تحليل السجلات الثنائية لفهم تأخر النسخ المتماثل

تأخر النسخ، هذه الآفة الصامتة

لقد شهد كل DBA هذه اللحظة: تعرض المراقبة 300 ثانية خلف النسخة المتماثلة، وتتدفق التنبيهات، والسؤال هو نفسه دائمًا - لماذا؟

Seconds_Behind_Master (أو Seconds_Behind_Source في MySQL 8) هو مؤشر ثنائي: يتأخر أو لا يتأخر. لم يذكر شيئًا عن السبب. هل هذه دفعة ضخمة من الحذف؟ عدم وجود التوازي؟ معاملة بحجم 800 كيلو بايت تحظر سلسلة المحادثات SQL؟ لمعرفة ذلك، يجب عليك تحليل السجلات الرئيسية - والتي تتطلب الوصول إلى SSH، والثنائي الصحيح mysqlbinlog، والوقت، وgrep.

PmaControl الآن يقوم بأتمتة كل هذا.

الميزة الجديدة: تحليل Binlog

المبدأ

من صفحة التابع/العرض لأي نسخة طبق الأصل، يمكنك الآن:

1. حدد نطاقًا زمنيًا مباشرة على الرسم البياني للتأخر (انقر مع السحب بالماوس) أو عبر حقول التاريخ والوقت
2. ابدأ التحليل بنقرة واحدة - كل شيء يحدث في الخلفية
3. متابعة التقدم في الوقت الحقيقي خطوة بخطوة
4. عرض التقرير مع رسم بياني تفاعلي ومقاييس تفصيلية
5. تلقي إشعار Telegram مع الملخص

ماذا يحدث خلف الكواليس

عند تشغيل تحليل، يقوم PmaControl بتشغيل مسار مكون من 15 مرحلة:

[21:15:02] ✓ init — Analysis #42 — slave=85 master=106 range=[20:27:51 → 20:29:27]
[21:15:02] ✓ master_info — Master: prod-db-01 — 10.68.68.106:3306
[21:15:02] ✓ version — Version: 8.0.44
[21:15:02] ✓ binary — Using: mysqlbinlog-8.0 — Ver 8.0.42
[21:15:03] ✓ credentials — MySQL user: pmacontrol@10.68.68.106:3306
[21:15:04] ✓ find_binlogs — Found 1 binlog file(s): mysql-bin.046508
[21:15:18] ✓ fetch — Fetched mysql-bin.046508 — 101.0 MB (via --read-from-remote-server, cached)
[21:15:19] ✓ file_ranges — 1 file(s) probed
[21:15:45] ✓ parse_gtid — Parsed 36284 transactions, total 97.2 MB, 123 >100KB, 3 >500KB
[21:16:12] ✓ parse_dml — I:148,659 U:191,867 D:115,853 = 456,379 rows across 148 databases
[21:16:38] ✓ parse_volume — 97 seconds of data, peak 612 txn/s, peak 1807 KB/s
[21:16:39] ✓ parse_ddl — No DDL — 100% DML row-based
[21:16:39] ✓ metadata — 1 metadata file(s) written
[21:16:39] ✓ store — Report stored successfully
[21:16:39] ✓ cleanup — Cleanup done — analysis complete

كل خطوة تكون مرئية في الوقت الحقيقي في الواجهة، مع تفاصيل ما يحدث. لا مزيد من التخمين إذا كان النقل قيد التقدم أو إذا كان التحليل محظورًا. ملاحظة: يستخدم الاستلام بروتوكول MySQL (--read-from-remote-server)، وليس SSH — لا حاجة لنشر أي مفتاح على السيد.

الثنائي الصحيح للإصدار الصحيح

أحد المزالق الكلاسيكية: استخدام mysqlbinlog MariaDB لقراءة binlog MySQL 8، أو العكس. يتم وضع علامة "يمكن تجاهلها" على الأحداث وتصبح البيانات المستندة إلى الصفوف غير قابلة للقراءة.

PmaControl يقوم بتضمين 8 ثنائيات mysqlbinlog ثابتة (x86_64 و aarch64):

