سایت را باز می‌کنی، پنل هاست را باز می‌کنی، و بین دو دکمه گیر کرده‌ای: «ارتقا» و «انتقال». می‌دانی که باید پلن را عوض کنی چون یا فضای دیسک پر شده، یا تعداد inode از سقف گذشته، یا هر شب ساعت دوازده سایت خواب می‌رود چون RAM پلن جواب نمی‌دهد. سؤال واقعی این نیست که کدام پلن بهتر است؛ سؤال این است که ارتقای پلن هاست را با چه ترتیبی انجام بدهی که کاربری که وسط خرید است، صفحهٔ سفید نبیند.
اولین کاری که می‌کنم این است که علت را با عدد مشخص کنم، نه با حس. اگر شک داری که مشکل از inode است، با یک دستور ساده می‌شود شمرد:
find ~ -type f | wc -l
find ~ -type d | wc -lجمع این دو عدد را با سقف پلن مقایسه کن. اگر به سقف نزدیک شده‌ای، ارتقا فقط وقت می‌خرد؛ مشکل اصلی معمولاً کش‌های قدیمی، نسخه‌های پشتیبان روی خود هاست، یا فایل‌های session انبارشده است. جزئیات شمارش و اینکه چه چیزی inode می‌خورد در محدودیت inode در هاست آمده و ارزش پنج دقیقه خواندن دارد، چون بدون آن ممکن است پلن گران‌تر بخری و دو هفته بعد دوباره به همان سقف بخوری.
چرا ارتقای پلن هاست روی همان سرور تقریباً بدون قطعی است
وقتی پلن جدید روی همان سرور و همان پارتیشن باشد، انتقال فقط یک تغییر سهمیه (quota) و بازنویسی کانفیگ وب‌سرور است. فایل‌ها جابه‌جا نمی‌شوند. DNS عوض نمی‌شود. SSL دست نمی‌خورد. در این حالت downtime واقعی معمولاً زیر ۶۰ ثانیه است و بیشترش صرف reload شدن PHP-FPM و وب‌سرور می‌شود.
اما اگر پلن جدید روی سرور دیگری باشد، داستان کاملاً عوض می‌شود. اینجا یک مهاجرت کامل داری: کپی فایل‌ها، dump و restore دیتابیس، تنظیم مجدد cron، و مهم‌تر از همه، انتظار برای TTL رکورد A. اینجاست که سایت‌ها ساعت‌ها پایین می‌مانند و کسی هم متوجه نمی‌شود چرا.
قبل از هر چیز: TTL را کم کن، نه بعد از انتقال
اینجا اشتباه می‌کنند. اکثر افراد اول انتقال را انجام می‌دهند و بعد یادشان می‌افتد که TTL رکورد A روی ۸۶۴۰۰ ثانیه (۲۴ ساعت) است. نتیجه‌اش این می‌شود که سایت جدید آماده است، ولی بخشی از کاربران تا یک روز کامل هنوز به سرور قدیمی می‌روند. اگر سرور قدیمی را خاموش کرده باشی، آن‌ها خطای اتصال می‌بینند و تو فکر می‌کنی DNS مشکل دارد.
ترتیب درست این است: حداقل ۲۴ تا ۴۸ ساعت قبل از انتقال، TTL رکورد A را به ۳۰۰ ثانیه (۵ دقیقه) کاهش بده. صبر کن تا TTL قدیمی منقضی شود. بعد انتقال را انجام بده. بعد از اینکه مطمئن شدی همه‌چیز پایدار است، TTL را به مقدار قبلی برگردان.
| رکورد | قبل از انتقال | حین انتقال | بعد از تثبیت |
|---|---|---|---|
| A / AAAA | 300 | 300 | 3600 یا 86400 |
| MX | دست نزن | دست نزن | دست نزن |
| CNAME (www) | 300 | 300 | 3600 |
رکورد MX را در جریان انتقال هاست عوض نکن. اگر ایمیل روی همان دامنه است، تغییر MX وسط کار باعث می‌شود ایمیل‌های چند ساعت گم شوند و در صف بمانند. ایمیل را جدا و در یک پنجرهٔ دیگر منتقل کن.
ترتیب دقیق کارها در پنجرهٔ کم‌بازدید
پنجرهٔ زمانی را بر اساس آمار خودت انتخاب کن، نه بر اساس عادت. اگر ترافیک سایتت بین ۳ تا ۵ بامداد به وقت تهران کمترین مقدار را دارد، همان بازه را بردار. اگر سایتت مخاطب خارجی دارد، این بازه غلط است و باید ساعت ۱۰ تا ۱۲ UTC را انتخاب کنی. یک نگاه به گزارش بازدید ساعتی کافی است.
- پشتیبان کامل بگیر و آن را جای دیگری نگه دار. نه روی همان هاست. فایل tar.gz و dump دیتابیس را دانلود کن و حجمشان را چک کن. پشتیبانی که حجمش صفر است، پشتیبان نیست.
- نسخه‌های PHP و MySQL را روی پلن جدید یادداشت کن. اگر سایتت روی PHP 7.4 است و پلن جدید پیش‌فرض 8.2 دارد، قبل از انتقال سازگاری را تست کن. فهرست افزونه‌های موجود و روش تست در بررسی افزونه‌های PHP روی هاست توضیح داده شده.
- سایت را روی مقصد بالا بیاور، ولی هنوز DNS را عوض نکن. با ویرایش فایل hosts روی سیستم خودت یا با یک subdomain موقت، سایت جدید را تست کن. این مرحله جایی است که ۹۰٪ خطاها پیدا می‌شود.
- دیتابیس را dump و restore کن. با
mysqldump --single-transaction --routines --triggersبگیر تا جداول InnoDB وسط کار قفل نشوند. - DNS را عوض کن. حالا که TTL پایین است، انتشار در چند دقیقه انجام می‌شود.
- سرور قدیمی را حداقل ۷۲ ساعت روشن نگه دار. فقط برای اطمینان. بعد خاموشش کن.
مرحلهٔ سوم را جدی بگیر. اگر بدون تست، DNS را عوض کنی و بعد بفهمی افزونهٔ imagick روی پلن جدید نصب نیست، مجبوری برگردی عقب و این بار با کاربران واقعی روی سایت.
نکته‌ای که در انتقال‌های واقعی زیاد می‌بینم
فایل wp-config.php یا معادلش را فراموش می‌کنند. سایت بالا می‌آید، صفحهٔ اول باز می‌شود، ولی هر صفحه‌ای که به دیتابیس نیاز دارد خطای «Error establishing a database connection» می‌دهد. علتش این است که اطلاعات اتصال دیتابیس در فایل کانفیگ هنوز به سرور قدیمی اشاره می‌کند، یا نام کاربری دیتابیس روی پلن جدید با قبلی فرق دارد. این خطا را در لاگ خطا هم می‌بینی، ولی خیلی‌ها فقط لاگ وب‌سرور را نگاه می‌کنند و چیزی پیدا نمی‌کنند.
مورد دوم: مسیرهای مطلق. اگر در کانفیگ یا در دیتابیس مسیر /home/olduser/public_html هاردکد شده باشد، روی پلن جدید که نام کاربری عوض شده، همه‌چیز می‌شکند. قبل از انتقال با یک جست‌وجوی ساده در دیتابیس پیدا و اصلاحش کن.
وقتی ارتقا جواب نمی‌دهد و باید سراغ سرور اختصاصی بروی
یک محدودیت واقعی وجود دارد که کمتر گفته می‌شود: اگر مصرف CPU سایتت به‌طور مداوم از سهم پلن بالاتر است، ارتقای پلن هاست فقط سقف را کمی بالا می‌برد و دو ماه بعد دوباره به همان دیوار می‌خوری. نشانه‌اش این است که در گزارش منابع، مصرف CPU در ساعات اوج به سقف می‌چسبد و بعد از ارتقا هم الگو تکرار می‌شود.
در این حالت دو راه داری. یا معماری را بهینه کنی (کش صفحه، کش آبجکت، جدا کردن پردازش‌های سنگین از مسیر درخواست کاربر)، یا به یک سرور اختصاصی منتقل شوی که سقف اشتراکی نداری. انتخاب من این است: اول بهینه‌سازی، چون هزینه‌اش کمتر است و نتیجه‌اش روی هر پلنی می‌ماند. اگر بعد از بهینه‌سازی هنوز سقف می‌خوری، آن‌وقت سراغ سرور اختصاصی برو. برعکسش یعنی پول بیشتری برای همان مشکل می‌دهی.
اگر سایت وردپرسی است و فقط ترافیک بالا رفته، معمولاً با یک کش صفحهٔ درست، مصرف CPU تا نصف کم می‌شود. این را قبل از هر تصمیم خرید تست کن.
بعد از انتقال چه چیزی را چک کنی
انتقال تمام نشده تا وقتی این‌ها را چک نکرده باشی:
- گواهی SSL روی دامنهٔ اصلی و
wwwمعتبر است و تاریخ انقضا درست است. اگر ریدایرکت HTTPS حلقه زده، راهنمای نصب SSL روی هاست مشکل را دقیق توضیح می‌دهد. - کرون‌جاب‌ها روی پلن جدید ساخته شده‌اند. این را زیاد فراموش می‌کنند و یک هفته بعد می‌فهمند پشتیبان خودکار اجرا نشده.
- ایمیل‌های تراکنشی (فرم تماس، بازیابی رمز) واقعاً ارسال می‌شوند. یک تست واقعی بفرست، نه فقط نگاه کردن به تنظیمات.
- TTL را به مقدار قبلی برگردان.
برای بررسی انتشار DNS از چند نقطه، ابزار بررسی DNS و شبکه کار را سریع می‌کند؛ لازم نیست از چند شهر مختلف دستی dig بزنی. و اگر می‌خواهی قبل از تصمیم نهایی، رفتار پلن‌ها را با یک سایت تست بسنجی، ابزارهای رایگان وب‌مستر نقطهٔ شروع خوبی است.
یک نکتهٔ آخر دربارهٔ زمان‌بندی: اگر سایت فروشگاهی داری و وسط کمپین هستی، انتقال را عقب بینداز. هیچ پنجرهٔ کم‌بازدیدی به‌اندازهٔ یک کمپین فعال ارزش ندارد. ارتقای پلن هاست یک کار فنی است، ولی زمان‌بندی‌اش یک تصمیم کسب‌وکاری است.
پرسش‌های پرتکرار
ارتقای پلن هاست چقدر طول می‌کشد و آیا سایت پایین می‌آید؟
اگر پلن جدید روی همان سرور باشد، معمولاً کمتر از یک دقیقه و بدون قطعی محسوس. اگر روی سرور دیگری باشد، زمان واقعی به حجم فایل‌ها و دیتابیس بستگی دارد و می‌تواند از چند دقیقه تا چند ساعت طول بکشد؛ در این حالت قطعی را با کاهش TTL و تست روی مقصد قبل از تغییر DNS به حداقل می‌رسانی.
چرا بعد از انتقال سایت هنوز به سرور قدیمی می‌رود؟
چون TTL رکورد A قبل از انتقال کم نشده و کش DNS کاربران و resolverها هنوز مقدار قدیمی را نگه داشته است. تا زمانی که TTL قبلی منقضی نشود، بخشی از ترافیک به مقصد قدیمی می‌رود. راه‌حل این است که TTL را ۲۴ تا ۴۸ ساعت قبل از انتقال به ۳۰۰ ثانیه برسانی.
آیا باید MX را هم موقع انتقال هاست عوض کنم؟
نه. رکورد MX را در جریان انتقال هاست دست نزن، مخصوصاً اگر ایمیل روی همان دامنه است. تغییر MX وسط کار باعث می‌شود ایمیل‌ها چند ساعت در صف بمانند یا برگردند. ایمیل را در یک پنجرهٔ زمانی جدا و بعد از تثبیت سایت منتقل کن.
از کجا بفهمم مشکل از پلن است یا از کد سایت؟
به گزارش منابع در ساعات اوج نگاه کن. اگر مصرف CPU و RAM به سقف می‌چسبد و همزمان زمان پاسخ دیتابیس بالا رفته، احتمالاً پلن تنگ است. اگر مصرف منابع پایین است ولی سایت کند می‌ماند، مشکل معمولاً در کد، کوئری‌های سنگین یا نبود کش است و ارتقای پلن فقط هزینه را بالا می‌برد.