ما علامات التحذير التي تشير إلى أن حاوية قاعدة البيانات قد تعرضت للتلف بسبب انقطاع التيار الكهربائي؟

إيفا وونغ

IceWhale author

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

What Are the Warning Signs That a Database Container Was Corrupted by Power Loss?

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

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

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

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

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

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

ابحث عن أخطاء المجموع الاختباري والصفحات غير الصالحة

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

يوضح pganalyze أن تلف PostgreSQL يظهر على شكل فشل المجموع الاختباري للصفحة يتبعه خطأ في الصفحة غير الصالحة عند قراءة الكتلة المتضررة.

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

راقب الاستعلامات التي تفشل مع صفوف أو جداول محددة فقط

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

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

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

تحقق من حالات عدم اتساق الفهارس والمعاملات والبيانات الوصفية

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

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

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

اربط أخطاء قاعدة البيانات بتحذيرات نظام الملفات والتخزين

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

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

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

أوقف عمليات الكتابة وأثبت إمكانية الاسترداد من نسخة احتياطية سليمة

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

تحدد قائمة ZimaSpace المرجعية الخاصة بـ النسخ الاحتياطي لحالة تطبيق Docker ما يجب توفره قبل محاولة استرداد مدمرة لقاعدة البيانات.

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