پہلے نیا سرور تیار اور آزمائیں، ایپلیکیشن کے تعاون یافتہ مستقل مزاجی کے طریقے سے ڈیٹا کاپی کریں، کٹ اوور کی ونڈو متعین کریں اور پرانا ماحول محفوظ رکھیں۔ رول بیک میں نئے سرور پر قبول شدہ تحریروں کا بھی خیال رکھنا چاہیے، نہ کہ صرف DNS تبدیلی کا۔
مشین منتقل کرنے سے پہلے سروس کی فہرست بنائیں
مائیگریشن میں ایپلیکیشن فائلوں سے زیادہ کچھ شامل ہوتا ہے۔ ڈیٹا بیس، اپ لوڈز، شیڈولڈ جابز، کیو ورکرز، سرٹیفکیٹس، ڈومینز، سیکرٹس اور آؤٹ باؤنڈ انٹیگریشنز کی فہرست بنائیں۔ سافٹ ویئر ورژنز اور اہم آپریٹنگ مفروضات ریکارڈ کریں، جیسے فائل پرمیشنز اور اسٹوریج پاتھ۔ ایک نیا ڈیڈیکیٹڈ سرور کوئی بھولا ہوا انحصار بے نقاب کر سکتا ہے جو برسوں پہلے پرانے ماحول پر خاموشی سے انسٹال ہوا تھا۔
کٹ اوور کے فیصلے کے لیے ایک ذمہ دار مقرر کریں اور وضاحت کریں کہ کامیابی کیسی نظر آئے گی۔ صارف کو نظر آنے والی جانچ، ڈیٹا کی مستقل مزاجی اور رسائی بحال کرنے کی صلاحیت شامل کریں۔ مائیگریشن کی تاریخ کا اعلان کرنے سے پہلے تصدیق کریں کہ نئی کنفیگریشن فراہم اور قابل استعمال ہے۔ آرڈر کی تصدیق یا درج ہارڈویئر تفصیلات کا مطلب پروڈکشن ڈیٹا وصول کرنے کے لیے تیار کام کرنے والی منزل نہیں ہے۔
منزل کو ایک الگ ماحول کے طور پر بنائیں
مطلوبہ اسٹیک انسٹال کریں، انتظامیہ قائم کریں اور مطلوبہ فائر وال کنفیگر کریں۔ سیکرٹس نجی رکھیں اور سروس پرمیشنز سوچ سمجھ کر مقرر کریں۔ عوامی ٹریفک منتقل ہونے سے پہلے ایپلیکیشن کے متوقع ہوسٹ نام اور سرٹیفکیٹ کے رویے کی تصدیق کریں۔ Apache کی ورچوئل ہوسٹ دستاویزات واضح کرتی ہیں کہ ہوسٹ نام کی روٹنگ سرور کے پتے سے الگ کنفیگریشن کا فیصلہ کیوں ہے۔ کام کرنے والا ڈیفالٹ صفحہ یہ ثابت نہیں کرتا کہ درست ایپلیکیشن ہوسٹ کنفیگر ہے۔
مشق کے لیے ایک نمائندہ بحال شدہ ڈیٹا سیٹ استعمال کریں، جس میں آؤٹ گوئنگ ای میل، ادائیگیاں اور شیڈولڈ جابز غیر فعال یا محفوظ ٹیسٹ سسٹمز کی طرف ری ڈائریکٹ ہوں۔ یہ ٹیسٹ ماحول کو حقیقی صارفین پر عمل کرنے سے روکتا ہے۔ لاگ ان، اپ لوڈز، پس منظر کے کام اور بحالی کی مشق کریں۔ طریقہ کار اور اس کا دورانیہ ریکارڈ کریں تاکہ حقیقی ونڈو مشاہدہ شدہ عمل پر مبنی ہو، نہ کہ امید پر۔
ایک مستقل ڈیٹا حد منتخب کریں
ڈیٹا بیس اور ایپلیکیشن کے تعاون یافتہ بیک اپ یا ریپلیکیشن کا طریقہ استعمال کریں۔ PostgreSQL SQL ڈمپس، فائل سسٹم بیک اپس اور مسلسل آرکائیونگ میں فرق کرتا ہے، ہر ایک کے اپنے مفروضات ہیں۔ اس کی ڈمپ گائیڈ بتاتی ہے کہ ڈیٹا بیس ڈمپس اندرونی طور پر مستقل ہو سکتے ہیں جبکہ کلسٹر وسیع کرداروں اور دیگر تفصیلات کے لیے الگ انتظام درکار ہوتا ہے۔ کھلی ڈیٹا فائلوں کو بلا امتیاز کاپی کرنے کے بجائے اپنے چلائے جانے والے عین نظام کی ضروریات پڑھیں۔
منصوبہ بنائیں کہ ڈیٹا بیس کا اپ لوڈز اور کیو اسٹیٹ سے کیسے تعلق ہے۔ اگر کوئی ریکارڈ ایسی فائل کی طرف اشارہ کرے جو مختلف وقت پر کاپی ہوئی، تو بحال شدہ ایپلیکیشن نامکمل ہو سکتی ہے چاہے دونوں کاپیاں الگ الگ کامیاب رہی ہوں۔ فیصلہ کریں کہ تحریروں کو مختصراً روکنا ہے، آزمودہ ریپلیکیشن انتظام استعمال کرنا ہے یا ایپلیکیشن کے مخصوص ایکسپورٹ کو انجام دینا ہے۔ اس مستقل مزاجی کے فیصلے کو رن بک میں واضح رکھیں۔
| مرحلہ | درکار ثبوت | فیصلہ |
|---|---|---|
| مشق | ایپلیکیشن اور بحال شدہ ڈیٹا جانچ پاس کرتے ہیں | منزل کو کٹ اوور کے لیے قابل غور سمجھا جا سکتا ہے |
| حتمی ہم آہنگی | متعین کردہ مستقل ریکوری پوائنٹ | صرف سمجھی گئی باقی تبدیلیوں کے ساتھ آگے بڑھیں |
| ٹریفک سوئچ | درست روٹنگ اور سرٹیفکیٹ کا رویہ | دونوں منزلوں کی نگرانی کریں |
| رول بیک | تمام نئی قبول شدہ تحریروں کا مقام | ٹریفک واپس کرنے سے پہلے ڈیٹا کی مفاہمت کریں |
فوری تبدیلیوں کا وعدہ کیے بغیر ٹریفک روٹنگ تیار کریں
DNS ٹائم ٹو لائیو کنٹرول کرتا ہے کہ ریکارڈز کتنی دیر کیش کیے جا سکتے ہیں، جیسا کہ Cloudflare کی DNS دستاویزات میں بیان کیا گیا ہے۔ اگر DNS مائیگریشن کا حصہ ہو تو TTL کا جائزہ ابتدائی طور پر لیں، اور موجودہ کیش شدہ ریکارڈز کو ان کی پچھلی ترتیب کے تحت پرانا ہونے دیں۔ کٹ اوور کے لمحے قدر تبدیل کرنا ہر کیش شدہ جواب کو ماضی میں مختصر نہیں کر سکتا۔ منتقلی کے دوران مختلف کلائنٹس مختلف منزلوں تک پہنچ سکتے ہیں۔
روٹنگ کی تبدیلیاں طے ہونے تک پرانا ماحول دستیاب رکھیں، اس بارے میں سوچیں کہ آیا یہ اب بھی تحریریں قبول کر سکتا ہے۔ ڈپلیکیٹ کیو کنزیومرز یا شیڈولڈ جابز چلانے سے گریز کریں جب تک ایپلیکیشن اس کے لیے ڈیزائن نہ کی گئی ہو۔ دونوں طرف درخواستوں کی نگرانی کریں اور آزاد کلائنٹس سے مطلوبہ ہوسٹ نام، TLS سرٹیفکیٹ اور ایپلیکیشن ورژن کی تصدیق کریں۔
تحریروں کے آغاز کے بعد رول بیک کی وضاحت کریں
نئے نظام کے تبدیلیاں قبول کرنے سے پہلے، ٹریفک واپس کرنا نسبتاً آسان ہو سکتا ہے۔ اس کے بعد، صرف DNS کی واپسی کام ضائع کر سکتی ہے یا دو متضاد تاریخیں بنا سکتی ہے۔ وضاحت کریں کہ نئے بنائے گئے ریکارڈز اور اپ لوڈز کو کیسے محفوظ یا ہم آہنگ کیا جائے گا۔ اگر ایپلیکیشن انہیں محفوظ طریقے سے ضم نہیں کر سکتی، تو پرانی کاپی پر بے ترتیب واپسی کے بجائے کنٹرول شدہ دیکھ بھال کی مدت بہتر ہو سکتی ہے۔
وہ شرائط مقرر کریں جن میں مائیگریشن روکنا ضروری ہو، اور فیصلے کے ذمہ دار کو قابل رسائی رکھیں۔ لاگز اور مفید ثبوت پروجیکٹ کے برقراری کے قواعد کے تحت محفوظ رکھیں۔ صرف اس لیے پرانی مشین یا اس کی آزاد ریکوری کاپی حذف نہ کریں کہ ہوم پیج ایک بار لوڈ ہو گیا تھا۔ برقراری کی مدت میں متفقہ تصدیق اور رول بیک کی ضروریات شامل ہونی چاہیے۔
آپریشنل جانچ کے ساتھ مائیگریشن مکمل کریں
کٹ اوور کے بعد، بیک اپس، الرٹس، سرٹیفکیٹ کی تجدید، شیڈولڈ کام اور رسائی کی بحالی کی تصدیق کریں۔ تصدیق کریں کہ نگرانی شدہ ہوسٹ نئی منزل ہے اور پروڈکشن میں کوئی ٹیسٹ انٹیگریشن باقی نہیں۔ عام ٹریفک کے تحت ایپلیکیشن کی غلطیاں اور صارف کو نظر آنے والے اوقات کا جائزہ لیں۔ انوینٹری اور رن بک اپ ڈیٹ کریں تاکہ اگلے منتظم کو اندازہ نہ لگانا پڑے کہ کیا تبدیل ہوا۔
SwissOctet کے ڈیڈیکیٹڈ فیملیز مختلف فزیکل کنفیگریشنز پیش کرتے ہیں، لیکن مائیگریشن کے کام اور منظم معاونت کی تصدیق منتخب کردہ سروس کے لیے کرنی ہوگی۔ کیٹلاگ سے موزوں وسائل منتخب کریں، پھر اپنی ایپلیکیشن کے ڈیٹا کے گرد ایک آزمودہ منتقلی بنائیں۔ مائیگریشن اس وقت مکمل ہوتی ہے جب سروس اور اس کا ریکوری عمل منزل پر کام کرے، نہ کہ صرف فائلوں کی منتقلی پر۔
آپ کی عملی چیک لسٹ۔
- ڈیٹا، جابز، سیکرٹس اور انٹیگریشنز کی فہرست بنائیں۔
- شیڈول کرنے سے پہلے فراہم کردہ منزل کی تصدیق کریں۔
- محفوظ بیرونی انٹیگریشنز کے ساتھ مشق کریں۔
- ڈیٹا بیس اور اپ لوڈ کی مستقل مزاجی متعین کریں۔
- روٹنگ کی منتقلی اور ڈپلیکیٹ جابز کی روک تھام کا منصوبہ بنائیں۔
- نئی تحریروں کے لیے رول بیک متعین کریں۔
- کٹ اوور کے بعد بیک اپس اور نگرانی کی تصدیق کریں۔
وہ تفصیلات جو اہم ہیں۔
کیا میں ایپلیکیشن ڈائریکٹری کاپی کر کے مائیگریٹ کر سکتا ہوں؟+
صرف اس صورت میں جب یہ سروس کی ہر ضرورت کو پکڑے اور مستقل مزاجی برقرار رکھے۔ ڈیٹا بیس، اپ لوڈز، جابز، سیکرٹس اور کنفیگریشن عام طور پر الگ توجہ مانگتے ہیں۔
کیا DNS TTL کم کرنے سے کٹ اوور فوری ہو جاتا ہے؟+
نہیں۔ پہلے کیش شدہ جواب اپنی پہلی عمر ختم ہونے تک رہ سکتے ہیں، اور کلائنٹس مختلف اوقات میں اپ ڈیٹ ہو سکتے ہیں۔
کیا رول بیک صرف DNS کو پرانے سرور کی طرف اشارہ کرنا ہے؟+
نئے سرور کے تحریریں قبول کرنے کے بعد نہیں۔ ٹریفک واپس کرنے سے پہلے ان ریکارڈز اور فائلوں کا خیال رکھنا ہوگا۔
ماخذ پر جائیں۔
یہ حوالہ جات اس گائیڈ میں تکنیکی تصورات کی حمایت کرتے ہیں۔ پروڈکشن سسٹم تبدیل کرنے سے پہلے موجودہ دستاویزات کی پیروی کریں۔
- PostgreSQL: بیک اپ اور بحالی www.postgresql.org
- PostgreSQL: SQL ڈمپ کی مستقل مزاجی اور بحالی www.postgresql.org
- Apache: ورچوئل ہوسٹ دستاویزات httpd.apache.org
- Cloudflare DNS: ٹائم ٹو لائیو developers.cloudflare.com
SwissOctet کی طرف سے ادارتی رہنمائی۔ مثالیں مثالی ہیں۔ سروس کی تفصیلات، دستیاب اختیارات اور معاہدے کی شرائط الگ سے تصدیق شدہ ہونی چاہئیں۔