حضّر الخادم الجديد واختبره أولاً، وانسخ البيانات بطريقة اتساق تدعمها التطبيقات، وحدّد نافذة تحويل، واحفظ البيئة القديمة. يجب أن يراعي التراجع الكتابات المقبولة على الخادم الجديد، وليس تغيير DNS فقط.
اجرد الخدمة قبل نقل الجهاز
يشمل الترحيل أكثر من ملفات التطبيق. اسرد قواعد البيانات والتحميلات والمهام المجدولة وعمال الطوابير والشهادات والنطاقات والأسرار والتكاملات الصادرة. سجّل إصدارات البرمجيات وافتراضات التشغيل المهمة، مثل أذونات الملفات ومسارات التخزين. قد يكشف خادم مخصص جديد عن تبعية منسية ثُبّتت بهدوء قبل سنوات على البيئة القديمة.
عيّن مسؤولاً لقرار التحويل وحدّد كيف يبدو النجاح. ضمّن فحوصاً مرئية للمستخدم واتساق البيانات والقدرة على استعادة الوصول. تأكد من تسليم الإعداد الجديد وقابليته للاستخدام قبل الإعلان عن موعد الترحيل. تأكيد الطلب أو مواصفات عتاد مدرجة ليسا مثل وجهة عاملة جاهزة لاستقبال بيانات الإنتاج.
ابنِ الوجهة كبيئة منفصلة
ثبّت الحزمة المطلوبة، وأنشئ الإدارة، واضبط الجدار الناري المقصود. أبقِ الأسرار خاصة واضبط أذونات الخدمة عن قصد. تحقق من اسم المضيف المتوقع للتطبيق وسلوك الشهادة قبل نقل الحركة العامة. توضح وثائق المضيف الافتراضي لـ Apache لماذا يعد توجيه اسم المضيف قرار إعداد منفصلاً عن عنوان الخادم. صفحة افتراضية عاملة لا تثبت أن مضيف التطبيق الصحيح مُعدّ.
استخدم مجموعة بيانات مستعادة تمثيلية للتجربة، مع تعطيل البريد الصادر والمدفوعات والمهام المجدولة أو إعادة توجيهها إلى أنظمة اختبار آمنة. يمنع ذلك بيئة الاختبار من التصرف بناءً على مستخدمين حقيقيين. اختبر تسجيل الدخول والتحميلات والعمل في الخلفية والاستعادة. سجّل الإجراء ومدته حتى تستند النافذة الحقيقية إلى عملية ملاحَظة لا إلى التفاؤل.
اختر حداً متسقاً للبيانات
استخدم طريقة نسخ احتياطي أو تكرار تدعمها قاعدة البيانات والتطبيق. يميّز PostgreSQL بين تفريغات SQL ونسخ نظام الملفات والأرشفة المستمرة، ولكل منها افتراضاته. تشير إرشادات التفريغ لديه إلى أن تفريغات قاعدة البيانات يمكن أن تكون متسقة داخلياً بينما تحتاج الأدوار على مستوى العنقود وتفاصيل أخرى إلى معالجة منفصلة. اقرأ متطلبات النظام المحدد الذي تشغله بدلاً من نسخ ملفات البيانات المفتوحة دون تمييز.
خطط لكيفية ارتباط قاعدة البيانات بالتحميلات وحالة الطوابير. إذا أشار سجل إلى ملف نُسخ في وقت مختلف، فقد يكون التطبيق المستعاد غير مكتمل حتى لو نجحت النسختان كل على حدة. قرر ما إذا كنت ستوقف الكتابات لفترة وجيزة، أو تستخدم ترتيب تكرار مختبراً، أو تنفذ تصديراً خاصاً بالتطبيق. أبقِ قرار الاتساق هذا صريحاً في دليل التشغيل.
| المرحلة | الدليل المطلوب | القرار |
|---|---|---|
| التجربة | نجاح التطبيق والبيانات المستعادة في الفحوص | يمكن اعتبار الوجهة للتحويل |
| المزامنة النهائية | نقطة استعادة متسقة محددة | تابع فقط مع التغييرات المتبقية المفهومة |
| تحويل الحركة | سلوك التوجيه والشهادة الصحيح | راقب الوجهتين |
| التراجع | موقع كل الكتابات المقبولة حديثاً | سوِّ البيانات قبل إعادة الحركة |
حضّر توجيه الحركة دون الوعد بتغييرات فورية
يتحكم DNS في مدة البقاء (TTL) التي تحدد مدة تخزين السجلات مؤقتاً، كما هو موضح في وثائق DNS من Cloudflare. راجع TTL مبكراً إذا كان DNS جزءاً من الترحيل، واسمح للسجلات المخزنة مؤقتاً بالتقادم وفق إعدادها السابق. تغيير القيمة لحظة التحويل لا يمكنه تقصير كل إجابة مخزنة مؤقتاً بأثر رجعي. قد يصل عملاء مختلفون إلى وجهات مختلفة أثناء الانتقال.
أبقِ البيئة القديمة متاحة بينما تستقر تغييرات التوجيه، مع سياسة مدروسة لما إذا كانت لا تزال تقبل الكتابات. تجنب تشغيل مستهلكي طوابير أو مهام مجدولة مكررة إلا إذا كان التطبيق مصمماً لذلك. راقب الطلبات على الجانبين وتأكد من اسم المضيف المقصود وشهادة TLS وإصدار التطبيق من عملاء مستقلين.
حدّد التراجع بعد بدء الكتابات
قبل أن يقبل النظام الجديد التغييرات، قد تكون إعادة حركة المرور بسيطة نسبيًا. بعد ذلك، قد يؤدي مجرد عكس DNS إلى فقدان العمل أو إنشاء تاريخين متعارضين. حدد كيفية الحفاظ على السجلات والتحميلات المنشأة حديثًا أو التوفيق بينها. إذا لم يستطع التطبيق دمجها بأمان، فقد تكون فترة صيانة مضبوطة أفضل من عودة مرتجلة إلى النسخة القديمة.
حدد الشروط التي تستدعي إيقاف الترحيل مؤقتًا، وأبقِ صاحب قرار الإيقاف متاحًا. احتفظ بالسجلات والأدلة المفيدة وفق قواعد الاحتفاظ الخاصة بالمشروع. لا تحذف الجهاز القديم أو نسخة الاسترداد المستقلة الخاصة به لمجرد أن الصفحة الرئيسية حُمّلت مرة واحدة. يجب أن تغطي فترة الاحتفاظ احتياجات التحقق والتراجع المتفق عليها.
أغلق الترحيل بفحوص تشغيلية
بعد التحويل، تحقق من النسخ الاحتياطية والتنبيهات وتجديد الشهادات والعمل المجدول واسترداد الوصول. تأكد من أن المضيف المراقب هو الوجهة الجديدة وأنه لم تبقَ أي تكاملات اختبارية في بيئة الإنتاج. راجع أخطاء التطبيق وأوقات الاستجابة المرئية للمستخدم تحت حركة المرور العادية. حدّث الجرد ودليل التشغيل حتى لا يضطر المسؤول التالي إلى استنتاج ما تغير.
تقدم عائلات SwissOctet المخصصة تكوينات مادية مختلفة، لكن يجب تأكيد أعمال الترحيل والمساعدة المُدارة للخدمة المختارة. استخدم الكتالوج لاختيار الموارد المناسبة، ثم ابنِ عملية نقل مُختبرة حول بيانات تطبيقك. يكتمل الترحيل عندما تعمل الخدمة وعملية الاسترداد الخاصة بها على الوجهة، وليس فقط عند نقل الملفات.
قائمة التحقق العملية.
- اجرد البيانات والمهام والأسرار والتكاملات.
- تحقق من الوجهة المُسلّمة قبل الجدولة.
- تدرّب باستخدام تكاملات خارجية آمنة.
- حدد اتساق قاعدة البيانات والتحميلات.
- خطط لانتقال التوجيه ومنع تكرار المهام.
- حدد آلية التراجع عن الكتابات الجديدة.
- تحقق من النسخ الاحتياطية والمراقبة بعد التحويل.
التفاصيل المهمة.
هل يمكنني الترحيل بنسخ دليل التطبيق؟+
فقط إذا كان ذلك يلتقط كل ما تحتاجه الخدمة ويحافظ على الاتساق. عادةً تتطلب قواعد البيانات والتحميلات والمهام والأسرار والتكوين اهتمامًا منفصلًا.
هل يؤدي خفض مدة صلاحية DNS إلى تحويل فوري؟+
لا. يمكن أن تبقى الإجابات المخزنة مؤقتًا سابقًا حتى انتهاء عمرها السابق، وقد يحدّث العملاء في أوقات مختلفة.
هل التراجع مجرد توجيه DNS إلى الخادم القديم؟+
ليس بعد أن يقبل الخادم الجديد عمليات الكتابة. يجب أن تراعي تلك السجلات والملفات قبل إعادة حركة المرور.
اذهب إلى المصدر.
تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.
- PostgreSQL: النسخ الاحتياطي والاستعادة www.postgresql.org
- PostgreSQL: اتساق تفريغ SQL واستعادته www.postgresql.org
- Apache: توثيق المضيف الافتراضي httpd.apache.org
- Cloudflare DNS: مدة الصلاحية developers.cloudflare.com
إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.