لماذا تحتاج ترحيلات قواعد البيانات إلى قائمة تحقق خاصة بها

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

هذا السيناريو يحدث في الفرق التي تتعامل مع تغييرات قاعدة البيانات بنفس طريقة تعاملها مع تغييرات كود التطبيق. ملف المخاطر مختلف جوهريًا. عندما يتعطل كود التطبيق، يمكنك إعادة نشر الإصدار السابق. عندما يتعطل ترحيل قاعدة البيانات، لا يمكنك دائمًا التراجع عما تم فعله. قد تُفقد البيانات. قد تُنتهك القيود. قد يتغير المخطط (Schema) بطرق تجعل الاسترجاع البسيط مستحيلًا دون استعادة كاملة من النسخة الاحتياطية.

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

المشكلة في معاملة الترحيلات مثل نشر الكود

نشر الكود آمن نسبيًا لأنه قابل للعكس. تنشر الإصدار 2، به خطأ، تنشر الإصدار 1 مرة أخرى. يعيد التطبيق التشغيل بالكود القديم، ويواصل المستخدمون العمل.

ترحيلات قاعدة البيانات لا تعمل بهذه الطريقة. بمجرد تشغيل الترحيل:

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

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

قالب ترحيل قاعدة البيانات من خمس خطوات

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

يوضح المخطط الانسيابي التالي القالب المكون من خمس خطوات ونقاط القرار الرئيسية:

flowchart TD A[الخطوة 1: النسخ الاحتياطي] --> B[الخطوة 2: التشغيل التجريبي على بيئة واقعية] B --> C{هل نجح التشغيل التجريبي؟} C -- نعم --> D[الخطوة 3: تنفيذ الترحيل في الإنتاج] C -- لا --> E[إصلاح المشكلات] E --> B D --> F[الخطوة 4: التحقق من النتيجة] F --> G{هل نجح التحقق؟} G -- نعم --> H[الخطوة 5: مراقبة التأثيرات قصيرة المدى] G -- لا --> I[الاسترجاع أو الاستعادة] I --> A

الخطوة 1: النسخ الاحتياطي قبل أي شيء آخر

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

يجب أن تكون النسخة الاحتياطية قابلة للاستخدام لاستعادة الحالة الدقيقة قبل الترحيل. وهذا يعني:

يقوم نص الترحيل القابل للعكس بإقران التغيير الأمامي مع الاسترجاع، مما يوضح كيفية التراجع إذا لزم الأمر:

-- Up: إضافة عمود بقيمة افتراضية
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP DEFAULT NULL;

-- Down: إزالة العمود (آمن فقط إذا لم يعتمد عليه أي كود)
ALTER TABLE users DROP COLUMN last_login_at;
  • يجب اختبار صحة ملف النسخة الاحتياطية، وليس فقط إنشاؤه
  • يجب توثيق إجراءات الاستعادة وممارستها
  • بالنسبة للترحيلات عالية المخاطر، فإن النسخة الاحتياطية اليدوية المأخوذة مباشرة قبل الترحيل أفضل من الاعتماد على النسخ الاحتياطية اليومية الآلية

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

الخطوة 2: التشغيل التجريبي على بيئة واقعية

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

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

يجب أن تحتوي بيئة التشغيل التجريبي المناسبة على:

  • مخطط (Schema) مطابق للإنتاج
  • حجم بيانات قريب من الإنتاج، أو على الأقل ممثل لأكبر الجداول التي يتم تعديلها
  • موارد أجهزة مماثلة أو قيود موارد، خاصة لوحدة المعالجة المركزية (CPU) والإدخال/الإخراج (I/O)

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

الخطوة 3: تنفيذ الترحيل في الإنتاج

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

أثناء التنفيذ، راقب بنشاط:

  • كم من الوقت يستغرق كل بيان لاكتماله؟
  • هل هناك أقفال تمنع الاستعلامات الأخرى؟
  • هل لا يزال التطبيق يخدم الطلبات، أم أن الاتصالات تنتهي مهلة؟
  • هل تزداد معدلات الأخطاء في سجلات التطبيق؟

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

الخطوة 4: التحقق من النتيجة

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

تحقق من خلال:

  • التأكد من وجود الأعمدة الجديدة بأنواع البيانات الصحيحة
  • تأكيد أن تحويلات البيانات أنتجت القيم المتوقعة
  • تشغيل استعلام اختباري يستخدم المخطط المتغير
  • توصيل التطبيق بقاعدة البيانات والتحقق من أخطاء الاتصال

إذا أضاف الترحيل قيودًا، تحقق من أن البيانات الحالية تفي بها. إذا أزال الترحيل قيودًا، تحقق من أن التطبيق لا يزال يعمل بشكل صحيح بدونها.

الخطوة 5: مراقبة التأثيرات قصيرة المدى

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

راقب خلال الساعات القليلة التالية:

  • هل هناك استعلامات بطيئة جديدة في قاعدة البيانات؟
  • هل معدلات الأخطاء في التطبيق أعلى من ذي قبل؟
  • هل هناك حالات توقف تام (Deadlocks) لم تكن موجودة سابقًا؟
  • هل يستجيب التطبيق ضمن نطاقات زمن الاستجابة الطبيعية؟

استخدم أدوات المراقبة الحالية. لا تعتمد على فحص السجلات يدويًا. قم بإعداد تنبيهات لأي تدهور يرتبط بوقت الترحيل.

قائمة تحقق عملية لترحيلات قواعد البيانات

الخطوة الإجراء التحقق
النسخ الاحتياطي خذ نسخة احتياطية يدوية قبل الترحيل اختبر أن ملف النسخة الاحتياطية صالح وقابل للاستعادة
التشغيل التجريبي شغّل الترحيل على بيئة اختبارية ببيانات مشابهة للإنتاج قارن وقت التنفيذ، تحقق من الأخطاء، لاحظ مدة الإقفال
التنفيذ شغّل الترحيل خلال انخفاض الحركة راقب مدة البيانات، الأقفال، أخطاء التطبيق
التحقق تحقق من المخطط والبيانات بعد الترحيل تأكد من الأعمدة والقيود واتصال التطبيق
المراقبة راقب تغييرات الأداء لمدة 2-4 ساعات تحقق من الاستعلامات البطيئة، معدلات الأخطاء، حالات التوقف التام

الخلاصة

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