الاختيار تلقائي: PmaControl يقرأ المتغير version الخاص بالسيد في مقاييسه ويحدد أقرب ثنائي متوافق (راجع MysqlbinlogBinaryResolver). بالنسبة لـ MySQL Oracle، تتمثل الاستراتيجية في اختيار أقل إصدار ≥ إصدار السيد (التوافق الأمامي أكثر موثوقية من الخلفي). بالنسبة لـ MariaDB، يدعم الحل أيضًا ثنائيات أكثر دقة باسم mysqlbinlog-mariadb-10.11، mysqlbinlog-mariadb-11.8، إلخ — يتم نشرها عند الطلب عندما يكشف المضيف عن تنسيق binlog خاص بإصداره الفرعي.

تقرير التحليل

رسم بياني للحجم ثانيًا بثاني

يعرض الرسم البياني الرئيسي سلسلتين متراكبتين:

• الأشرطة الزرقاء: الحجم بالكيلوبايت/ثانية (مجموع transaction_length في الثانية)
• الخط البرتقالي: عدد المعاملات في الثانية

هذا هو أول رد فعل لـ DBA: هل يأتي التأخر من الذروة المحددة أم من التدفق المستمر؟ يستجيب الرسم البياني على الفور.

مقاييس التوازي MTS

هذا هو المكان الذي تكون فيه التحليلات مفيدة حقًا. يقوم PmaControl بتحليل الحقلين last_committed وsequence_number لكل حدث GTID لحساب:

• % من المعاملات المتسلسلة — تلك التي يكون فيها sequence_number = last_committed + 1، والتي لا يمكن موازنتها بواسطة التابع متعدد الخيوط
• الحد الأقصى لحجم مجموعة التوازي — عدد المعاملات التي يمكن تنفيذها فعليًا بالتوازي
• توزيع المجموعات — كم عدد المجموعات المكونة من 1، 2، 3... المعاملات

مثال ملموس: إذا كانت 31% من المعاملات متسلسلة والحد الأقصى للتوازي هو 7، فحتى مع 16 replica_parallel_workers، سيظل معظمها خاملاً. التوصية واضحة: قم بتفعيل binlog_transaction_dependency_tracking = WRITESET على السيد.

كشف المعاملات الكبيرة

المعاملات الكبيرة هي القاتل رقم 1 للنسخ المتماثل. معاملة واحدة بحجم 834 كيلو بايت تلامس 6171 صفًا تحظر مؤشر ترابط التطبيق SQL طوال مدته بأكملها - وتنتظر المعاملات الأخرى في الخلف.

PmaControl التهم:

• المعاملات > 100 كيلو بايت
• المعاملات > 500 كيلو بايت
• أكبر معاملة (بمحتوياتها: ما الجداول، كم عدد الصفوف)

أعلى الجداول

يسرد التقرير الجداول الثلاثين الأكثر تعديلاً مع تفاصيل INSERT/UPDATE/DELETE. غالبًا ما نجد هذا النمط السام: الدُفعات التي تقوم بـ DELETE FROM table WHERE ...; INSERT INTO table ... "لتحديث" البيانات بدلاً من استخدام INSERT ... ON DUPLICATE KEY UPDATE أو معاملات أصغر.

التوصيات التلقائية

اعتمادًا على المقاييس، يقدم PmaControl توصيات ملموسة:

• "نسبة المعاملات التسلسلية هي 31.3%. فكر في binlog_transaction_dependency_tracking = WRITESET."
• "3 معاملة (معاملات) > 500 كيلو بايت. تمنع المعاملات الكبيرة سلسلة تطبيق التطبيق SQL."
• "تم تعديل 148 قاعدة بيانات. قد يتسبب نمط المستأجرين المتعددين في ظهور نقاط فعالة للنسخ المتماثل."

هذه ليست نصائح عامة، بل يتم حسابها من البيانات الفعلية الموجودة في سجلاتك الثنائية.

إشعار برقية

عند اكتمال التحليل، يتم إرسال الملخص تلقائيًا عبر Telegram:

