مقاله 08 / مهاجرت زیرساخت
مهاجرت سایت به سرور جدید با کمترین اختلال؛ برنامه انتقال و بازگشت
مشخصات پیشنهادی انتشار
- عنوان سئو
- مهاجرت سایت به سرور جدید با کمترین اختلال | نگهبان وب
- توضیح متا
- برای مهاجرت سایت به سرور جدید، وابستگی‌ها، انتقال داده، DNS و برنامه بازگشت را مشخص کنید؛ مسیر کاهش اختلال و تأیید سلامت پس از انتقال را ببینید.
- مسیر پیشنهادی
- /blog/server-migration-plan
- عبارت اصلی
- مهاجرت سایت به سرور جدید
- تصویر
- server-migration-plan.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
مهاجرت سایت فقط کپی کردن فایل و تغییر IP دامنه نیست. برنامه، دیتابیس، فایل‌های کاربران، صف‌ها، زمان‌بندی‌ها و سرویس‌های بیرونی باید در مقصد درست کار کنند. اگر این وابستگی‌ها دیده نشوند، ممکن است صفحه اصلی باز شود اما سفارش، ورود یا ارسال پیام شکست بخورد.
هدف عملی، کاهش اختلال با برنامه روشن و معیار تصمیم مشخص است. وعده «بدون حتی یک ثانیه قطعی» برای هر معماری قابل اتکا نیست. میزان اختلال به روش انتقال داده، وضعیت برنامه و امکان هم‌زمانی کنترل‌شده محیط‌ها بستگی دارد.
دامنه‌ها، رکوردهای DNS، گواهی‌ها، نسخه runtime، پایگاه داده، فایل‌های آپلودی و سرویس‌های پس‌زمینه را فهرست کنید. ارسال ایمیل، callback پرداخت، webhook و دسترسی API به IP مبدأ نیز ممکن است به تغییر حساس باشند.
برای هر جزء، مسئول و روش آزمون مشخص کنید. اگر فقط یک نفر می‌داند یک cron چه کاری می‌کند، قبل از انتقال آن را مستند کنید. بهتر است برنامه مهاجرت شامل زمان اجرا، مسئول تصمیم و حد توقف نیز باشد تا هنگام فشار، تصمیم‌ها بداهه نشوند.
مقصد را پیش از جابه‌جایی ترافیک آماده کنید
سیستم‌عامل، وابستگی‌ها، فضای ذخیره‌سازی، شبکه و گواهی مقصد را آماده کنید. برنامه را با نسخه مشخص اجرا کنید و مسیرهای اصلی را بدون ایجاد اثر واقعی ناخواسته آزمایش کنید. برای تست HTTPS و میزبان مجازی، روش آزمایش باید نام دامنه و گواهی را هم درست در نظر بگیرد.
مقصد آزمایشی نباید هم‌زمان با مبدأ ایمیل، پیامک یا کار زمان‌بندی‌شده واقعی را تکرار کند. فعال بودن دو scheduler می‌تواند یک عملیات را دوبار اجرا کند. نقش workerها و زمان فعال شدن آن‌ها را در برنامه انتقال بنویسید.
روش انتقال داده را متناسب با سامانه انتخاب کنید
برای سایت کم‌تغییر، پنجره کوتاه توقف نوشتن و انتقال نهایی ممکن است کافی باشد. برای داده پرتغییر، replication یا انتقال مرحله‌ای می‌تواند لازم شود. استفاده از این روش‌ها به سازگاری نسخه‌ها، توان آزمون و ابزار موتور دیتابیس بستگی دارد.
در هر حالت باید «آخرین مرجع معتبر داده» مشخص باشد. اجازه نوشتن بی‌برنامه در دو دیتابیس مستقل می‌تواند داده‌های متناقض ایجاد کند. فایل‌های جدید کاربران نیز باید همراه تغییرات دیتابیس منتقل یا از فضای ذخیره مشترک مناسب خوانده شوند.
TTL را با انتظار درست تنظیم کنید
TTL به مدت نگهداری پاسخ DNS در کش مرتبط است. اگر لازم است آن را کاهش دهید، این کار را با فاصله کافی پیش از مهاجرت و متناسب با TTL قبلی انجام دهید. پایین آوردن مقدار درست هنگام جابه‌جایی، کش‌های قبلی را فوراً پاک نمی‌کند.
رفتار DNS proxied، DNS-only، resolverها و اتصال‌های موجود یکسان نیست. پس از تغییر، پاسخ چند resolver و دسترسی از شبکه‌های مرتبط را بررسی کنید. مبدأ را تا پایان دوره توافق‌شده بررسی نگه دارید، اما نقش نوشتن داده را کنترل کنید تا دو مرجع فعال ایجاد نشود.
یک برنامه اجرایی کوتاه بسازید
| مرحله | اقدام | معیار عبور |
|---|---|---|
| آمادگی | تست مقصد و تأیید بکاپ | نتیجه آزمون ثبت شده باشد |
| همگام‌سازی | انتقال داده و فایل | سازگاری و عقب‌ماندگی قابل قبول |
| نقطه انتقال | کنترل نوشتن و تغییر مسیر | مرجع داده واحد و روشن |
| تأیید | آزمون مسیرهای اصلی | ورود و عملیات ضروری سالم |
| تثبیت | پایش و نگهداشت مبدأ | نبود خطای باز طبق معیار توافق |
این جدول باید با معماری واقعی تکمیل شود. مثلاً وجود WebSocket یا پردازش طولانی به بررسی اتصال‌ها و تخلیه کارهای جاری نیاز دارد. زمان انتقال نیز باید با ترافیک و دسترسی اعضای تیم هماهنگ باشد.
بازگشت فقط تغییر دوباره DNS نیست
اگر پس از انتقال، سفارش جدید در مقصد ثبت شده باشد، برگشت ساده ترافیک به مبدأ ممکن است آن سفارش‌ها را پنهان یا پراکنده کند. قبل از اجرا مشخص کنید با داده نوشته‌شده در مقصد چه خواهید کرد و چه کسی اجازه تصمیم بازگشت دارد.
برای برخی رخدادها اصلاح رو به جلو، از بازگشت کامل کم‌خطرتر است. انتخاب آن باید براساس سلامت داده و زمان بازیابی باشد. برنامه بکاپ و بازیابی و فهرست تغییرات کمک می‌کنند این تصمیم قابل دفاع باشد.
بعد از انتقال چه چیزهایی را ببینیم؟
خطاهای برنامه، سرعت مسیرهای اصلی، پردازش صف، ارسال پیام و callbackها را کنترل کنید. سفارش یا تراکنش آزمایشی باید با ابزار رسمی آزمایشی و بدون ایجاد دریافت وجه ناخواسته انجام شود. سپس تنظیمات باقی‌مانده مبدأ و دسترسی‌های موقت را پاک‌سازی کنترل‌شده کنید.
پرسش‌های رایج
آیا مهاجرت همیشه بدون توقف ممکن است؟
خیر. سازگاری برنامه و داده تعیین‌کننده است. زمان توقف کوتاه و برنامه‌ریزی‌شده می‌تواند از انتقال نامطمئن بهتر باشد.
سرور قبلی را چه زمانی حذف کنیم؟
بعد از تأیید سلامت، پایان دوره پایش توافق‌شده و اطمینان از نگهداری داده و بکاپ لازم؛ صرف باز شدن صفحه اصلی کافی نیست.
برای برنامه انتقال متناسب با پروژه، درخواست مهاجرت زیرساخت ثبت کنید و حجم داده، مبدأ، مقصد و محدودیت زمانی را بنویسید.
