السياق

في 6 مارس 2026، تعرض خادم الإنتاج MariaDB 10.11.15 الذي يشرف عليه PmaControl إلى حادث كبير. على عكس الأعطال المعتادة (OOM، segfault)، قدم هذا الحادث أعراضًا جديدة:

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

تمت إعادة تشغيل الخادم في حلقة عدة مرات قبل الاستقرار، مع وجود أخطاء .frm mismatch في العديد من جداول السلاسل الزمنية.

تذكرة MDEV-39044

بعد التحقيق، قمنا بربط هذه الحادثة بالتذكرة MariaDB MDEV-39044:

تلف MyRocks بعد إعادة التشغيل أثناء/بعد تغيير عبء العمل: الفساد: نص السجل المقطوع، عدم تطابق .frm، لا يوجد سجل أعطال، لا يوجد قاتل OOM*

ما تصفه التذكرة

توثق التذكرة سيناريو الفساد القابل للتكرار:

جداول RocksDB الكبيرة المقسمة — بالضبط ما يستخدمه PmaControl للمقاييس (جداول ts_value_* المقسمة على أساس يومي)
ALTER TABLE تحت تحميل الكتابة — إضافة أقسام أثناء قيام التطبيق بالكتابة بشكل مستمر
ضغط الذاكرة InnoDB المتزامن — يتواجد جدولا InnoDB وRocksDB معًا على نفس الخادم
لا يوجد أثر للنواة — لا يوجد قاتل OOM، ولا يوجد خطأ segfault، ولا يوجد سجل أعطال

لماذا هو غدرا

أخطر نقطة في التذكرة: غياب سجل الأعطال هو السلوك المتوقع في هذا السيناريو. تتم إعادة تشغيل الخادم، ويقوم بإجراء InnoDB crash recovery، ولكن بيانات تعريف RocksDB تالفة (.frm mismatch).

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

حالتنا الملموسة

الجداول المتأثرة

جميع جداول RocksDB مقسمة حسب اليوم، ويتم طلبها كتابيًا على نطاق واسع:

ts_value_general_int — مقاييس الأعداد الصحيحة (متغيرات الحالة، والعدادات)
ts_value_general_json — مقاييس JSON المعقدة
ts_mysql_digest_stat — إحصائيات الاستعلام (الملخصات)
ts_value_general_text — المقاييس النصية
ts_value_slave_int — مقاييس النسخ المتماثل
ts_value_slave_text — حالات النسخ المتماثل التفصيلية

المحفز المحتمل

PmaControl يحافظ على أقسام هذه الجداول تلقائيًا: إضافة قسم اليوم التالي، وحذف الأقسام منتهية الصلاحية. يتم تنفيذ هذه ALTER TABLE ... ADD PARTITION / DROP PARTITION على جداول تبلغ مساحتها عدة عشرات من الجيجابايت، بينما يكتب عمال الفراغ بشكل مستمر (كل 10 ثوانٍ لكل خادم خاضع للإشراف).

إشارات ضغط الذاكرة

قبل التعطل، يُظهر السجل MariaDB:

InnoDB: Memory pressure event disregarded

تشير التذكرة MDEV-39044 بوضوح إلى هذا السبب كعامل مشدد. لا يتسبب ضغط الذاكرة InnoDB في حدوث تلف مباشر، ولكنه ينشئ السياق الذي يصبح فيه RocksDB DDL غير ذري.

كيف اكتشف PmaControl الحادثة

تم اكتشاف إعادة ضبط وقت التشغيل خلال 10 ثوانٍ عبر السلسلة الزمنية ts_variable.uptime
تنبيه برقية يتم إرساله فورًا
الارتباط التلقائي مع سجل الأخطاء: اكتشاف توقيعات crash recovery + truncated record body
تحليل بأثر رجعي: كانت المقاييس من الساعة السابقة (سلاسل العمليات، والذاكرة، ووحدة المعالجة المركزية) طبيعية - مما يؤكد أن هذه ليست مشكلة تحميل نموذجية

التوصيات

إجراءات فورية

لا تقم بتشغيل DDL على جداول RocksDB تحت تحميل الكتابة . جدول ALTER TABLE ... ADD/DROP PARTITION خلال فترات النشاط المنخفض.
مراقبة .frm الأخطاء في سجل الأخطاء. هذا هو المؤشر الأول لفساد ما بعد DDL.
اتبع التذكرة MDEV-39044 للإصلاح الرسمي.

الإجراءات الهيكلية

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

ما ليس كذلك

هذه ليست مشكلة في الأجهزة (القرص، ذاكرة الوصول العشوائي)
هذه ليست مشكلة في تكوين MySQL (الإعدادات صحيحة)
هذا غير قابل للتكرار عند الطلب (هذه حالة سباق في محرك RocksDB/DDL)

هذا خطأ في المحرك تم توثيقه بواسطة MariaDB أنفسهم.

الخلاصة

يعد MDEV-39044 بمثابة تذكير بأن استخدام محركات التخزين البديلة (RocksDB وTokuDB) في أحمال عمل الإنتاج يتطلب يقظة خاصة بشأن DDL. عدم وجود سجلات الأعطال لا يعني عدم وجود الفساد.

يكتشف PmaControl هذه الحوادث من خلال مراقبة uptime + ارتباط سجل الأخطاء، حيث لا ترى الأدوات التقليدية شيئًا.

MyRocks تحت التحميل: عندما يتسبب ALTER TABLE في حدوث تلف