Binlog Analysis Complete
Slave: replica-prod-01
Master: master-prod-01 (8.0.44)
Range: 2026-04-13 20:27:51 → 2026-04-13 20:29:27
━━━━━━━━━━━━━━━━━━━
Size: 101.0 MB | Txn: 36,284 | Duration: 96s
DML: I:148,659 U:191,867 D:115,853 = 456,379 rows
Peak: 612 txn/s | Avg: 378.0 txn/s
Sequential: 31.3% | Max parallel: 7
Large txn: 123 >100K, 3 >500K (max 815 KB)
Databases: 148
━━━━━━━━━━━━━━━━━━━
• High write throughput (peak 612 txn/s). Ensure replica_parallel_workers >= 8.
• Sequential transaction ratio is 31.3%. Consider WRITESET.
• 3 transaction(s) > 500 KB. Large transactions block the SQL applier thread.

لدى DBA عند الطلب كل ما يحتاجه للعمل، مباشرة في جيبه.

الهندسة الفنية

استرداد Binlog: مثل سلسلة عمليات الإدخال والإخراج

PmaControl لا يستخدم SSH لاسترداد السجلات الثنائية. ويستخدم mysqlbinlog --read-from-remote-server الذي يتصل بالجهاز الرئيسي عبر بروتوكول MySQL، تمامًا مثل مؤشر ترابط الإدخال / الإخراج للنسخة المتماثلة. تعد بيانات الاعتماد MySQL وPmaControl كافية - ولا حاجة لمفتاح SSH على الجهاز الرئيسي.

mysqlbinlog --read-from-remote-server \
  --host=10.105.1.11 --port=3306 \
  --user=pmacontrol --password=*** \
  --raw --result-file=/tmp/analysis/ \
  mysql-bin.1054495

هذا يعني أنه إذا كان بإمكان PmaControl الاتصال بـ MySQL الخاص بالجهاز الرئيسي (وهو ما يفعله بالفعل للمراقبة)، فيمكنه استرداد السجلات الثنائية. لا يوجد تكوين إضافي.

الاكتشاف الذكي لملفات binlog

يمكن أن يحتوي سيد الإنتاج على الآلاف من ملفات binlog (واجهنا 2712 ملفًا أثناء التطوير). سيكون فحص كل ملف للعثور على النطاق الزمني أمرًا باهظًا.

استراتيجية الخطوتين:

1. التثبيت عبر موضع العبد — نقرأ Master_Log_File من SHOW SLAVE STATUS لمعرفة السجل الثنائي الحالي. نقرأ أيضًا SHOW MASTER STATUS على الماستر لمراعاة التأخر. وهذا يعطي نافذة ضيقة بدلاً من فحص جميع الملفات البالغ عددها 2712 ملفًا.

2. بحث ثنائي — في هذه النافذة، نقوم بالتحقق من الطابع الزمني الأول لكل ملف عبر mysqlbinlog --stop-position=8192 (يقرأ فقط رأس FORMAT_DESCRIPTION + الحدث الأول). باستخدام البحث الثنائي، فإن العثور على الملف الصحيح من بين 100 مرشح يستغرق 7 تحقيقات فقط بدلاً من 100.

النتيجة: يستغرق اكتشاف السجلات الثنائية على وحدة رئيسية تحتوي على 2712 ملفًا ثانيتين بدلاً من عدة دقائق.

ذاكرة تخزين مؤقت دائمة + ملف JSON المرافق للذكاء الاصطناعي

يتم تخزين السجلات الثنائية التي تم تنزيلها ضمن data/binlog_analysis/<id_السيد>/ مع TTL لمدة 30 يومًا. النتيجة المباشرة: إعادة تحليل نفس النطاق الزمني (أو نطاق مجاور يصيب نفس الملفات) مجاني من حيث الشبكة والوقت — تحصل فورًا على Cache hit: mysql-bin.046508.

لكل سجل binlog مخزن مؤقتًا، يكتب PmaControl أيضًا ملفًا مرافقًا mysql-bin.046508.meta.json يحتوي على ملخص منظم: إجمالي المعاملات، توازي MTS، أهم جداول DML، DDL، ذروة txn/s. تم تصميم هذا JSON ليستهلكه وكيل LLM (راجع صفحة وكلاء الذكاء الاصطناعي في الموقع) الذي يحتاج إلى التفكير في حادثة دون إعادة تحليل السجلات الثنائية بنفسه.

