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