انقل موقعك بين السيرفرات بصفر توقف: خطة عملية من خمس مراحل

الجواب المختصر: صفر توقف يبدأ قبل النقل بيومين لا لحظته

نقل موقعك بين سيرفرين بصفر توقف ممكن، لكنه لا يحصل بالضغط على زر واحد يوم النقل، بل يبدأ قبل يومين بخطوة واحدة صغيرة: خفض قيمة DNS TTL. القاعدة العملية أن أغلب حالات التوقف أثناء النقل سببها انتظار انتشار DNS الذي قد يستغرق حتى 48 ساعة على سجل TTL افتراضي مقداره 86400 ثانية، فإذا خفضته مبكراً إلى 300 ثانية صار التبديل النهائي يكتمل خلال خمس دقائق بدل يومين.

الخطة كاملة خمس مراحل مرتبة: أولاً خفض TTL قبل النقل بـ 48 ساعة، ثانياً مزامنة الملفات مرتين (نسخة أولية كبيرة ثم نسخة تفاضلية سريعة)، ثالثاً نقل قاعدة البيانات في آخر لحظة لتفادي فقد أي صف، رابعاً اختبار الموقع كاملاً على السيرفر الجديد عبر ملف hosts قبل أن يراه أي زائر، وخامساً تبديل DNS ثم تجميد الكتابة على السيرفر القديم لمدة قصيرة. لو التزمت بالترتيب هذا فالمستخدم لن يشعر بأي انقطاع، وأقصى ما قد يحصل ثوانٍ من قراءة محتوى قديم قبل أن يستقر كل شيء. هذا الدليل يشرح كل مرحلة بأوامر فعلية وأرقام تقيس عليها نجاحك، مع خطة تراجع جاهزة لو ساءت الأمور.

ليش المواقع تطيح أثناء النقل؟ ثلاثة أسباب فقط

قبل ما نحل المشكلة نفهمها. التوقف أثناء النقل ليس قدراً محتوماً، بل ينتج عن ثلاثة أخطاء متكررة، ولو أغلقت هذه الأبواب الثلاثة وصلت لصفر توقف حقيقي.

• انتظار DNS: تنقل الملفات ثم تغيّر عنوان IP في سجل A، فيبقى نصف زوارك يوصلون للسيرفر القديم ونصفهم للجديد لمدة قد تصل 48 ساعة حسب قيمة TTL. هذا أكبر سبب منفرد للتوقف الملموس.
• فقد بيانات اللحظة الأخيرة: تنسخ قاعدة البيانات الساعة العاشرة، ويستمر الموقع القديم يستقبل طلبات وتسجيلات حتى الساعة الثانية عشرة، فتضيع ساعتان من الطلبات لأنها كتبت على القديم بعد النسخ.
• اختلاف البيئة: إصدار PHP مختلف، أو امتداد مفقود، أو مسار خاطئ في ملف الإعداد، فيفتح الموقع على السيرفر الجديد بصفحة خطأ 500 لحظة التبديل. الاختبار المسبق يقتل هذا الاحتمال بالكامل.

الملاحظة المهمة أن السببين الأول والثالث يُحلّان بالتحضير قبل يوم النقل، والثاني يُحل بترتيب الخطوات في ساعة النقل نفسها. يعني 80% من العمل يصير قبل اللحظة الحرجة، وهذا بالضبط سر الهدوء يوم التبديل.

المرحلة الأولى: خفض DNS TTL قبل النقل بـ 48 ساعة

TTL أو Time To Live هو عدد الثواني التي يحتفظ بها كل خادم DNS في العالم بنسخة من سجلك قبل أن يسأل عنه مجدداً. القيمة الافتراضية عند أغلب مزودي النطاقات 3600 أو حتى 86400 ثانية، ما يعني أن تغييرك قد لا يصل لبعض الزوار قبل يوم كامل.

الخطوة العملية

• افتح لوحة إدارة DNS للنطاق قبل موعد النقل بـ 48 ساعة على الأقل.
• عدّل سجلات A و CNAME الرئيسية وخفّض TTL من 86400 إلى 300 ثانية (خمس دقائق).
• لا تغيّر عنوان IP بعد، فقط قيمة TTL. الهدف أن ينتشر انخفاض TTL نفسه أولاً.
• انتظر 48 ساعة كاملة حتى تنتهي صلاحية كل النسخ القديمة المخزّنة بقيمة TTL المرتفعة.