الثنائيات الثمانية الثابتة، ولماذا

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

مثال من الحياة الواقعية: قراءة mysqlbinlog MariaDB لـ MySQL 8.0 binlog تحدد الأحداث المستندة إلى الصفوف على أنها "يمكن تجاهلها" وتتخطاها. ينتقل عدد المعاملات من 36284 إلى 0. ولا يتم عرض أية أخطاء.

يتم استخراج الثنائيات من القطران الرسمي:

• MySQL 5.6 و5.7: منذ dev.mysql.com/get/Downloads/MySQL-5.x/
• MySQL 8.0 و8.4: منذ الحد الأدنى glibc2.17
• MySQL 9.2: إصدار الابتكار
• MariaDB: mariadb-binlog لتوزيع النظام

خطأ mysqlbinlog 5.6/5.7: --raw يتجاهل --stop-datetime

تم اكتشاف مأزق أثناء التطوير: في وضع --raw --read-from-remote-server، الإصدارات 5.6 و5.7 من mysqlbinlog تجاهل بصمت خياري --start-datetime و--stop-datetime. بدلاً من التوقف في التاريخ المطلوب، تتصرف العملية مثل سلسلة عمليات الإدخال والإخراج وتنتظر إلى أجل غير مسمى للأحداث الجديدة.

الحل في PmaControl: استخدم --raw بدون مرشح الوقت (تنزيل الملف الكامل، ثم يتوقف)، وتطبيق التصفية حسب النطاق الزمني فقط عند التحليل محليًا. تتم إضافة مهلة قدرها 120 ثانية لكل ملف للأمان.

خط أنابيب غير متزامن مع تقدم في الوقت الفعلي

يتم تشغيل التحليل في الخلفية عبر Glial CLI (php App/Webroot/index.php slave runBinlogAnalysisCli <id>). تقوم الواجهة الأمامية باستقصاء الحالة كل ثانيتين وتعرض التقدم في محطة مصممة. يقوم الحقل progress في JSON بتخزين كل خطوة مع الطابع الزمني والمرحلة والرسالة والحالة - 15 مرحلة من التهيئة إلى التنظيف.

تخزين النتائج

كل شيء ثابت في الجدول binlog_analysis:

• الحجم في الثانية (JSON)
• أعلى الجداول (JSON)
• التوزيع المتوازي (JSON)
• التوصيات (JSON)

يمكن الاطلاع على النتائج في أي وقت من تاريخ التحليل.

حالات الاستخدام الملموسة

"تأخر النسخة المتماثلة عند الساعة 3 صباحًا"

يظهر الرصد ذروة التأخر عند 3 ساعات. في صباح اليوم التالي، يختار DBA النطاق 02:55-03:10 على الرسم البياني ويبدأ التحليل. النتيجة: دفعة تحديث port_flux والتي تقوم بحذف + إدراج 15000 صف في معاملة واحدة على 148 قاعدة. الحل: تقسيم المعاملات إلى 500 صف.### "لماذا لا تلحق النسخة المتماثلة؟"

يزداد الفارق تدريجياً على الرغم من وجود 8 عمال متوازيين. يُظهر التحليل 35% من المعاملات المتسلسلة والحد الأقصى للتوازي 5. الحل: قم بتنشيط WRITESET على الجهاز الرئيسي وزيادة العدد إلى 16 عاملاً.

"ما هو تأثير هذه الدفعة؟"

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

كيفية استخدامه

1. افتح PmaControl → تابع → عرض على النسخة المتماثلة الخاصة بك
2. انقر واسحب على الرسم البياني للتأخر لتحديد نطاق
3. انقر فوق "تحليل Binlogs"
4. شاهد الخطوات تتكشف في الوقت الحقيقي
5. عرض التقرير، والتحقق من التوصيات
6. احصل على الملخص على Telegram

هذا كل شيء. لا يوجد SSH يدوي، ولا mysqlbinlog | grep | awk | sort، ولا يوجد برنامج نصي للصيانة. بنقرة واحدة تشخيص تأخر النسخ المتماثل.