MySQL Master-Master Replication Auto Flush Old Logs

Question

Ich habe MySQL-5.1.41 Master-Master-Setup, das auf Ubuntu-Maschinen ausgeführt wird, und unten ist die Konfiguration eines Masters:

skip-host-cache
skip-name-resolve
event_scheduler = ON
max_connections = 500
max_connect_errors = 1000

server-id = 10
replicate-same-server-id = 0
auto-increment-increment = 10
auto-increment-offset = 1

master-host = 192.168.1.106
master-user = repli
master-password = secret
master-connect-retry = 60

binlog-format = MIXED
binlog-ignore-db = information_schema
binlog-ignore-db = lb1

log-bin = /var/log/mysql/mysql-bin
log-bin-index = /var/log/mysql/bin-log.index

log-slave-updates
report-host = 192.168.1.105
replicate-ignore-db = information_schema
replicate-ignore-db = lb2

relay-log = /var/log/mysql/relay.log
relay-log-index = /var/log/mysql/relay-log.index

Die Protokolldateien scheinen jeden Tag zu wachsen. Weiß jemand, welcher Parameter ich in die obige Konfiguration einbeziehen sollte, um alte unnötige lassische Protokolle automatisch zu entfernen/zu spülen, wobei ein ordentlicher Wert verursacht wird, der keine Synchronisierungsschaden verursacht?

Answer 1

Um Protokolle mehr als 7 Tage alt zu drehen, fügen Sie dies zu my.cnf hinzu

[mysqld]
expire-logs-days=7

Dann starten Sie MySQL neu.

Um dies manuell auszuführen, führen Sie diesen Befehl aus:

mysql> PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 7 DAY) + INTERVAL 0 SECOND;

Dies wird vor 7 Tagen Binärprotokolle auf Mitternacht zurücklöschen.

WARNUNG !!!

Löschen Sie keine Binärprotokolle aus der OS -Ebene, da es die interne Funktionalität von Mysqld für das Drehen von Binärprotokollen stört.

Update 2012-01-24 13:20 EDT

Stellen Sie sicher, dass Sie Binärprotokolle, die die Replikation verwendet, nicht reinigen.

Hier ist ein Beispiel, wie Sie binäre Protokolle sicher manuell löschen können ...

Für einen Master-Master-Setup M1 und M2

Gehen Sie zu M2 und führen Sie das aus:

mysql> SHOW SLAVE STATUS\G

Sie werden zwei Zeilen sehen, die binäre Protokollnamen anzeigen

• Master_log_file
• Relay_master_log_file

Master_Log_File repräsentiert das aktuelle binäre Protokoll für M1, das zuletzt auf M2 gelesen wurde.

Relay_Master_Log_File repräsentiert das aktuelle binäre Protokoll für M1, das zuletzt auf M2 ausgeführt wurde.

Nehmen wir an, M2 hat dies:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.176.205
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000131
          Read_Master_Log_Pos: 570079419
               Relay_Log_File: relay-bin.003496
                Relay_Log_Pos: 251
        Relay_Master_Log_File: mysql-bin.000131
             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: 570079419
              Relay_Log_Space: 545
              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)

mysql>

Auf m2, Relay_Master_Log_File sagt mysql-bin.000131. Auf M1 können Sie dies also ausführen:

mysql> PURGE BINARY LOGS TO 'mysql-bin.000131';

Da master_log_file und relay_master_log_file gleich sind, warum nicht master_log_file verwenden?

Grund Nr. 1: SQL -Fehler im Sklaven

Wenn ein SQL -Fehler in M2 im SQL -Thread auftritt, beendet die Replikation die Verarbeitung von SQL aus den Relaisprotokollen. Der IO -Thread wird weiterhin neue SQL -Einträge von M1 herunterladen und an die Relaisprotokolle von M2 angehängt.

Grund Nr. 2: Langlaufende SQL -Abfrage im Sklaven

Wenn eine Frage kommt, wie z. UPDATE Das aktualisiert jede Zeile in einer Tabelle und dauert 5 Minuten. Während dieser 5 Minuten, Der IO -Thread wird weiterhin neue SQL -Einträge von M1 herunterladen und an die Relaisprotokolle von M2 angehängt.

Angesichts der beiden Gründe gibt es einige Anlässe, wo Relay_Master_Log_File und Master_Log_File sind anders. In diesem Fall immer verwenden Relay_Master_Log_File. In Anbetracht dessen gibt es einen anderen Grund:

Grund Nr. 3: Log -Korruption im Sklaven oder Master

Es gibt seltene Zeiten, in denen eine schlechte Netzwerkübertragung beschädigte Relaisprotokolle erzeugt. Wenn Sie das tun SHOW SLAVE STATUS\G, Eine Fehlermeldung erklärt, dass das binäre Protokoll korrupt sein kann. Sie sollten FIRSDT mit den Relaisprotokollen beginnen.

Um sie zu räumen und mit dem frischen Set zu beginnen, tun Sie es SHOW SLAVE STATUS\G, bekommen das Relay_Master_Log_File (RMLF), die Exec_Master_Log_Pos (EMLP) und führen Sie dies auf M2 aus

STOP SLAVE;
CHANGE MASTER TO master_log_file='RMLF',master_log_pos=EMLP;
START SLAVE;

Das CHANGE MASTER TO Der Befehl löscht alle Relaisprotokolle und beginnt von Grund auf neu herunterzuladen.

Wenn du START SLAVE;, Wenn Sie die beschädigte Fehlerprotokollnachricht erneut abrufen, war die Netzwerkübertragung nicht das Problem. Das binäre Protokoll auf M1 kann doch nur korrupt sein.

Sie müssen zu M1 gehen, Kopie des mutmaßlichen Protokolls, ausführen mysqlbinlog gegen dieses kopierte binäre Protokoll und leiten Sie sie in eine Textdatei um. Lesen Sie die Textdatei. Wenn die Textdateien Kauderwelsch- oder unbestreitbare Zeichen enthalten, müssen Sie eine vollständige Synchronisierung des Sklaven ausführen.