MySQL Fehlerbehebung

MySQL Logdateien löschen – purge mysql binary log files

MySQL schreibt jedes SQL-Kommando in die Binlog-Files. Diese Binlog-Protokolle verwendet ein Replication-Slave um eine exakte Kopie der Originaldatenbank zu gewährleisten. Bei viel Aktivität auf der Datenbank wachsen diese Logdateien enorm und es kann vorkommen, dass Logdateien aus Platzgründen (Festplatte läuft voll) gelöscht werden müssen.

MySQL Binlog-Dateien dürfen keinesfalls über die Shell, sondern ausschließlich über das MySQL-CLI gelöscht werden!

Das Kommando purge binary logs wird keinesfalls Binlog-Dateien löschen, die vom Relication-Slave noch benötigt werden. Wer allerdings ganz sicher gehen möchte, der folgt dieser Anleitung:

Auf dem Slave nachsehen, bis zu welcher Binlog-Datei die Replizierung erfolgreich war

mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.232.38.99
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.002962
          Read_Master_Log_Pos: 30656966
               Relay_Log_File: relay-mysql.000287
                Relay_Log_Pos: 30657111
        Relay_Master_Log_File: mysql-bin.002962
             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: 30656966
              Relay_Log_Space: 30657305
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

Auf diese Weise hat man auch gleich eine Kontrolle, ob der Slave ohne Schwierigkeiten repliziert hat. Das aktuelle Master_Log_File muss natürlich vorhanden bleiben.

Auf dem Master die Binlog-Dateien maximal bis zum Master_Log_File purgen

mysql> purge binary logs to 'mysql-bin.002960';
Query OK, 0 rows affected (2.97 sec)

Hintergrund:

Im MySQL-Logdirectory befindet sich auch die Datei mysql-bin.index in welcher die geschriebenen Binlog-Dateien aufgelistet sind. Diese Datei verwendet MySQL zur das automatische Purgen der Logfiles. Die maximale Vorhaltezeit in Tagen wie auch die maximale Größe der Logfiles wird in /etc/mysql/my.cnf konfiguriert:

expire_logs_days        = 10
max_binlog_size         = 100M

Tabellen reparieren

ERROR 1030 (HY000): Got error 134 from storage engine

Natürlich gibt es auch nicht so leicht zu behebende Fehler, hier möchte ich jedoch den einfachen Weg zeigen, der in bestimmt über 90% der Fehlersituationen (selbstverständlich nur die mit oben stehender Fehlermeldung) zielführend ist.

Ursache: Eine Tabelle ist defekt.

Eine Prüfung ist mit folgendem Kommando möglich (Beispiel):

mysql> check table content;
+--------------+-------+----------+----------------------------------------------------------------------+
| Table        | Op    | Msg_type | Msg_text                                                             |
+--------------+-------+----------+----------------------------------------------------------------------+
| bild.content | check | warning  | Found 4864180 deleted space in delete link chain. Should be 4865912  |
| bild.content | check | error    | Found more than the expected 13977 deleted rows in delete link chain |
| bild.content | check | error    | record delete-link-chain corrupted                                   |
| bild.content | check | error    | Corrupt                                                              |
+--------------+-------+----------+----------------------------------------------------------------------+
4 rows in set (0.01 sec)

Behebung: Reparatur der defekten Tabelle (Beispiel)

mysql> repair table content;
+--------------+--------+----------+------------------------------------------------+
| Table        | Op     | Msg_type | Msg_text                                       |
+--------------+--------+----------+------------------------------------------------+
| bild.content | repair | warning  | Number of rows changed from 3020539 to 3020542 |
| bild.content | repair | status   | OK                                             |
+--------------+--------+----------+------------------------------------------------+
2 rows in set (12 min 23.44 sec)

Und sicherheitshalber anschließend die Überprüfung:

mysql> check table content;
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| bild.content | check | status   | OK       |
+--------------+-------+----------+----------+
1 row in set (1 min 45.21 sec)

ACHTUNG! Die oben stehenden Kommandos brauchen eine ganze Weile für die Ausführung (siehe beispielhafte Zeitangaben). Man tut gut daran, vor dem Reparatur sämtliche Benutzer der Datenbank zu informieren und darum zu bitten möglichst keine Suchanfragen zu stellen, da die Datenbank in der Reparaturphase nur eine massiv reduzierte Performance hat.

Das Beispielsystem ist eine 8-Kern Xeon Maschine mit jeweils 2,33 GHz und insgesamt 16 GB RAM unter Linux.