☰

Diagnostizieren von MySQL-Replikationsproblemen

tag-icon • tag-icon mysql mysql-replication
Diagnostizieren von MySQL-Replikationsproblemen

Auf unserem Backup-Server läuft ein MySQL-Replikationsclient. Seit einem Stromausfall letzte Woche wird die Replikation eingestellt. Davor lief er mehrere Monate lang ohne Unterbrechung.

Ich habe versucht, sowohl den Master als auch den Slave neu zu starten, aber das hat nicht geholfen. Ich kann vom Slave aus auf den Master-Server zugreifen, das Netzwerk ist also nicht das Problem.

Kann ich sonst noch etwas tun, um das Problem zu diagnostizieren?

mysql> show slave status\G;
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: master
                Master_User: username
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000060
        Read_Master_Log_Pos: 46277494
             Relay_Log_File: mysqld-relay-bin.000348
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysql-bin.000060
           Slave_IO_Running: No
          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: 46277494
            Relay_Log_Space: 98
            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: NULL
1 row in set (0.00 sec)

ERROR:
No query specified


mysql> show master status\G;
*************************** 1. row ***************************
            File: mysql-bin.000069
        Position: 851796
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

ERROR:
No query specified

Update: Die Fehler gingen in daemon.log, nicht in mysql.err, was erklären würde, warum ich sie nicht finden konnte. Das Problem scheint zu sein, dass der Master sagt, das Protokoll sei nicht verfügbar, was nicht viel Sinn ergibt, da dieses Protokoll (und das vorherige) auf dem Master noch verfügbar sind.

090710  9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710  9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306',  replication started in log 'mysql-bin.000060' at position 46277494
090710  9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710  9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710  9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494

Antwort1

Willkommen in der wunderbaren Welt der MySQL-Replikation. Ich bin selbst noch nicht auf Ihr spezielles Problem gestoßen, aber ich bin auf viele andere seltsame Probleme gestoßen und die unmittelbare Lösung besteht darin, einfach vom Master aus neu zu synchronisieren, als wäre es ein brandneuer Slave, und damit fertig.

Antwort2

Sie sollten das Fehlerprotokoll des Slaves prüfen. Normalerweise wird dort das Problem recht deutlich angegeben.

Sie sollten die MySQL-Fehlerprotokolle in Ihr Überwachungssystem einbinden, da Ihre Slaves andernfalls möglicherweise wertlos sind.

Darüber hinaus sollten Sie über einen Monitor verfügen, der den Slave-Status überprüft.

Und damit dies überhaupt von Nutzen ist, sollten Sie auch von Zeit zu Zeit die Synchronisierung der Slaves überprüfen, beispielsweise mithilfe von etwas wie mk-table-checksum. Binden Sie die Ergebnisse idealerweise auch in Ihr Überwachungssystem ein.

Antwort3

Viele Leute setzen skip-slave-start, damit sie sicherstellen können, dass alles in Ordnung ist, wenn ein Slave die Replikation stoppt, bevor sie ihn starten. Versuchen Sie, „start slave“ auszuführen und sehen Sie, ob sich etwas ändert oder ob etwas protokolliert wird. Außerdem ist es seltsam, dass der SlaveSQL-Prozess läuft und der SlaveIO nicht. Es ist jedoch möglich, dass die lokalen Relay-Protokolle auf dem Slave beschädigt wurden.sollenin den Protokollen gemeldet werden. Sie können versuchen, MySQL herunterzufahren und dann die Relay-Protokolle zu löschen.

Antwort4

Im obigen Bericht habe ich das Problem gefunden, dieses Feld muss auf (Slave_IO_Running): ja eingestellt sein, aber im obigen Bericht wird „Slave_IO_Running: Nein“ angezeigt.

Das ist die Ursache des Problems. Wenn diese Variable „Nein“ anzeigt, wurde der IO-Thread gestoppt. Es findet also keine Replikation mehr statt. Weitere Informationen zur Ursache finden Sie unter Last_SQL_Errno und Last_SQL_Err. Eine Fehlernummer von 0 und eine Meldung mit einer leeren Zeichenfolge bedeuten „kein Fehler“. Last_SQL_Error erscheint im Fehlerprotokoll des Slaves.

Um dieses Problem zu beheben, stoppen Sie den Slave

Stellen Sie dann ein:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Dies weist den Slave an, eine Abfrage zu überspringen (und zwar die ungültige, die zum Stoppen der Replikation geführt hat). Wenn Sie zwei Abfragen überspringen möchten, verwenden Sie stattdessen SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; und so weiter.

Starten Sie dann den Slave neu und überprüfen Sie die Protokolle. In der Hoffnung, dass das Problem dadurch behoben wird ...

verwandte Informationen