mysql 5.6 gtid-Replikationssklave steckt fest (Systemsperre)?

dba.stackexchange https://dba.stackexchange.com/questions/117068

  •  29-09-2020
  •  | 
  •  

Frage

Ich habe eine 5.6 gtid-basierte Replikation eingerichtet (am 5.6.26). Es schien zu funktionieren, als ich es tat, es replizierte meine zufällige Testdatenbank, über die ich neben normalen Daten erstellt hatte.Irgendwann muss jedoch etwas passiert sein, denn alles, was ich sehe, ist Folgendes:

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

jetzt sagte ursprünglich "Slave_SQL_Running_State" "Ereignis aus Relay-Protokoll lesen" oder so ähnlich, es hat sich jetzt auch in Systemsperre geändert (IO-Status hat das immer gesagt).

Es scheint, dass die Seconds_Behind_Master nimmt stetig zu, und das Relay-Protokoll wächst schnell in der Größe auf dem Dateisystem, während Executed_gtid_set scheint sich zu ändern, aber immer noch scheint etwas nicht zu stimmen, weil es einfach so viel zurückliegt....

Hier ist die Prozessliste:

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             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+

Ich habe versucht, den Sklaven anzuhalten und erneut zu starten, aber es hat nicht geholfen.

Hat jemand eine Idee, was ich versuchen könnte, damit das wieder funktioniert?Wäre sehr dankbar.

Danke

War es hilfreich?

Lösung

Da sehe ich mehr als 2 system user einträge in der Prozessliste, ich würde annehmen, dass Sie Multithread-Replikation verwenden (sklaven_parallel_arbeiter > 1).

Das sieht nach einem Fehler aus

Am 29. Oktober 2014 wurde dies zum Ausdruck gebracht von David Moss

Vielen Dank für Ihre Rückmeldung.Dieses Problem wurde in Fehler 17326020 behandelt und Folgendes wurde zu den MySQL 5.6.21- und 5.7.5-Änderungsprotokollen hinzugefügt:

Wenn der E / A-Thread über GTIDs wieder mit einem Master verbunden ist und multithread-Slaves Während einer Transaktion ist es fehlgeschlagen um die Transaktion abzubrechen, belassen Sie eine Teiltransaktion im Relay protokollieren und dann dieselbe Transaktion erneut abrufen.Dies geschah bei einer Drehung des Relaisprotokolls.Jetzt beim erneuten Verbinden, der Server überprüft in solchen Fällen vor dem Drehen des Protokolls und wartet zuerst für den Abschluss einer laufenden Transaktion.

Daher wird nichts Neues hinzugefügt, um diesen Fehler zu beheben, und ich schließe ihn als behoben.

Am 10. Dezember 2014 wurde dies zum Ausdruck gebracht von Laurynas Biveinis

Problem:

Wenn MTS, GTIDs und automatische Positionierung aktiviert sind, wenn ein Mitarbeiter eine teiltransaktion, die durch eine erneute E / A-Thread-Verbindung im Relaylog verbleibt, ist es wartet, bis das XID-Protokollereignis die Transaktion festschreibt.

Leider wird der SQL-Thread-Koordinator den Master erreichen Ereignis in der nächsten Relaylog-Datei drehen und auf alle Mitarbeiter warten um ihre Aufgaben zu beenden, bevor Sie die DREHUNG anwenden.

Analyse:

Da die gesamte Transaktion vom IO-Thread nach dem erneuten Abrufen erneut abgerufen wird bei erneuter Verbindung muss der Slave die Teiltransaktion einmal zurücksetzen bemerken Sie diese DREHUNG vom Master.

Dieser Fehler meldet dasselbe Problem, das bereits durch FEHLER # 17326020 behoben wurde, und das gemeldetes Problem ist nicht mehr reproduzierbar.Also, dieser Patch ist nur hinzufügen eines neuen Testfalls.

VORSCHLAG

Laufen FLUSH BINARY LOGS; auf dem Meister

Überprüfen Sie, ob die Bewegung eine Antwort von den SQL-Threads auslöst.

Wenn nicht, fahren Sie fort und entfernen Sie sklaven_parallel_arbeiter von my.cnf und starten Sie MySQL neu.

Seit du MySQL gestartet hast und Master und Slave und bekommen hast error 1236, das bedeutet, dass Sie versuchen, die Replikation von einer unmöglichen Position aus zu etablieren.Im Zusammenhang mit der GTID und der Fehlermeldung, die Sie erhalten haben, sind die Binärprotokolle, die zum vollständigen Identifizieren einer Reihe von Abfragen innerhalb einer GTID-Gruppe erforderlich sind, nicht mehr vorhanden,

Schau zurück auf deine SHOW SLAVE STATUS\G

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

Daraus ergibt sich die zuletzt ausgeführte GTID 7846a847-62c7-11e5-91a6-e06995de432e:4783274

Dies bedeutet, dass das Binärlog, das hat oder hatte 7846a847-62c7-11e5-91a6-e06995de432e:4783275 existiert nicht mehr.

Ich kann sehen, dass dies passiert, wenn Sie die Replikation auf dem Slave gestoppt, die Replikation lange genug deaktiviert haben, damit der Master seine Binärprotokolle (über expire_logs_days ) drehen kann, die der Slave noch sehen musste, und dann die Replikation aktiviert haben.

Versuchen Sie in Ihrem speziellen Fall, einen mysqlbinlog-Dump des Binärlogs zu erstellen mysqld-bin.000141.Wenn nichts dabei herauskommt, müssen Sie den Slave neu laden und die Replikation von Grund auf neu einrichten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit dba.stackexchange
scroll top