ماذا يحدث بعد نجاح ترحيل قاعدة البيانات؟

ينتهي ترحيل قاعدة البيانات دون أخطاء. تظهر خط أنابيب CI/CD باللون الأخضر. يتنفس الفريق الصعداء. لكن بعد ساعة، يبدأ المستخدمون في الإبلاغ أن الصفحات تتحمّل ببطء. بعض الاستعلامات تنتهي بانتهاء المهلة. بعض استدعاءات API ترجع أخطاء 500. نجح الترحيل تقنيًا، لكن شيئًا ما حدث خطأ في الخلفية.

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

لماذا رموز النجاح غير كافية

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

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

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

تحقق من حالة الترحيل بشكل صحيح

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

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

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

قارن زمن استجابة الاستعلام قبل وبعد

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

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

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

تحقق من الأقفال التي لم تُحرر

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

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

شغّل هذا الاستعلام لترى ما إذا كانت أي أقفال لا تزال محتجزة على الجدول الذي رحّلته:

SELECT
    pg_locks.pid,
    pg_locks.mode,
    pg_locks.granted,
    pg_class.relname,
    pg_stat_activity.query,
    pg_stat_activity.state,
    pg_stat_activity.wait_event_type || ': ' || pg_stat_activity.wait_event AS wait
FROM pg_locks
JOIN pg_class ON pg_locks.relation = pg_class.oid
JOIN pg_stat_activity ON pg_locks.pid = pg_stat_activity.pid
WHERE pg_class.relname = 'your_table_name'
  AND pg_locks.granted = true;

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

تحقق من عدد الصفوف لترحيلات تغيير البيانات

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

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

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

راقب سجلات التطبيق بحثًا عن أخطاء قاعدة البيانات

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

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

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

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

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

يُوضح المخطط الانسيابي التالي التسلسل الموصى به لخطوات التحقق:

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

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

الخلاصة

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