كيف تنقل موقعك دون توقف: خفض TTL والتشغيل المتوازي والتحويل الآمن لسجلات DNS

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

لماذا تتوقف المواقع أثناء النقل؟

التوقف يأتي غالبًا من أحد ثلاثة أسباب: إلغاء الاستضافة القديمة قبل اكتمال تحويل DNS، أو تخزين سجلات DNS مؤقتًا لساعات أو ليوم كامل فيستغرق التحويل وقتًا أطول بكثير من المتوقع، أو أن الخادم الجديد لم يكن جاهزًا تمامًا عند وصول الزيارات، كأن تكون شهادة SSL غير مركبة أو إصدار PHP مختلفًا أو صناديق البريد غير منشأة بعد. كل خطوة من الخطوات التالية تزيل أحد هذه الأسباب.

الجدول الزمني باختصار

1. اخفض قيمة TTL مبكرًا

قيمة TTL (مدة الصلاحية) تخبر خوادم DNS الوسيطة بالمدة التي يمكنها فيها الاحتفاظ بنسخة مؤقتة من السجل. إذا كانت قيمة TTL لسجل A هي 86400 ثانية (24 ساعة)، فقد يستغرق وصول التغيير إلى الجميع يومًا كاملًا. اخفض TTL للسجلات التي ستغيّرها، وهي عادة سجلات A للنطاق الرئيسي وwww، إلى 300 ثانية (5 دقائق). افعل ذلك قبل موعد التحويل بمدة لا تقل عن قيمة TTL القديمة كاملة، وإلا ستظل الخوادم الوسيطة محتفظة بالقيمة الطويلة القديمة.

غيّر سجلات A بدل تغيير خوادم الأسماء (Nameservers). تفويض خوادم الأسماء يُخزن مؤقتًا على مستوى سجل الامتداد نفسه بقيمة TTL طويلة لا يمكنك خفضها، لذلك يظل تغيير خوادم الأسماء هو التحويل الأبطأ دائمًا. وإذا أردت نقل إدارة DNS أيضًا، فاجعله خطوة منفصلة قبل نقل الخادم أو بعده بأيام.

2. جهّز الخادم الجديد وشغّله بالتوازي

• طابق البيئة البرمجية: خادم الويب، وإصدار PHP وإضافاته، وإصدار قاعدة البيانات.
• انسخ الملفات بأداة rsync عبر SSH (أو استعد نسخة كاملة على خوادم cPanel)، ثم استورد نسخة من قاعدة البيانات.
• ركّب شهادة SSL قبل التحويل. التحقق بملف HTTP لن يصل إلى الخادم الجديد ما دام DNS يشير إلى القديم، لذلك استخدم التحقق عبر DNS، أو انقل الشهادة الحالية ومفتاحها الخاص إلى الخادم الجديد بطريقة آمنة.
• اختبر عبر ملف hosts على جهازك: تصفح، وسجّل الدخول، وأرسل النماذج، وشغّل المهام المجدولة يدويًا، واقرأ سجل الأخطاء.

في هذه المرحلة يستطيع الخادمان تقديم الموقع، بينما ما زال القديم يستقبل كل الزيارات الحقيقية.

3. جمّد الكتابة ونفّذ المزامنة الأخيرة

الموقع الثابت أو قليل التحديث يمكن تحويله في أي وقت. أما الموقع الذي يكتب بيانات، مثل متجر أو نظام حجوزات أو منتدى، فيحتاج إلى تجميد قصير حتى لا يذهب طلب أو تعليق إلى قاعدة البيانات الخطأ:

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

في قواعد البيانات الكبيرة التي لا تحتمل حتى دقائق من التجميد، يمكن استخدام النسخ المتزامن (Replication) من الخادم القديم إلى الجديد لإبقائهما متطابقين حتى لحظة التحويل. هذا يتطلب VPS أو سيرفرًا مخصصًا تتحكم فيه بإعدادات قاعدة البيانات.

4. حوّل DNS وأبقِ الخادمين يعملان

غيّر سجلات A إلى عنوان IP الجديد. مع قيمة TTL تبلغ 300 ثانية ينتقل معظم الزوار خلال دقائق، لكن بعض الخوادم الوسيطة والأجهزة تتجاهل القيم القصيرة، فيظل الخادم القديم يستقبل طلبات قليلة لمدة يوم تقريبًا. أبقِه يعمل في وضع القراءة فقط، أو اضبطه كوسيط عكسي (Reverse Proxy) يمرر الطلبات إلى الخادم الجديد، حتى يجد الزائر المتأخر موقعًا يعمل ولا تُكتب بيانات في قاعدة البيانات القديمة. راقب سجلات الوصول على الخادمين: عندما يهدأ القديم تمامًا يكون التحويل قد اكتمل.

5. حافظ على استمرار البريد

البريد هو أكثر نقطة يفشل فيها «النقل دون توقف»، لأن خوادم البريد المرسلة تسلّم الرسائل إلى الخادم الذي كان يشير إليه سجل MX لحظة استعلامها عنه. هناك طريقتان آمنتان:

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

في الحالتين حدّث سجل SPF إذا تغير الخادم الذي يرسل رسائل الموقع، واضبط DKIM على الخادم الجديد، وإلا فقد تبدأ رسائل نماذج التواصل والطلبات في الوصول إلى مجلد الرسائل المزعجة. ويشرح دليل إعداد بريد الشركة سجلات MX وSPF وDKIM وDMARC.

6. بعد التحويل

• أعد قيمة TTL إلى قيمة طبيعية، مثل ساعة أو أكثر، بعد استقرار كل شيء.
• خذ نسخة احتياطية جديدة على الخادم الجديد، وتأكد أن النسخ المجدول يعمل.
• لا توقف الخادم القديم إلا بعد أن تُظهر سجلاته عدة أيام بلا أي زيارات أو بريد.

متى تناسبك هذه الطريقة؟

تفترض هذه الطريقة أنك تتحكم في DNS، ويفضل أن يكون لديك وصول إلى سطر الأوامر في الخادمين، وهذا هو الوضع المعتاد عند الانتقال إلى VPS لينكس. وبحسب سياسة الاستخدام في EngHosting، يصبح الـ VPS بعد تسليم بيانات الدخول مسؤولية العميل، وإدارة الخادم من الداخل خدمة منفصلة مدفوعة، لذلك حدّد مسبقًا من سينفّذ هذه الخطوات. أما النقل الأبسط بين حسابات استضافة مشتركة، فتغطيه قائمة مراجعة نقل الموقع إلى استضافة جديدة بكل بنود الحصر والاختبار.