بعد مرور هذه المدة يصبح أي تغيير لاحق في عنوان IP ينتشر عالمياً خلال خمس دقائق بدل يوم. هذه الخطوة وحدها تختصر نافذة الخطر من 1440 دقيقة إلى 5 دقائق، أي بنسبة خفض تتجاوز 99%. حين تنقل إلى سيرفر داخل المملكة تستفيد إضافة أن زمن الاستجابة من الرياض ينزل إلى نحو 8ms مقابل 100 إلى 120ms للسيرفرات الخارجية، فالنقل هنا ترقية أداء لا مجرد تبديل مكان.

المرحلة الثانية: مزامنة الملفات على دفعتين

الخطأ الشائع نسخ الملفات مرة واحدة يوم النقل، وهذا يجبرك على تجميد الموقع ساعات كاملة إن كان حجمه كبيراً. الحل الاحترافي المزامنة على دفعتين باستخدام rsync الذي ينقل الفروقات فقط.

الدفعة الأولى: النسخة الكبيرة المبكرة

قبل النقل بيوم أو يومين، انسخ كل الملفات والموقع لا يزال يعمل بشكل طبيعي:

• استخدم أمراً مثل rsync -avz مع الضغط لتقليل زمن النقل عبر الشبكة.
• هذه الدفعة تأخذ الوقت الأطول لأنها تنقل كل شيء، وقد تستغرق ساعات لموقع بحجم عشرات الجيجابايت، لكنها تجري والموقع حي بلا أي أثر على الزوار.

الدفعة الثانية: النسخة التفاضلية السريعة

في ساعة النقل، شغّل rsync نفسه مرة ثانية على المجلد ذاته. هذه المرة ينقل الملفات التي تغيّرت فقط منذ الدفعة الأولى، فتكتمل خلال دقائق معدودة بدل ساعات. الفرق عملياً أن المزامنة الثانية قد تنقل أقل من 2% من حجم البيانات الكلي، لأن أغلب الملفات لم تتغيّر. بهذه الطريقة تنكمش نافذة النقل الفعلية من ساعات إلى دقائق، وهي أساس الوصول لصفر توقف على المواقع الكبيرة.

المرحلة الثالثة: نقل قاعدة البيانات دون فقد صف واحد

قاعدة البيانات أخطر من الملفات لأنها تتغيّر كل ثانية مع كل طلب أو تسجيل جديد. لو نسختها مبكراً مثل الملفات، ستفقد كل ما كُتب بعد النسخ. لذلك ترتيب الخطوات هنا حرج ولا يقبل الاجتهاد.

• فعّل وضع الصيانة للكتابة فقط: في اللحظة الأخيرة، امنع أي كتابة جديدة على السيرفر القديم مع إبقاء القراءة تعمل. هذا يجمّد حالة قاعدة البيانات نقطة ثابتة يمكن نسخها بأمان.
• خذ نسخة نظيفة: استخدم mysqldump مع خيار single-transaction لقاعدة InnoDB حتى تحصل على لقطة متسقة دون قفل الجداول طويلاً.
• استورد على الجديد وتحقق: استورد النسخة على السيرفر الجديد، ثم قارن عدد الصفوف في الجداول الحساسة مثل الطلبات والمستخدمين بين السيرفرين للتأكد من التطابق التام.

هذه المرحلة كلها يجب أن تكتمل في أقل من عشر دقائق لموقع متوسط، وكل دقيقة إضافية هنا هي دقيقة يبقى فيها الموقع مجمّد الكتابة. لهذا نجعلها آخر خطوة قبل التبديل مباشرة، وقد جهّزنا كل شيء آخر مسبقاً. لو كان موقعك يستقبل مئات الطلبات في الدقيقة، فكل دقيقة تأخير قد تعني عشرات المعاملات المعلّقة، فالسرعة هنا ليست ترفاً.

المرحلة الرابعة: اختبر الموقع الجديد قبل أن يراه أحد

قبل تحويل أي زائر للسيرفر الجديد، لازم تتأكد أنه يعمل 100%. الحيلة أن تخدع جهازك وحده ليرى السيرفر الجديد بينما بقية العالم لا يزال على القديم، وذلك بتعديل ملف hosts على حاسوبك.

