محتوای آموزشی وبلاگ نتآرام
انتقال موفق زمانی است که کاربر متوجه آن نشود. کپی فایلها بخش ساده کار است؛ اختلاف دیتابیس میان دو سرور، ایمیلی که به مقصد قدیمی میرسد یا Cronی که همزمان در هر دو سمت اجرا میشود، علت بیشتر انتقالهای دردسرساز است.
۲۴ تا ۴۸ ساعت پیش از انتقال
TTL رکوردهای مؤثر را کاهش دهید. این کار باید پیش از تغییر IP انجام شود تا Resolverها فرصت کنند مقدار کوتاهتر را دریافت کنند. فهرست کامل DNS را ذخیره کنید: رکوردهای وب، MX، SPF، DKIM، DMARC، زیردامنهها و سرویسهای جانبی.
همزمان وضعیت نسخههای PHP، افزونهها، ماژولها، دیتابیس، Cron و گواهی SSL دو میزبان را مقایسه کنید. انتقال به محیطی که نسخه لازم برنامه را ندارد، حتی با کپی کامل دادهها شکست میخورد.
کپی اولیه را در حالی انجام دهید که سایت فعال است
فایلها و یک Dump سازگار از دیتابیس را به مقصد ببرید. در این مرحله هنوز DNS تغییر نکرده، پس سایت اصلی سرویس میدهد. در مقصد مالکیت فایلها، مجوزها، اتصال دیتابیس و مسیر ذخیرهسازی را اصلاح کنید.
برای سایت بزرگ از انتقال افزایشی استفاده کنید: بار اول تمام فایلها و در مرحله نهایی فقط تفاوتها. این کار پنجره همگامسازی نهایی را کوتاه میکند.
پیش از تغییر DNS واقعاً تست کنید
با فایل Hosts سیستم آزمایش، دامنه را فقط روی دستگاه خود به IP جدید اشاره دهید. صفحات عمومی کافی نیستند؛ ورود، جستوجو، سبد خرید، پرداخت آزمایشی، آپلود، ارسال فرم، ایمیل خروجی و پنل مدیریت را بررسی کنید.
لاگ خطا، Redirectها، URLهای مطلق و دسترسی APIهای بیرونی را ببینید. اگر مقصد پشت CDN قرار میگیرد، یک بار مستقیم و یک بار از مسیر CDN آزمایش کنید.
پنجره همگامسازی نهایی
برای سایت پویا چند دقیقه حالت نگهداری یا توقف نوشتن لازم است. ترتیب امن معمولاً چنین است:
- توقف سفارش، ثبتنام یا نوشتن داده جدید؛
- Dump نهایی دیتابیس؛
- همگامسازی فایلهای تغییرکرده و Uploadها؛
- اجرای Migrationهای لازم در مقصد؛
- یک آزمون کوتاه؛
- تغییر رکورد DNS؛
- بازکردن سایت.
اگر برنامه صف دارد، Worker قدیمی را قبل از سوییچ متوقف کنید تا یک Job دوبار اجرا نشود.
ایمیل را جداگانه مدیریت کنید
اگر MX تغییر میکند، صندوقها، Aliasها و Forwarderها را پیش از سوییچ بسازید. سرور قدیمی را حداقل بهاندازه بیشترین TTL فعال نگه دارید و پیامهای باقیمانده را دوباره همگام کنید. SPF و DKIM مقصد باید پیش از ارسال انبوه درست باشند؛ وگرنه ایمیل تحویل میشود اما به Spam میرود.
اگر ایمیل روی سرویس دیگری است و MX تغییر نمیکند، بیدلیل رکوردهای آن را دست نزنید.
برنامه بازگشت داشته باشید
پیش از شروع مشخص کنید در چه شرایطی برمیگردید و کدام داده منبع حقیقت است. پس از پذیرش سفارش روی مقصد، برگشت ساده به سرور قدیمی ممکن است داده جدید را حذف کند. برای همین نقطه تصمیم و مسئول اجرا باید از قبل معلوم باشد.
خدمات میزبانی و مدیریت سرور زمانی ارزشمندند که انتقال با چکلیست، لاگ و امکان بازگشت انجام شود، نه با تغییر ناگهانی نامسرور.
جمعبندی
انتقال بدون قطعی حاصل آمادهسازی DNS، آزمون مقصد، همگامسازی نهایی کنترلشده و نگهداری موقت سرور قدیمی است. ایمیل و Jobهای پسزمینه را مستقل ببینید و فقط زمانی منبع قبلی را خاموش کنید که ترافیک، داده و پیامها در مقصد تأیید شده باشند.
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام