منتقلی کی ہر ڈراؤنی کہانی کا درمیانی حصہ ایک جیسا ہوتا ہے: کسی نے پہلے DNS بدل دیا اور پھر کاپی شروع کی۔ منتقلی کے دوران ڈاؤن ٹائم تقریباً کبھی سست کاپی کی وجہ سے نہیں ہوتا۔ وہ قدموں کی غلط ترتیب کی وجہ سے ہوتا ہے۔
یہ رہی وہ ترتیب جو کام کرتی ہے، چاہے آپ کسی اور فراہم کنندہ کو چھوڑ رہے ہوں یا ہمارے دو پلانز کے درمیان جا رہے ہوں۔
1۔ دو دن پہلے: TTL کم کریں
وہ DNS ریکارڈز ڈھونڈیں جنہیں آپ بدلیں گے (عام طور پر A، AAAA اور ان کی طرف اشارہ کرنے والے CNAME) اور ان کا TTL 300 سیکنڈ کر دیں۔ پھر کم از کم اتنا انتظار کریں جتنا پرانا TTL تھا۔ ایک دن کے TTL والے ریکارڈ کا مطلب ہے کہ کچھ ریزولورز تبدیلی کے بعد بھی ایک دن تک پرانا ایڈریس دیتے رہیں گے، اور سرور پر آپ کچھ بھی کریں، یہ تیز نہیں ہوگا۔
یہی قدم لوگ چھوڑ دیتے ہیں، اور یہی پانچ منٹ کے سوئچ کو ایسے دن میں بدل دیتا ہے جب آدھے صارفین پرانا سرور دیکھتے ہیں۔
2۔ پرانے سرور کی فہرست بنائیں
آپ اس مشین کو کہیں اور دوبارہ بنانے والے ہیں، اس لیے لکھ لیں کہ یہ اصل میں کیا کرتی ہے۔ وہ نہیں جو آپ کو یاد ہے۔ جو یہ کرتی ہے:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
فہرست میں یہ بھی شامل کریں: TLS سرٹیفکیٹ اور ان کی تجدید کا طریقہ، سیکریٹس والی انوائرنمنٹ فائلیں، فائر وال کے قواعد، صارفین اور ان کی SSH کیز، ڈیٹابیس اور اس کا سائز، اور ہر وہ چیز جو سرور سے IP ایڈریس کے ذریعے بات کرتی ہے۔ یہ آخری گروہ ہی چالاک ہے: کسی پارٹنر کی allowlist، پیمنٹ فراہم کنندہ کی ویب ہُک سیٹنگز، کوئی مانیٹرنگ جانچ۔
3۔ نیا سرور پرانے کے ساتھ کھڑا کریں
نیا سرور آرڈر کریں اور پرانے کو مت چھیڑیں۔ VPS فہرست سے ایسا پلان چنیں جس کی ڈسک اتنی یا اس سے زیادہ ہو جتنی آپ اصل میں استعمال کرتے ہیں، نہ کہ جتنی آپ کو بیچی گئی تھی۔ اگر پرانی مشین پر کوئی بھی اِن باؤنڈ ٹریفک آتا ہے (ویب سائٹ، ویب ہُکس، API) تو نئی کو اپنا IPv4 چاہیے۔ NAT پلان صرف اپنے SSH پورٹ پر اِن باؤنڈ کنکشن لیتا ہے، اور یہ کیوں اہم ہے، یہ ایک فارورڈ کیا گیا پورٹ کیا کر سکتا ہے اور کیا نہیں میں سمجھایا گیا ہے۔
کنیکٹ کریں، وہی پیکجز انسٹال کریں، صارفین اور فائر وال دوبارہ بنائیں۔ کیز اور پہلا لاگ اِن کنکشن گائیڈ میں ہیں۔
4۔ فائلیں دو بار سنک کریں
پہلا سنک سب کچھ کاپی کرتا ہے جبکہ پرانا سرور کام کرتا رہتا ہے۔ اس میں گھنٹے لگ سکتے ہیں؛ کوئی بات نہیں۔
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
آپشن --numeric-ids فائلوں کی ملکیت کو نمبر کے حساب سے برقرار رکھتا ہے، جس سے وہ پرانا جھٹکا نہیں لگتا کہ "سب کچھ غلط صارف کا ہے"، جب دونوں سسٹمز نے صارفین مختلف ترتیب میں بنائے ہوں۔ اگر آپ نے SSH پر rsync کبھی نہیں چلایا، تو VPS پر فائلیں کیسے منتقل کریں اسے قدم بہ قدم بتاتا ہے۔
دوسرا سنک، سوئچ سے بالکل پہلے، صرف وہی کاپی کرتا ہے جو پہلے کے بعد بدلا۔ عام طور پر چند سیکنڈ لگتے ہیں۔
5۔ ڈیٹابیس سوچ سمجھ کر منتقل کریں
فائلیں آسان ہیں۔ رائٹ لینے والا ڈیٹابیس وہ واحد حصہ ہے جہاں "بغیر ڈاؤن ٹائم" کے لیے یا تو تھوڑا سمجھوتا چاہیے یا زیادہ محنت۔
آسان طریقہ: جانچ کے لیے ایک بار ڈمپ لے کر ری اسٹور کریں، پھر سوئچ کے وقت ایک منٹ کے لیے رائٹ روکیں (ایپ کو صرف پڑھنے والے موڈ میں ڈالیں یا بند کریں)، تازہ ڈمپ لیں، نئے سرور پر ری اسٹور کریں اور ایپ وہیں چلائیں۔ زیادہ تر چھوٹے پروجیکٹس کے لیے یہ ایک دو منٹ کا وقفہ ہے، جس کی اطلاع پہلے دی جا سکتی ہے۔
بغیر وقفے کا طریقہ: پرانے ڈیٹابیس سے نئے میں ریپلیکیشن سیٹ کریں، اسے برابر آنے دیں، اور سوئچ کے وقت نئے کو مرکزی بنا دیں۔ تیاری زیادہ ہے، اور یہ تب جائز ہے جب ایک منٹ کے کھوئے رائٹ بھی قبول نہ ہوں۔
6۔ کسی اور کے دیکھنے سے پہلے نیا سرور جانچیں
DNS اب بھی پرانے سرور کی طرف ہے، اس لیے نئے کو آپ خاموشی سے جانچ سکتے ہیں۔ اپنے اصل ڈومین کی درخواست نئے ایڈریس پر بھیجیں:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
اگر سرٹیفکیٹ ابھی نہیں ہے تو اسی طرح HTTP پر جانچیں، یا hosts فائل میں عارضی لائن جوڑ کر براؤزر میں سائٹ گھوم لیں۔ لاگ اِن، اپ لوڈ، بیک گراؤنڈ کام اور جانے والی میل جانچیں۔ غائب PHP ایکسٹینشن پکڑنے کا یہی سب سے سستا موقع ہے۔
7۔ سوئچ کریں، اور پرانا سرور چلتا رہنے دیں
آخری فائل سنک اور ڈیٹابیس والا قدم مکمل کریں، پھر DNS ریکارڈز بدلیں۔ 300 سیکنڈ کے TTL کے ساتھ زیادہ تر ٹریفک منٹوں میں منتقل ہو جاتا ہے۔ پرانے سرور کا ایکسیس لاگ دیکھتے رہیں: TTL کو نظرانداز کرنے والے ریزولورز اور کلائنٹس سے وہاں اب بھی کچھ درخواستیں آتی رہیں گی۔ اسے بغیر بدلے چند دن چلنے دیں۔ پھر پرانے IP کی طرف اشارہ کرنے والی ہر چیز اپ ڈیٹ کریں: پارٹنرز کی allowlist، ویب ہُک URLs، اور میل کے لیے نئے ایڈریس کا ریورس DNS (ہمارے ڈیڈیکیٹڈ IP پلانز پر آپ اسے خود سیٹ کرتے ہیں، دیکھیں ریورس DNS) اور اپنا SPF ریکارڈ۔
سب سے زیادہ کیا ٹوٹتا ہے
موٹے طور پر اس ترتیب میں جتنی بار ہم اسے دیکھتے ہیں: ایک systemd ٹائمر جسے کسی نے فہرست میں نہیں ڈالا، پرانے IP کے ساتھ سیدھی لکھی کنفیگ فائل، غلط صارف کی فائلیں، ایپ کے اپنے پورٹ کو روکنے والا فائر وال، پرانے سرور پر تجدید ہونے والا لیکن نئے پر نہ ہونے والا سرٹیفکیٹ، اور اسپام میں جاتی میل کیونکہ نئے ایڈریس کا ابھی ریورس DNS نہیں۔
یہ چیک لسٹ کہاں مناسب نہیں
مسلسل رائٹ والے مصروف ڈیٹابیس کو، جو وقفہ بالکل برداشت نہیں کر سکتا، بلاگ کی چیک لسٹ نہیں بلکہ اصل ریپلیکیشن اور ایک ریہرسل چاہیے۔ Windows سرورز rsync کے بجائے دوسرے اوزاروں سے منتقل ہوتے ہیں۔ اور اگر منتقلی اصل میں سائز کی وجہ سے ہے تو پہلے یہ پڑھیں: یہاں پلانز وہیں بڑھتے ہیں۔ اسی نیٹ ورک ٹائپ کے بڑے پلان پر جانے سے بغیر کسی منتقلی کے ایک ری بوٹ میں vCPU، RAM اور ڈسک بڑھ جاتے ہیں۔ نیا سرور صرف چھوٹا کرنے کے لیے چاہیے۔ اگر آپ اس لیے منتقل ہو رہے ہیں کہ معلوم نہیں مشین کافی ہے یا نہیں، تو آپ کو واقعی 64 GB RAM کب چاہیے آپ کو یہ سفر بچا سکتا ہے، اور اگر یقین نہیں کہ VPS صحیح ٹھکانا ہے تو VPS بمقابلہ شیئرڈ ہوسٹنگ بمقابلہ ڈیڈیکیٹڈ بمقابلہ کلاؤڈ مدد کرے گا۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