MySQL 5.6 gtid النسخ المتماثل العبد عالق (قفل النظام)؟

Question

لقد قمت بإعداد النسخ المتماثل المستند إلى 5.6 gtid (في 5.6.26) وبدا أنه يعمل عندما قمت بذلك، فقد قام بتكرار قاعدة بيانات الاختبار العشوائي الخاصة بي والتي قمت بإنشائها بجانب البيانات العادية.ولكن في مرحلة ما لا بد أن شيئًا ما قد حدث لأن كل ما أراه هو هذا:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: System lock
                  Master_Host: xxxxxxxxxxxxxxxxxx
                  Master_User: xxxxxxxxxxxxxxxx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysqld-bin.000141
          Read_Master_Log_Pos: 169293671
               Relay_Log_File: mysqld-relay-bin.000003
                Relay_Log_Pos: 16861206
        Relay_Master_Log_File: mysqld-bin.000141
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 16860994
              Relay_Log_Space: 169298584
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 55203
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: 7846a847-62c7-11e5-91a6-e06995de432e
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
            Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
                Auto_Position: 1

الآن قال "Slave_SQL_Running_State" في الأصل "قراءة الحدث من سجل الترحيل" أو شيء من هذا القبيل، لقد تغير الآن إلى قفل النظام أيضًا (كانت حالة IO دائمًا تقول ذلك).

يبدو أن Seconds_Behind_Master يتزايد بشكل مطرد، وينمو حجم سجل الترحيل بسرعة على نظام الملفات، بينما Executed_gtid_set يبدو أنه يتغير، ولكن لا يزال هناك شيء يبدو خاطئًا لأنه متأخر جدًا....

إليك قائمة العمليات:

mysql> show processlist;
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| Id   | User        | Host      | db   | Command | Time  | State                                 | Info             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| 1877 | root        | localhost | NULL | Sleep   |  6076 |                                       | NULL             |
| 1878 | root        | localhost | NULL | Query   |     0 | init                                  | show processlist |
| 1886 | system user |           | NULL | Connect |   783 | System lock                           | NULL             |
| 1887 | system user |           | NULL | Connect |     0 | System lock                           | NULL             |
| 1888 | system user |           | NULL | Connect |   783 | Waiting for an event from Coordinator | NULL             |
| 1889 | system user |           | NULL | Connect | 55455 | System lock                           | NULL             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+

حاولت إيقاف العبد وتشغيله مرة أخرى لكن ذلك لم يساعد.

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

شكرًا

Answer 1

منذ أن رأيت أكثر من 2 system user الإدخالات في قائمة العمليات، أفترض أنك تستخدم النسخ المتماثل متعدد الخيوط (Slave_parallel_workers > 1).

هذا يبدو وكأنه خطأ

• الخطأ رقم 73066 :توقف النسخ المتماثل مع النسخ المتماثل متعدد الخيوط
• الخطأ رقم 72794 :قد يؤدي سجل الترحيل بدون xid_log_event إلى تعليق النسخ المتماثل المتوازي

في 29 أكتوبر 2014، تم التعبير عن ذلك بواسطة David Moss

شكرا لك على ملاحظاتك.تمت تغطية هذه المشكلة في الخطأ رقم 17326020 وتمت إضافة ما يلي إلى سجلي التغيير MySQL 5.6.21 و5.7.5:

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

لذلك لن تتم إضافة أي شيء جديد لتغطية هذا الخطأ وسأقوم بإغلاقه لأنه تم إصلاحه.

في 10 ديسمبر 2014، تم التعبير عن ذلك بواسطة Laurynas Biveinis

مشكلة:

مع تمكين MTS و GTIDs وتحديد المواقع التلقائية ، عندما يطبق العامل معاملة جزئية تركت على Relaylog بواسطة إعادة اتصال مؤشر ترابط IO ، فإنه ينتظر حدث سجل XID لارتكاب المعاملة.

لسوء الحظ ، سيصل منسق مؤشر ترابط SQL إلى الحدث الدوراني للماجستير في ملف الترحيل التالي وسينتظر حتى ينهي جميع العمال مهامهم قبل تطبيق الدوران.

تحليل:

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

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

اقتراح

يجري FLUSH BINARY LOGS; على الماجستير

معرفة ما إذا كانت الحركة تؤدي إلى استجابة من سلاسل عمليات SQL.

إذا لم يحدث ذلك، المضي قدما وإزالته Slave_parallel_workers من my.cnf وأعد تشغيل الخلية.

منذ أن بدأت MySQL صعودًا وسيدًا وعبدًا وحصلت error 1236, ، هذا يعني أنك تحاول إنشاء النسخ المتماثل من موضع مستحيل.في سياق GTID ورسالة الخطأ التي تلقيتها، فإن السجلات الثنائية اللازمة لتحديد مجموعة الاستعلامات بشكل كامل ضمن مجموعة GTID لم تعد موجودة،

انظر إلى الوراء في الخاص بك SHOW SLAVE STATUS\G

Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
 Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274

من هذا، آخر GTID تم تنفيذه هو 7846a847-62c7-11e5-91a6-e06995de432e:4783274

وهذا يعني أن السجل الثنائي الذي لديه أو كان 7846a847-62c7-11e5-91a6-e06995de432e:4783275 لم يعد موجود.

أستطيع أن أرى أن هذا يحدث إذا أوقفت النسخ المتماثل على الجهاز التابع، وتركت النسخ المتماثل متوقفًا لفترة كافية حتى يتمكن السيد من تدوير سجلاته الثنائية (عبر Experty_logs_days) الذي لا يزال العبد بحاجة إلى رؤيته، ثم قم بتشغيل النسخ المتماثل.

في حالتك الخاصة، حاول إجراء تفريغ mysqlbinlog للسجل الثنائي mysqld-bin.000141.إذا لم يخرج أي شيء منه، فسيتعين عليك إعادة تحميل النسخة التابعة وإعداد النسخ المتماثل من البداية.