استكشاف أخطاء زمن انتقال النسخ المتماثل وإصلاحها في قاعدة بيانات Azure ل MySQL - الخادم المرن
ينطبق على: 
قاعدة بيانات Azure ل MySQL - خادم واحد قاعدة بيانات Azure ل MySQL - خادم مرن
هام
قاعدة بيانات Azure لخادم MySQL الفردي على مسار الإيقاف. نوصي بشدة بالترقية إلى قاعدة بيانات Azure لخادم MySQL المرن. لمزيد من المعلومات حول الترحيل إلى خادم Azure Database for MySQL المرن، راجع ما الذي يحدث لقاعدة بيانات Azure لخادم MySQL الفردي؟
إشعار
تشير هذه المقالة إلى مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، بالتالي سنزيله من هذه المقالة.
تسمح لك ميزة النسخ المتماثل للقراءة بنسخ البيانات قاعدة بيانات Azure لخادم MySQL إلى خادم للقراءة فقط. يمكنك توسيع نطاق أعباء العمل عن طريق توجيه استعلامات القراءة وإعداد التقارير من التطبيق إلى خوادم النسخ المتماثل. يقلل هذا الإعداد من الضغط على الخادم المصدر ويحسن الأداء العام وزمن الانتقال للتطبيق أثناء تحجيمه.
يتم تحديث النسخ المتماثلة بشكل غير متزامن باستخدام تقنية النسخ المتماثل المستند إلى موضع السجل الثنائي الأصلي لمحرك MySQL (binlog). لمزيد من المعلومات، راجع نظرة عامة على تكوين النسخ المتماثل المستند إلى موضع ملف MySQL binlog.
يعتمد تأخر النسخ المتماثل على النسخ المتماثلة الثانوية للقراءة على عدة عوامل. وتشمل هذه العوامل على سبيل المثال لا الحصر:
- زمن وصول الشبكة.
- حجم المعاملات على الخادم المصدر.
- حساب طبقة الخادم المصدر وخادم النسخ المتماثل الثانوي للقراءة.
- الاستعلامات التي تعمل على الخادم المصدر والخادم الثانوي.
في هذه المقالة، ستتعلم كيفية استكشاف أخطاء زمن انتقال النسخ المتماثل وإصلاحها في قاعدة بيانات Azure لـ MySQL. ستحصل أيضا على فكرة أفضل عن بعض الأسباب الشائعة لزيادة زمن انتقال النسخ المتماثل على خوادم النسخ المتماثلة.
إشعار
تحتوي هذه المقالة على مراجع لمصطلح slave، وهو مصطلح لم تعد Microsoft تستخدمه. عند إزالة المصطلح من البرنامج، بالتالي سنزيله من هذه المقالة.
مفاهيم النسخ المتماثل
عند تمكين سجل ثنائي، يكتب الخادم المصدر المعاملات الملتزم بها في السجل الثنائي. يتم استخدام السجل الثنائي للنسخ المتماثل. يتم تشغيله افتراضياً لجميع الخوادم التي تم توفيرها حديثاً والتي تدعم ما يصل إلى 16 تيرابايت من السعة التخزينية. على خوادم النسخ المتماثلة، يتم تشغيل مؤشري ترابط على كل خادم نسخة متماثلة. أحدهما مؤشر ترابط IO، والآخر هو مؤشر ترابط SQL:
- يتصل مؤشر ترابط IO بالخادم المصدر ويطلب السجلات الثنائية المحدثة. يتلقى مؤشر الترابط هذا تحديثات السجل الثنائي. يتم حفظ هذه التحديثات على خادم نسخة متماثلة، في سجل محلي يسمى سجل الترحيل.
- يقرأ مؤشر ترابط SQL سجل الترحيل ثم يطبق تغييرات البيانات على خوادم النسخ المتماثلة.
مراقبة زمن وصول النسخ المتماثل
تُوفر قاعدة بيانات Azure لـ MySQL مقياس تأخّر النسخ المتماثل بالثواني في مراقبة Azure. يتوفر هذا المقياس فقط على خوادم النسخ المتماثلة للقراءة. يتم حسابه بواسطة مقياس seconds_behind_master المتوفر في MySQL.
لفهم سبب زيادة زمن انتقال النسخ المتماثل، اتصل بخادم النسخ المتماثل باستخدام MySQL Workbench أو Azure Cloud Shell. ثم تشغيل الأمر التالي.
إشعار
في التعليمات البرمجية الخاصة بك، استبدل قيم المثال باسم خادم النسخة المتماثلة واسم مستخدم المسؤول. يتطلب @\<servername> اسم المستخدم المسؤول لقاعدة بيانات Azure لـ MySQL.
mysql --host=myreplicademoserver.mysql.database.azure.com --user=myadmin@mydemoserver -p
إليك كيف تبدو التجربة في المحطة الطرفية Cloud Shell:
Requesting a Cloud Shell.Succeeded.
Connecting terminal...
Welcome to Azure Cloud Shell
Type "az" to use Azure CLI
Type "help" to learn about Cloud Shell
user@Azure:~$mysql -h myreplicademoserver.mysql.database.azure.com -u myadmin@mydemoserver -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 64796
Server version: 5.6.42.0 Source distribution
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
قم بتشغيل الأمر التالي في المحطة الطرفية Azure Cloud Shell:
mysql> SHOW SLAVE STATUS;
فيما يلي الإخراج النموذجي:
يحتوي الإخراج على العديد من المعلومات. عادة، تحتاج إلى التركيز على الصفوف التي يصفها الجدول التالي فقط.
| مقياس | الوصف |
|---|---|
| Slave_IO_State | يمثل الحالة الحالية لمترابط IO. عادةً ما تكون الحالة "في انتظار قيام الرئيسي بإرسال الحدث" إذا كان خادم المصدر (الرئيسي) قيد المزامنة. تشير حالة مثل "الاتصال بالخادم الرئيسي" إلى أن النسخة المتماثلة فقدت الاتصال بالخادم المصدر. تأكد من تشغيل الخادم المصدر، أو تحقق لمعرفة ما إذا كان جدار الحماية يمنع الاتصال. |
| Master_Log_File | يمثل ملف السجل الثنائي الذي يكتب إليه الخادم المصدر. |
| Read_Master_Log_Pos | يشير إلى مكان كتابة الخادم المصدر في ملف السجل الثنائي. |
| Relay_Master_Log_File | يمثل ملف السجل الثنائي الذي يقرأه خادم النسخة المتماثلة من الخادم المصدر. |
| Slave_IO_Running | يشير إلى ما إذا كان مؤشر ترابط IO قيد التشغيل. يجب أن تكون القيمة Yes. إذا كانت القيمة هي NO، فمن المحتمل أن يكون النسخ المتماثل مقطوعاً. |
| Slave_SQL_Running | يشير إلى ما إذا كان مؤشر ترابط SQL قيد التشغيل. يجب أن تكون القيمة Yes. إذا كانت القيمة هي NO، فمن المحتمل أن يكون النسخ المتماثل مقطوعاً. |
| Exec_Master_Log_Pos | يشير إلى موضع Relay_Master_Log_File الذي تطبقه النسخة المتماثلة. إذا كان هناك زمن انتقال، فيجب أن يكون تسلسل الموضع هذا أصغر من Read_Master_Log_Pos. |
| Relay_Log_Space | يشير إلى الحجم الإجمالي المدمج لكافة ملفات سجل الترحيل الموجودة. يمكنك التحقق من حجم الحد الأعلى عن طريق الاستعلام SHOW GLOBAL VARIABLES مثل relay_log_space_limit. |
| Seconds_Behind_Master | يعرض زمن انتقال النسخ المتماثل في ثوان. |
| Last_IO_Errno | يعرض رمز خطأ مؤشر ترابط IO، إن وجد. لمزيد من المعلومات حول هذه التعليمات البرمجية، راجع مرجع رسالة خطأ خادم MySQL. |
| Last_IO_Errno | يعرض رمز خطأ مؤشر ترابط IO، إن وجد. |
| Last_SQL_Errno | يعرض رمز الخطأ مؤشر ترابط SQL، إن وجد. لمزيد من المعلومات حول هذه التعليمات البرمجية، راجع مرجع رسالة خطأ خادم MySQL. |
| Last_SQL_Error | يعرض رسالة الخطأ مؤشر ترابط SQL، إن وجدت. |
| Slave_SQL_Running_State | يشير إلى حالة مؤشر ترابط SQL الحالية. في هذه الحالة، System lock هو طبيعي. من الطبيعي أيضاً رؤية حالة Waiting for dependent transaction to commit. تشير هذه الحالة إلى أن النسخة المتماثلة تنتظر مؤشرات ترابط عامل SQL الأخرى لتحديث المعاملات الملتزم بها. |
إذا كان Slave_IO_Running هو Yes Slave_SQL_Running هو Yes، فإن النسخ المتماثل يعمل بشكل جيد.
بعد ذلك، تحقق من Last_IO_Errno و Last_IO_Error و Last_SQL_Errno و Last_SQL_Error. تعرض هذه الحقول رقم الخطأ ورسالة الخطأ للخطأ الأحدث الذي تسبب في توقف مؤشر ترابط SQL. يعني رقم الخطأ 0 ورسالة فارغة عدم وجود خطأ. تحقق من أي قيمة خطأ غير صفرية عن طريق التحقق من رمز الخطأ في مرجع رسالة خطأ خادم MySQL.
السيناريوهات الشائعة لزمن انتقال النسخ المتماثل العالي
تتناول المقاطع التالية سيناريوهات حيث زمن الوصول النسخ المتماثل عالية شائعة.
زمن انتقال الشبكة أو استهلاك وحدة المعالجة المركزية العالي على الخادم المصدر
إذا رأيت القيم التالية، فمن المحتمل أن يكون السبب في زمن انتقال النسخ المتماثل هو زيادة زمن انتقال الشبكة أو ارتفاع استهلاك وحدة المعالجة المركزية على الخادم المصدر.
Slave_IO_State: Waiting for master to send event
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller than Master_Log_File, e.g. mysql-bin.00010
في هذه الحالة، يتم تشغيل مؤشر ترابط IO وينتظر على الخادم المصدر. لقد كتب الخادم المصدر بالفعل إلى رقم ملف السجل الثنائي 20. تلقت النسخة المتماثلة حتى رقم الملف 10 فقط. العوامل الأساسية لارتفاع زمن انتقال النسخ المتماثل في هذا السيناريو هي سرعة الشبكة أو الاستخدام العالي لوحدة المعالجة المركزية على الخادم المصدر.
في Azure، يمكن عادة قياس زمن انتقال الشبكة داخل منطقة بالمللي ثانية. عبر المناطق، يتراوح زمن الانتقال من مللي ثانية إلى ثوان.
في معظم الحالات، يحدث تأخير الاتصال بين مؤشرات ترابط IO والخادم المصدر بسبب الاستخدام العالي لوحدة المعالجة المركزية على الخادم المصدر. تتم معالجة مؤشرات الترابط IO ببطء. يمكنك الكشف عن هذه المشكلة باستخدام Azure Monitor للتحقق من استخدام وحدة المعالجة المركزية وعدد الاتصالات المتزامنة على الخادم المصدر.
إذا كنت لا ترى استخداماً عالياً لوحدة المعالجة المركزية على الخادم المصدر، فقد تكون المشكلة في زمن انتقال الشبكة. إذا كان زمن انتقال الشبكة مرتفعاً فجأة بشكل غير طبيعي، فتحقق من صفحة حالة Azure بحثاً عن المشكلات أو الانقطاعات المعروفة.
دفعات كثيفة من المعاملات على الخادم المصدر
إذا رأيت القيم التالية، فمن المحتمل أن يتسبب الاندفاع الكثيف للمعاملات على الخادم المصدر في زمن انتقال النسخ المتماثل.
Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller then Master_Log_File, e.g. mysql-bin.00010
يظهر الإخراج أن النسخة المتماثلة يمكنها استرداد السجل الثنائي خلف الخادم المصدر. ولكن مؤشر ترابط IO للنسخة المتماثلة يشير إلى أن مساحة سجل الترحيل ممتلئة بالفعل.
سرعة الشبكة لا تسبب التأخير. تحاول النسخة المتماثلة اللحاق بالركب. ولكن حجم السجل الثنائي المحدث يتجاوز الحد الأعلى لمساحة سجل الترحيل.
لاستكشاف هذه المشكلة وإصلاحها، قم بتمكين سجل الاستعلام البطيء على الخادم المصدر. استخدم سجلات الاستعلام البطيئة لتحديد المعاملات طويلة الأمد على الخادم المصدر. ثم قم بضبط الاستعلامات المحددة لتقليل زمن الانتقال على الخادم.
يحدث زمن انتقال النسخ المتماثل من هذا النوع عادة بسبب تحميل البيانات على الخادم المصدر. عندما تحتوي خوادم المصدر على أحمال بيانات أسبوعية أو شهرية، فإن زمن انتقال النسخ المتماثل للأسف لا يمكن تجنبه. اللحاق بخوادم النسخ المتماثلة في النهاية بعد انتهاء تحميل البيانات على الخادم المصدر.
البطء على خادم النسخة المتماثلة
إذا لاحظت القيم التالية، فقد تكون المشكلة على خادم النسخة المتماثلة.
Slave_IO_State: Waiting for master to send event
Master_Log_File: The binary log file sequence equals to Relay_Master_Log_File, e.g. mysql-bin.000191
Read_Master_Log_Pos: The position of master server written to the above file is larger than Relay_Log_Pos, e.g. 103978138
Relay_Master_Log_File: mysql-bin.000191
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: The position of slave reads from master binary log file is smaller than Read_Master_Log_Pos, e.g. 13468882
Seconds_Behind_Master: There is latency and the value here is greater than 0
في هذا السيناريو، يظهر الإخراج أن كل من مؤشر ترابط IO وسلسلة SQL تعمل بشكل جيد. تقرأ النسخة المتماثلة نفس ملف السجل الثنائي الذي يكتبه الخادم المصدر. ومع ذلك، يعكس بعض زمن الانتقال على خادم النسخة المتماثلة نفس المعاملة من الخادم المصدر.
تصف الأقسام التالية الأسباب الشائعة لهذا النوع من زمن الانتقال.
لا يوجد مفتاح أساسي أو مفتاح فريد على جدول
تستخدم قاعدة بيانات Azure لـ MySQL النسخ المتماثل المستند إلى الصف. يكتب الخادم المصدر الأحداث إلى السجل الثنائي، ويسجل التغييرات في صفوف الجدول الفردية. ثم ينسخ مؤشر ترابط SQL هذه التغييرات إلى صفوف الجدول المقابلة على خادم النسخة المتماثلة. عندما يفتقر الجدول إلى مفتاح أساسي أو مفتاح فريد، يقوم مؤشر ترابط SQL بفحص جميع الصفوف في الجدول الهدف لتطبيق التغييرات. يمكن أن يتسبب هذا الفحص في زمن انتقال النسخ المتماثل.
في MySQL، المفتاح الأساسي هو فهرس مقترن يضمن أداء الاستعلام السريع لأنه لا يمكن أن يتضمن قيم NULL. إذا كنت تستخدم محرك تخزين InnoDB، يتم تنظيم بيانات الجدول فعلياً لإجراء عمليات بحث وفرز فائقة السرعة استناداً إلى المفتاح الأساسي.
نوصي بإضافة مفتاح أساسي على الجداول في الخادم المصدر قبل إنشاء خادم النسخة المتماثلة. أضف المفاتيح الأساسية على الخادم المصدر ثم أعد إنشاء نسخ متماثلة للقراءة للمساعدة في تحسين زمن انتقال النسخ المتماثل.
استخدم الاستعلام التالي لمعرفة الجداول التي تفتقد إلى مفتاح أساسي على الخادم المصدر:
select tab.table_schema as database_name, tab.table_name
from information_schema.tables tab left join
information_schema.table_constraints tco
on tab.table_schema = tco.table_schema
and tab.table_name = tco.table_name
and tco.constraint_type = 'PRIMARY KEY'
where tco.constraint_type is null
and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys')
and tab.table_type = 'BASE TABLE'
order by tab.table_schema, tab.table_name;
استعلامات طويلة الأمد على خادم النسخة المتماثلة
يمكن أن يجعل حمل العمل على خادم النسخة المتماثلة مؤشر ترابط SQL متخلفا عن مؤشر ترابط IO. الاستعلامات طويلة الأمد على خادم النسخ المتماثلة هي أحد الأسباب الشائعة لزمن انتقال النسخ المتماثل العالي. لاستكشاف هذه المشكلة وإصلاحها، قم بتمكين سجل الاستعلام البطيء على خادم النسخة المتماثلة.
يمكن أن تزيد الاستعلامات البطيئة من استهلاك الموارد أو تبطئ الخادم بحيث لا يمكن للنسخة المتماثلة اللحاق بالخادم المصدر. في هذا السيناريو، قم بضبط الاستعلامات البطيئة. تمنع الاستعلامات الأسرع انسداد مؤشر ترابط SQL وتحسن زمن انتقال النسخ المتماثل بشكل ملحوظ.
استعلامات DDL على الخادم المصدر
على الخادم المصدر، قد يستغرق الأمر لغة تعريف البيانات (DDL) مثل ALTER TABLE وقتاً طويلاً. أثناء تشغيل الأمر DDL، قد يتم تشغيل الآلاف من الاستعلامات الأخرى بالتوازي على الخادم المصدر.
عند نسخ DDL، لضمان تناسق قاعدة البيانات، يقوم محرك MySQL بتشغيل DDL في مؤشر ترابط نسخ متماثل واحد. أثناء هذه المهمة، يتم حظر كافة الاستعلامات الأخرى المنسوخة نسخاً متماثلاً ويجب الانتظار حتى تنتهي عملية DDL على خادم النسخة المتماثلة. حتى عمليات DDL عبر الإنترنت تسبب هذا التأخير. تزيد عمليات DDL من زمن انتقال النسخ المتماثل.
إذا قمت بتمكين سجل الاستعلام البطيء على الخادم المصدر، يمكنك الكشف عن مشكلة زمن الانتقال هذه عن طريق التحقق من أمر DDL الذي تم تشغيله على الخادم المصدر. من خلال إسقاط الفهرس وإعادة تسميته وإنشاءه، يمكنك استخدام خوارزمية INPLACE لـ ALTER TABLE. قد تحتاج إلى نسخ بيانات الجدول وإعادة إنشاء الجدول.
عادة ما يتم دعم DML المتزامن لخوارزمية INPLACE. ولكن يمكنك أن تأخذ لفترة وجيزة تأمين بيانات التعريف الحصرية على الجدول عند إعداد وتشغيل العملية. لذلك بالنسبة إلى عبارة CREATE INDEX، يمكنك استخدام العبارتين ALGORITHM و LOCK للتأثير على أسلوب نسخ الجدول ومستوى التزامن للقراءة والكتابة. لا يزال بإمكانك منع عمليات DML عن طريق إضافة فهرس FULLTEXT أو فهرس SPATIAL.
ينشئ المثال التالي فهرساً باستخدام عبارات ALGORITHM و LOCK.
ALTER TABLE table_name ADD INDEX index_name (column), ALGORITHM=INPLACE, LOCK=NONE;
لسوء الحظ، بالنسبة إلى عبارة DDL التي تتطلب تأميناً، لا يمكنك تجنب زمن انتقال النسخ المتماثل. لتقليل التأثيرات المحتملة، قم بهذه الأنواع من عمليات DDL خلال ساعات الذروة، على سبيل المثال أثناء الليل.
خادم النسخة المتماثلة المخفضة
في قاعدة بيانات Azure لـ MySQL، تستخدم النسخ المتماثلة للقراءة نفس تكوين الخادم مثل الخادم المصدر. يمكن تغيير تكوين خادم النسخة المتماثلة بعد إنشائه.
إذا تم تخفيض خادم النسخة المتماثلة، يمكن أن يستهلك حمل العمل المزيد من الموارد، والذي بدوره يمكن أن يؤدي إلى زمن انتقال النسخ المتماثل. للكشف عن هذه المشكلة، استخدم Azure Monitor للتحقق من استهلاك وحدة المعالجة المركزية والذاكرة لخادم النسخة المتماثلة.
في هذا السيناريو، نوصي بالاحتفاظ بتكوين خادم النسخة المتماثلة عند قيم تساوي قيم الخادم المصدر أو أكبر منها. يسمح هذا التكوين للنسخة المتماثلة بمواكبة الخادم المصدر.
تحسين زمن انتقال النسخ المتماثل عن طريق ضبط معلمات الخادم المصدر
في Azure Database لـ MySQL، بشكل افتراضي يتم تحسين النسخ المتماثل للتشغيل مع مؤشرات الترابط المتوازية على النسخ المتماثلة. عندما تتسبب أحمال العمل عالية التزامن على الخادم المصدر في تأخر خادم النسخة المتماثلة، يمكنك تحسين زمن انتقال النسخ المتماثل عن طريق تكوين المعلمة binlog_group_commit_sync_delay على الخادم المصدر.
تتحكم المعلمة binlog_group_commit_sync_delay في عدد الميكروثانية التي ينتظرها الالتزام بالسجل الثنائي قبل مزامنة ملف السجل الثنائي. تكمن فائدة هذه المعلمة في أنه بدلاً من التطبيق الفوري لكل معاملة ملتزمة، يرسل الخادم المصدر تحديثات السجل الثنائي دفعة واحدة. يقلل هذا التأخير من IO على النسخة المتماثلة ويساعد على تحسين الأداء.
قد يكون من المفيد تعيين المعلمة binlog_group_commit_sync_delay إلى 1000 أو نحو ذلك. ثم مراقبة زمن انتقال النسخ المتماثل. قم بتعيين هذه المعلمة بحذر، واستخدمها فقط لأحمال العمل عالية التزامن.
هام
في خادم النسخ المتماثلة، يوصى لمعلمة binlog_group_commit_sync_delay بأن تكون 0. يوصى بذلك لأنه على عكس الخادم المصدر، لن يكون لخادم النسخة المتماثلة تزامن عال وقد تؤدي زيادة قيمة binlog_group_commit_sync_delay على خادم النسخ المتماثل عن غير قصد إلى زيادة تأخر النسخ المتماثل.
بالنسبة لأحمال العمل منخفضة التزامن التي تتضمن العديد من المعاملات الأحادية، يمكن أن يؤدي إعداد binlog_group_commit_sync_delay إلى زيادة زمن الانتقال. يمكن أن يزيد زمن الانتقال لأن مؤشر ترابط IO ينتظر تحديثات السجل الثنائي المجمع حتى إذا تم تنفيذ عدد قليل فقط من المعاملات.
خيارات متقدمة لاستكشاف الأخطاء وإصلاحها
إذا لم يوفر استخدام الأمر إظهار حالة الرقيق معلومات كافية لاستكشاف زمن انتقال النسخ المتماثل وإصلاحه، فحاول عرض هذه الخيارات الإضافية للتعرف على العمليات النشطة أو قيد الانتظار.
عرض جدول مؤشرات الترابط
performance_schema.threads يعرض الجدول حالة العملية. تشير عملية الحالة في انتظار تأمين lock_type إلى وجود تأمين على أحد الجداول، مما يمنع مؤشر ترابط النسخ المتماثل من تحديث الجدول.
SELECT name, processlist_state, processlist_time FROM performance_schema.threads WHERE name LIKE '%slave%';
لمزيد من المعلومات، راجع حالات مؤشر الترابط العام.
عرض الجدول replication_connection_status
يعرض جدول performance_schema.replication_connection_status الحالة الحالية لمؤشر ترابط الإدخال/الإخراج للنسخ المتماثل الذي يعالج اتصال النسخة المتماثلة بالمصدر، ويتغير بشكل متكرر. يحتوي الجدول على قيم تختلف أثناء الاتصال.
SELECT * FROM performance_schema.replication_connection_status;
عرض جدول replication_applier_status_by_worker
performance_schema.replication_applier_status_by_worker يعرض الجدول حالة مؤشرات ترابط العامل، آخر معاملة تمت رؤيتها مع رقم الخطأ الأخير والرسالة، والتي تساعدك على العثور على المعاملة التي تواجه مشكلة وتحديد السبب الجذري.
يمكنك تشغيل الأوامر أدناه في النسخ المتماثل Data-in لتخطي الأخطاء أو المعاملات:
az_replication_skip_counter
أو
az_replication_skip_gtid_transaction
SELECT * FROM performance_schema.replication_applier_status_by_worker;
عرض عبارة SHOW RELAYLOG EVENTS
show relaylog events تظهر العبارة الأحداث في سجل الترحيل للنسخة المتماثلة.
· بالنسبة للنسخ المتماثل المستند إلى GITD (قراءة النسخة المتماثلة)، تظهر العبارة معاملة GTID وملف binlog وموضعه، يمكنك استخدام mysqlbinlog لتشغيل المحتويات والعبارات. · بالنسبة إلى النسخ المتماثل لموضع Binlog MySQL (المستخدم للنسخ المتماثل للبيانات في)، فإنه يعرض العبارات التي يتم تشغيلها، مما سيساعد على معرفة معاملات الجدول التي يتم تشغيلها
تحقق من إخراج InnoDB Standard Monitor و Lock Monitor
يمكنك أيضا محاولة التحقق من InnoDB Standard Monitor و Lock Monitor Output للمساعدة في حل حالات التأمين والتوقف التام وتقليل تأخر النسخ المتماثل. يعد Lock Monitor هو نفسه جهاز العرض القياسي باستثناء أنه يتضمن معلومات تأمين إضافية. لعرض معلومات التأمين وحالة التوقف التام الإضافية هذه، قم بتشغيل الأمر show engine innodb status\G.