خطوات الاختبار

• أضف سطراً في ملف hosts يربط اسم نطاقك بعنوان IP الجديد، فيصبح جهازك وحده يفتح النسخة الجديدة.
• تصفّح كل الصفحات الحساسة: الرئيسية، تسجيل الدخول، السلة، صفحة الدفع، لوحة التحكم.
• تحقق من إصدار PHP والامتدادات وشهادة SSL ومسارات الرفع والصلاحيات.
• جرّب عملية كتابة حقيقية مثل تسجيل حساب تجريبي للتأكد أن قاعدة البيانات تستقبل وتكتب سليم.

أكثر من نصف مشاكل ما بعد النقل تظهر في هذه المرحلة لو أُجريت بجدية: امتداد mysqli مفقود، أو إصدار PHP أقدم من متطلبات الإطار، أو شهادة SSL لم تُصدر بعد. حلّها الآن يكلّفك دقائق، وحلّها بعد التبديل يكلّفك توقفاً أمام الزوار. لا تبدّل DNS إطلاقاً قبل أن تمر كل صفحة اختبار بنجاح على ملف hosts.

المرحلة الخامسة: التبديل ثم التجميد المزدوج

وصلنا للحظة الحاسمة. الملفات متزامنة، قاعدة البيانات منقولة ومتحقق منها، والموقع الجديد نجح في كل الاختبارات. الآن نبدّل ونراقب.

• غيّر سجل A ليشير إلى عنوان IP الجديد. بفضل خفض TTL المبكر، ينتشر التغيير خلال خمس دقائق.
• أبقِ السيرفر القديم يعمل كامل المدة، لا تطفئه. سيستمر بعض الزوار يصلون إليه دقائق حتى تنتهي صلاحية النسخ المخزّنة.
• حافظ على تجميد الكتابة على السيرفر القديم طوال فترة الانتقال حتى لا يُكتب فيه صف جديد يضيع، فكل الكتابة الجديدة صارت على الجديد.

القاعدة الذهبية أن تُبقي السيرفر القديم شغّالاً 24 إلى 72 ساعة كاملة بعد التبديل. خلال هذه المدة راقب سجلات الوصول على الجديد حتى تصل نسبة الطلبات إليه إلى 100% تقريباً، وحينها فقط تتأكد أن كل خوادم DNS في العالم انتقلت. إطفاء السيرفر القديم مبكراً هو الخطأ الأخير الذي يفسد نقلاً ناجحاً، فبعض مزودي الإنترنت يتجاهلون TTL ويحتفظون بالنسخة القديمة أطول من المتوقع.

خطة التراجع: كيف ترجع بأمان لو ساءت الأمور

الاحترافية ليست ألا يحصل خطأ، بل أن تكون جاهزاً له. لأنك أبقيت السيرفر القديم يعمل، التراجع بسيط: أعد سجل A ليشير للعنوان القديم، وبفضل TTL المنخفض يرجع كل شيء خلال خمس دقائق. لكن انتبه لنقطة واحدة حاسمة: أي كتابة حصلت على السيرفر الجديد بعد التبديل لن تكون موجودة على القديم لو رجعت. لهذا يفضّل أخذ قرار التراجع بسرعة خلال أول ساعة، قبل تراكم بيانات كثيرة على الجديد.

لهذا نوصي عملاء كلاود بجدول زمني واضح: لو ظهر عطل جوهري خلال أول 60 دقيقة، ارجع فوراً للقديم وحلّل المشكلة بهدوء. بعد الساعة الأولى وتراكم البيانات، الأفضل عادةً إصلاح المشكلة على الجديد بدل التراجع. حين تنقل إلى بنية سعودية داخل المملكة تحصل على ميزة إضافية للتراجع والدعم: القرب الجغرافي وزمن استجابة 8ms يجعلان تشخيص أي مشكلة أسرع، وفريق التزويد التلقائي يفعّل بيئتك الجديدة خلال ثوانٍ فتختبر وتقارن دون انتظار. النقل الناجح ليس مغامرة، بل خطة مكتوبة بخمس مراحل وخطة تراجع جاهزة، ولو نفّذتها كما هي فموقعك ينتقل وزوارك لا يلاحظون شيئاً.