Skip navigation links
13.6.2.8 START SLAVE »
Section Navigation      [Toggle]

13.6.2.7. SHOW SLAVE STATUS

SHOW SLAVE STATUS

Diese Anweisung vermittelt Statusinformationen zu wesentlichen Parametern der Slave-Threads. Wenn Sie diese Anweisung mit dem mysql-Client absetzen, können Sie \G statt des Semikolons als Abschlusszeichen für die Anweisung verwenden, um eine vertikale Ausgabe zu erhalten, die besser zu lesen ist: 

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      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: 8

SHOW SLAVE STATUS gibt die folgenden Felder zurück:

  • Slave_IO_State

    Eine Kopie des State-Felds in der Ausgabe von SHOW PROCESSLIST für den Slave-I/O-Thread. Sie zeigt an, was der Thread gerade tut: Verbindungsherstellung zum Master, Warten auf vom Master kommende Ereignisse, Wiederverbindung mit dem Master usw. Mögliche Zustände sind in Abschnitt 6.4, „Replikation: Implementationsdetails“, beschrieben. Bei älteren MySQL-Versionen ist eine Überprüfung dieses Felds notwendig, denn diese erlaubten eine fortlaufende Ausführung des Threads auch für den Fall, dass eine Verbindungsherstellung mit dem Master nicht möglich war. Wird er ausgeführt, so liegt kein Problem vor; andernfalls finden Sie den Fehler im Feld Last_Error (siehe unten).

  • Master_Host

    Der aktuelle Master-Host.

  • Master_User

    Der aktuelle Benutzer, der mit dem Master verbunden ist.

  • Master_Port

    Der aktuelle Master-Port.

  • Connect_Retry

    Der aktuelle Wert der Option --master-connect-retry.

  • Master_Log_File

    Der Name der Master-Binärlogdatei, aus der der I/O-Thread derzeit liest.

  • Read_Master_Log_Pos

    Die Position, bis zu der der I/O-Thread im aktuellen Master-Binärlog gelesen hat.

  • Relay_Log_File

    Der Name der Relay-Logdatei, deren Angaben der SQL-Thread derzeit liest und ausführt.

  • Relay_Log_Pos

    Die Position, bis zu der der SQL-Thread Angaben in der aktuellen Relay-Logdatei gelesen und ausgeführt hat.

  • Relay_Master_Log_File

    Der Name der Master-Binärlogdatei, die das aktuelle Ereignis enthält, welches gerade vom SQL-Thread ausgeführt wird.

  • Slave_IO_Running

    Gibt an, ob der I/O-Thread gestartet wurde und erfolgreich eine Verbindung mit dem Master herstellen konnte. Bei älteren MySQL-Versionen (vor 4.1.14 und 5.0.12) hat Slave_IO_Running den Wert YES, wenn der I/O-Thread gestartet wurde (und zwar auch dann, wenn noch keine Verbindung zum Master hergestellt wurde).

  • Slave_SQL_Running

    Gibt an, ob der SQL-Thread gestartet wurde.

  • Replicate_Do_DB, Replicate_Ignore_DB

    Liste der Datenbanken, die ggf. mit den Optionen --replicate-do-db und --replicate-ignore-db angegeben wurden.

  • Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table

    Liste der Tabellen, die ggf. mit den Optionen --replicate-do-table, --replicate-ignore-table, --replicate-wild-do-table und --replicate-wild-ignore_table angegeben wurden.

  • Last_Errno, Last_Error

    Nummer und Meldung des Fehlers, der von der zuletzt ausgeführten Abfrage zurückgegeben wurde. Die Fehlernummer 0 und der Leer-String als Meldung haben die Bedeutung „kein Fehler“. Wenn der Wert Last_Error nicht leer ist, erscheint er auch als Meldung im Fehlerlog des Slaves. Zum Beispiel: 

    Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'

    Die Meldung zeigt an, dass die Tabelle z auf dem Master vorhanden war und dort gelöscht wurde, dass sie aber auf dem Slave nicht existierte, weswegen die Anweisung DROP TABLE dort fehlschlug. (Dies kann beispielsweise passieren, wenn Sie vergessen, die Tabelle beim Einrichten der Replikation auf den Slave zu kopieren.)

  • Skip_Counter

    Der zuletzt verwendete Wert von SQL_SLAVE_SKIP_COUNTER.

  • Exec_Master_Log_Pos

    Die Position des letzten vom SQL-Thread ausgeführten Ereignisses aus dem Binärlog des Masters (Relay_Master_Log_File). (Relay_Master_Log_File, Exec_Master_Log_Pos) im Binärlog des Masters entspricht (Relay_Log_File, Relay_Log_Pos) im Relay-Log.

  • Relay_Log_Space

    Die Gesamtgröße aller vorhandenen Relay-Logs.

  • Until_Condition, Until_Log_File, Until_Log_Pos

    Der in der UNTIL-Klausel der START SLAVE-Anweisung angegebene Wert.

    Until_Condition kann folgende Werte haben:

    • None, sofern keine UNTIL-Klausel angegeben wurde.

    • Master, wenn der Slave bis zu einer angegebenen Position in den Binärlogs des Masters liest.

    • Relay, wenn der Slave bis zu einer angegebenen Position in seinen Binärlogs liest.

    Until_Log_File und Until_Log_Pos geben den Namen der Logdatei und die Position an. Diese Werte definieren den Punkt, an dem die Ausführung des SQL-Threads endet.

  • Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, Master_SSL_Key

    Diese Felder geben (sofern vorhanden) die SSL-Parameter an, die vom Slave zur Verbindung mit dem Master verwendet werden.

    Master_SSL_Allowed kann folgende Werte haben:

    • Yes, wenn eine SSL-Verbindung zum Master zulässig ist.

    • No, wenn keine SSL-Verbindung zum Master zulässig ist.

    • Ignored, wenn eine SSL-Verbindung zwar zulässig ist, aber am Slave-Server die SSL-Unterstützung nicht aktiviert ist.

    Die Werte der übrigen SSL-spezifischen Felder entsprechen den Werten der Optionen --master-ca, --master-capath, --master-cert, --master-cipher und --master-key.

  • Seconds_Behind_Master

    Dieses Feld gibt an, wie „verspätet“ der Slave ist:

    • Wenn der Slave-SQL-Thread aktiv läuft (d. h. Änderungen verarbeitet), dann gibt dieses Feld die Anzahl der Sekunden an, die seit dem Zeitstempel des Ereignisses vergangen sind, das von diesem Thread zuletzt auf dem Master ausgeführt wurde.

    • Wenn der SQL-Thread den Slave-I/O-Thread eingeholt hat und untätig auf weitere Ereignisse vom I/O-Thread wartet, ist das Feld null.

    Im Endeffekt misst das Feld also den zeitlichen Unterschied zwischen dem Slave-SQL-Thread und dem Slave-I/O-Thread.

    Ist die Netzwerkverbindung zwischen Master und Slave sehr schnell, dann liegt der Slave-I/O-Thread recht nah am Master, d. h., das Feld erlaubt eine recht genaue Schätzung des zeitlichen Verarbeitungsabstandes zwischen Slave-SQL-Thread und dem Master. Ist das Netzwerk hingegen langsam, dann ist der Wert nicht sehr aussagekräftig: Der Slave-SQL-Thread kann recht häufig zum langsam lesenden Slave-I/O-Thread aufschließen, weswegen Seconds_Behind_Master oft den Wert 0 anzeigt – und zwar auch dann, wenn der I/O-Thread im Vergleich zum Master relativ stark verspätet ist. Anders gesagt, diese Spalte ist nur bei schnellen Netzwerken aussagekräftig.

    Diese Berechnung des zeitlichen Unterschieds funktioniert, obwohl Master und Slave keine identisch laufenden Uhren haben (der Unterschied wird ermittelt, wenn der Slave-I/O-Thread startet; danach wird davon ausgegangen, dass der Abstand konstant bleibt). Seconds_Behind_Master ist NULL (d. h. „unbekannt“), wenn der Slave-SQL-Thread nicht ausgeführt wird oder wenn der Slave-I/O-Thread nicht läuft oder nicht mit dem Master verbunden ist. Schläft beispielsweise der Slave-I/O-Thread für die mit der Option --master-connect-retry angegebene Anzahl von Sekunden, bevor er eine Wiederverbindung versucht, dann wird NULL angezeigt, weil der Slave nicht wissen kann, was der Master tut, und deswegen auch nicht zuverlässig weiß, wie spät es ist.

    Dieses Feld hat eine Einschränkung: Der Zeitstempel wird bei der Replikation beibehalten, d. h., wenn ein Master M1 seinerseits ein Slave von M0 ist, dann hat jedes Ereignis im Binärlog von M1, das der Replikation eines Ereignisses aus dem Binärlog von M0 entstammt, auch den Zeitstempel dieses Ereignisses. Dies erlaubt MySQL die erfolgreiche Replikation von TIMESTAMP. Der Nachteil für Seconds_Behind_Master besteht allerdings darin, dass, wenn M1 auch direkte Updates von Clients erhält, der Wert wahllos abweicht, weil das letzte Ereignis auf M1 mal von M0 stammt, mal aber auch der letzte Zeitstempel eines direkten Updates ist.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.