عندما تفشل ترحيلات البيانات: استراتيجيات التراجع الفعّالة

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

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

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

النسخ الاحتياطي قبل الترحيل، وليس بعده

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

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

يُوضح المخطط الانسيابي التالي مسار اتخاذ القرار عند فشل الترحيل، مما يساعدك على اختيار طريقة التراجع المناسبة بناءً على الموقف.

flowchart TD A[تم إنشاء النسخة الاحتياطية قبل الترحيل] --> B[تشغيل الترحيل] B --> C{هل نجح الترحيل؟} C -->|نعم| D[تم] C -->|لا| E{اختيار طريقة التراجع} E -->|تغيير مدمر أو فقدان بيانات| F[الاسترداد في نقطة زمنية] E -->|تغيير قابل للعكس في المخطط| G[التراجع عن الإصدار - ترحيل هبوطي] E -->|توجد لقطة كاملة| H[استعادة اللقطة قبل الترحيل] F --> I[التحقيق في السبب الجذري] G --> I H --> I I --> J[إصلاح سكربت الترحيل] J --> B

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

التراجع عن إصدار الترحيل له حدود

معظم أطر عمل الترحيل تدعم الإصدارات الأمامية والخلفية. Flyway تسميها migrate و undo. Liquibase تسميها update و rollback. Alembic تسميها upgrade و downgrade. هذه الأدوات يمكنها عكس تغييرات المخطط عن طريق تشغيل سكربت ترحيل هبوطي.

المشكلة هي أن الترحيلات الهبوطية تعمل بأمان فقط للتغييرات القابلة للعكس. إضافة عمود قابل للقيم الخالية (nullable) هو تغيير قابل للعكس: الترحيل الهبوطي يحذف العمود، ولا يتم فقدان أي بيانات. إعادة تسمية عمود قابلة للعكس إذا أعاد الترحيل الهبوطي تسميته مرة أخرى. لكن التغييرات المدمرة قصة مختلفة. إذا حذفت عموداً، يمكن للترحيل الهبوطي إعادة إنشائه، لكن البيانات التي كانت في ذلك العمود اختفت. إذا قمت بتحويل البيانات من تنسيق إلى آخر، يمكن للترحيل الهبوطي عكس التحويل فقط إذا قمت بتخزين القيم الأصلية في مكان ما.

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

الاسترداد في نقطة زمنية محددة كشبكة أمان

أقوى استراتيجية تراجع لا تعتمد على سكربتات الترحيل على الإطلاق. الاسترداد في نقطة زمنية محددة يستخدم سجل معاملات قاعدة البيانات لاستعادة قاعدة البيانات إلى أي لحظة قبل بدء الترحيل.

إليك كيف يعمل. تقوم قاعدة البيانات باستمرار بكتابة سجلات المعاملات أو سجلات الكتابة المسبقة التي تسجل كل تغيير. إذا كان لديك هذه السجلات ونسخة احتياطية أساسية، يمكنك إعادة تشغيل السجلات حتى طابع زمني محدد. عندما يفشل الترحيل في الساعة 14:00، تقوم باستعادة قاعدة البيانات إلى 13:59، قبل بدء الترحيل. جميع التغييرات التي أجراها الترحيل تختفي، وتكون قاعدة البيانات في حالتها الأصلية بغض النظر عن مدى تدمير الترحيل.

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

هذا النهج يعمل مع أي ترحيل، بما في ذلك الترحيلات المدمرة. لا يهتم بما إذا كان الترحيل أضاف أعمدة، أو حذف جداول، أو حول ملايين الصفوف. إنه ببساطة يعيد الزمن إلى الوراء.

اختبر التراجع، وليس الترحيل فقط

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

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

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

بعد التراجع، تحقق قبل إعادة المحاولة

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

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

قائمة تحقق عملية للتراجع عن الترحيل

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

الخلاصة العملية

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