المشكلة

بين يناير ومارس 2026، لاحظنا 6 عمليات إعادة ضبط غير طبيعية لوقت التشغيل على خادم إنتاج MariaDB 10.11.15 يشرف عليه PmaControl. يستضيف الخادم جداول RocksDB كبيرة جدًا ومقسمة (مقاييس السلاسل الزمنية).

رد الفعل الكلاسيكي لـ DBA عند مواجهة عطل: انظر إلى سجلات النظام. journalctl، dmesg، /var/log/syslog. نحن نبحث عن OOM، Killed process، segfault، kernel panic.

من أصل 6 أعطال، كان هناك واحد فقط به أثر نواة قابل للاستخدام. أما الخمسة الأخرى: صمت تام من جانب النظام.

طريقة الكشف

بدلاً من الثقة في سجلات النظام، استخدمنا PmaControl لاكتشاف الأعطال عبر السلسلة الزمنية uptime:

استرجاع قيم uptime عبر ts_value_general_int
تصفية عمليات إعادة التعيين غير الطبيعية (وقت التشغيل الذي ينخفض إلى 0)
الارتباط بالسجلات MariaDB (error.log)
الارتباط مع journalctl للبحث عن توقيعات النواة
تحليل المقاييس خلال الساعة السابقة (سلاسل العمليات، وحدة المعالجة المركزية، الذاكرة)

هذا هو الأسلوب الأكثر موثوقية: إعادة ضبط وقت التشغيل + توقيع InnoDB crash recovery = تعطل مؤكد، حتى بدون تتبع النظام.

تم تحديد الأعطال الستة

التاريخ	تصنيف	التوقيع الرئيسي
29 يناير	تحطم محتمل	`InnoDB crash recovery` + سجل الاسترداد
5 فبراير	تحطم محتمل	استعادة الأعطال + `Event invalid` في binlog
23 فبراير	تحطم محتمل	`InnoDB crash recovery` + `Crash table recovery`
3 مارس	تحطم محتمل	`Too many connections` ثم استعادة الأعطال
6 مارس	حادثة كبرى	فساد MyRocks: `truncated record body`, `.frm mismatch`
12 مارس	تم تأكيد الحادث	`systemd: status=9/KILL` + استعادة الأعطال

انهيار 6 مارس: الارتباط MDEV-39044

أخطر حادث كان يوم 6 مارس. وكانت الأخطاء مختلفة:

RocksDB: Error opening instance, Status Code: 2,
  Status: Corruption: truncated record body
Incorrect information in file: './pmacontrol/ts_value_general_int.frm'
Can't init tc log
Aborting

يتوافق هذا النمط تمامًا مع التذكرة MariaDB MDEV-39044: تلف MyRocks الناتج عن:

ALTER TABLE على جداول RocksDB الكبيرة المقسمة
عبء كتابة متواصل مرتفع جدًا
ضغط الذاكرة InnoDB المتزامن

تؤكد التذكرة صراحةً أن غياب سجل الأعطال أو قاتل OOM أمر طبيعي في هذا السيناريو.

لماذا سجلات النظام ليست كافية

من بين الحوادث الستة، عثر journalctl على أثر واحد قابل للاستغلال (status=9/KILL بتاريخ 12 مارس).

بالنسبة للـ 5 الآخرين:

لا Out of memory
لا Killed process
لا segfault
لا kernel panic

الاستنتاج بسيط: غياب توقيع النواة لا يعفي من حدوث عطل. ويتوافق هذا أيضًا مع النموذج MDEV-39044، الذي يوثق الأعطال دون تتبع النظام.

ما يكتشفه PmaControl أن السجلات لا تظهر

PmaControl يراقب uptime بشكل مستمر (كل 10 ثوانٍ). إعادة تعيين = تنبيه فوري. ثم يرتبط الوكيل تلقائيًا بما يلي:

مقاييس من الساعة السابقة (المواضيع، الذاكرة، وحدة المعالجة المركزية)
وجود crash recovery في سجل الأخطاء
أخطاء البيانات الوصفية (.frm mismatch)

وهذا يسمح بتصنيف الحادث حتى بدون التعاون من النواة .

التوصيات

لا تعتمد أبدًا على سجلات النظام فقط لاكتشاف الأعطال MariaDB
المراقبة uptime كمؤشر أساسي للاستقرار
ارتبط بسجل الأخطاء MariaDB، وليس مع journalctl
إذا كنت تستخدم RocksDB: قم بتقييد ملفات DDL على الجداول المقسمة الكبيرة، خاصة تحت تحميل الكتابة
اتبع MDEV-39044 للحصول على إصلاح محتمل لـ MyRocks

الخلاصة

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

هذا هو بالضبط دور PmaControl.

الأعطال الصامتة لـ MariaDB: عندما يخفي نقص السجلات حالة الطوارئ