MySQL-Methode zum automatischen Bereinigen von Binlog-Protokollen

Anleitung:

MySQL aktivieren Wenn der Binlog-Server nicht so eingestellt ist, dass er die Protokolle automatisch bereinigt, werden die Binlog-Protokolle standardmäßig beibehalten. Mit der Zeit wird der Speicherplatz des Servers durch die Binlog-Protokolle aufgefüllt, was zu einem Fehler in der MySQL-Datenbank führt.

Verwenden Sie die folgende Methode, um das Binlog-Protokoll sicher zu bereinigen

1. Bereinigen Sie das Protokoll ohne Master-Slave-Synchronisierung

mysql -uroot -p123456 -e 'PURGE MASTER LOGS VORHER DATE_SUB ( NOW( ),INTERVAL 5 DAY)';

#mysql bereinigt regelmäßig das Binlog von vor 5 Tagen

mysql -u root -p #Geben Sie die MySQL-Konsole ein

reset binlog

2. Binlog-Protokolle unter MySQL-Master-Slave-Synchronisierung sicher löschen

1. Geben Sie die MySQL-Konsole des Slave-Servers ein.
Slave-Status anzeigenG; #Überprüfen Sie, welches Protokoll vom Slave-Server gelesen wird. Es gibt mehrere Slave-Server. Wählen Sie den ältesten als Zielprotokoll aus.
2. Rufen Sie die MySQL-Konsole des Master-Servers auf

Zeigen Sie eine Reihe von Protokollen auf dem Master-Server
LÖSCHEN SIE MASTER-LOGS AUF „binlog.000058“; #Löschen Sie diejenigen vor binlog.000005, mit Ausnahme von binlog.000058
LÖSCHEN SIE DIE MASTER-LOGS VOR dem 22.06.2016 13:00:00'; #Binlog-Protokolle vor dem 22.06.2016 13:00:00 löschen
VORHER MASTER-LOGS LÖSCHEN DATE_SUB( NOW( ), INTERVAL 3 DAY); #Binlog-Protokolle vor 3 Tagen löschen

3. Automatische Bereinigung der MySQL-Binlog-Protokolle einrichten

vi /etc/my.cnf #Konfiguration bearbeiten

expire_logs_days = 15 #自动删除15天前的日志。默认值为0，表示从不删除。
log-bin=mysql-bin #注释掉之后，会关闭binlog日志
binlog_format=mixed #注释掉之后，会关闭binlog日志

:wq! #Speichern und beenden

Erweiterte Lektüre:

mysql> help purge;

Name: 'BINARY LOGS'

Beschreibung:

Syntax:

PURGE { BINARY | LOGS

{ TO 'log_name' | datetime_expr }

Das Binärprotokoll ist eine Reihe von Dateien, die Informationen über Datenänderungen enthalten,

vom MySQL-Server vorgenommene Änderungen. Das Protokoll besteht aus einer Reihe von

Binärprotokolldateien , plus eine Indexdatei (siehe

http://dev.mysql.com/doc/refman/5.5/en/binary-log.html).

Die PURGE BINARY LOGS-Anweisung löscht alle binären Protokolldateien, die

in der Protokollindexdatei vor dem angegebenen Protokolldateinamen oder -datum aufgeführt sind.

BINÄR und MASTER sind Synonyme, die auch aus

die in der Indexdatei aufgezeichnete Liste, sodass die angegebene Protokolldatei

die erste in der Liste wird.

Diese Anweisung hat keine Auswirkung, wenn der Server nicht mit gestartet wurde

--log-bin-Option zum Aktivieren der binären Protokollierung.

URL: http://dev.mysql.com/doc/refman/5.5/en/purge-binary-logs.html

Beispiele:

BINÄRE PROTOKOLLE IN „mysql-bin.010“ LÖSCHEN;

BINÄRE PROTOKOLLE VOR „2008-04-02 22:46:26“ LÖSCHEN;

Im Folgenden sind die von anderen Internetnutzern angegebenen Methoden aufgeführt.

Die MYSQL-Master-Slave-Replikation verwendet RBR Nach dem Ändern des Modus lautet das Format von binlog „ROW“, wodurch viele Probleme bei der Duplizierung ursprünglicher Schlüssel gelöst werden können.

In einer ausgelasteten Master-Datenbank Auf dem Server wächst die Binlog-Protokolldatei sehr schnell. Wenn sie nicht regelmäßig gelöscht wird, ist der Festplattenspeicher schnell voll.
Automatische Reinigung von MySQL einrichten Binlog-Protokoll, my.cnf konfigurieren:

expire_logs_days = 10

Zur Laufzeit ändern:

Binärprotokolle anzeigen

Variablen wie „%log%“ anzeigen; 🎜>Global einstellen Expire_logs_days = 10;

Die entsprechende Sicherungsstrategie kann vor dem Löschen übernommen werden.

Löschen Sie die MySQL-Binlog-Protokolle vor 10 Tagen manuell:

PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);

show Master-Protokolle;

MASTER und BINARY sind Synonyme.

Unter normalen Umständen wird empfohlen, die GEMISCHTE Binlog-Replikation zu verwenden. Anweisungen in http://dev.mysql.com/doc/refman/5.1/en/open-bugs-general.html: Replikation verwendet Protokollierung auf Abfrageebene: Der Master schreibt die ausgeführten Abfragen in die Binärdatei log. Dies ist eine sehr schnelle, kompakte und effiziente Protokollierungsmethode, die funktioniert in den meisten Fällen perfekt.

Anhang: Mehrere Modi der MYSQL-Replikation

Ab MySQL 5.1.12 können die folgenden drei Modi verwendet werden, um Folgendes zu erreichen:

– Basierend auf Replikation von SQL-Anweisungen (anweisungsbasiert). Replikation (SBR),
– zeilenbasierte Replikation (RBR),
– Gemischtbasierte Replikation (MBR).
Entsprechend gibt es drei Binlog-Formate: STATEMENT, ROW und MIXED. Im MBR-Modus ist der SBR-Modus die Standardeinstellung.

Das Binlog-Format kann während der Laufzeit dynamisch geändert werden, außer in den folgenden Situationen:

In der Mitte eines gespeicherten Prozesses oder Triggers

Versuchen Sie RBR für aktuelle Sitzung Modus und die temporäre Tabelle wurde geöffnet

Wenn das Binlog den GEMISCHTEN Modus annimmt, wird der Binlog-Modus in den folgenden Situationen automatisch vom SBR-Modus in den RBR-Modus geändert.
. Wenn eine DML-Anweisung eine NDB-Tabelle aktualisiert

Wenn die Funktion UUID() enthält

Wenn 2 oder mehr Tabellen mit AUTO_INCREMENT-Feldern aktualisiert werden
. Beim Ausführen einer INSERT DELAYED-Anweisung
Bei Verwendung von UDF
Wenn die Ansicht beispielsweise beim Erstellen der Ansicht die Verwendung von RBR erfordern muss, wird UUID() verwendet Funktion

Master-Slave-Replikationsmodus festlegen:
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

Sie können das Binlog-Format auch zur Laufzeit dynamisch ändern. Zum Beispiel
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> GLOBAL binlog_format = 'MIXED';

Die Vor- und Nachteile der beiden Modi:

SBR Vorteile:
Lange Geschichte und ausgereifte Fähigkeiten
Die Binlog-Datei ist kleiner
Das Binlog enthält alle Datenbankänderungsinformationen, die zur Überprüfung der Sicherheit der Datenbank und in anderen Situationen verwendet werden können
Das Binlog kann sein Wird für die Echtzeitwiederherstellung und nicht nur für die Replikation verwendet
Die Master- und Slave-Versionen können unterschiedlich sein und die Slave-Server-Version kann höher sein als die Master-Server-Version
SBR Nachteile:
Nicht alle UPDATE-Anweisungen können kopiert werden, insbesondere wenn sie unsichere Operationen enthalten.
Rufen Sie eine UDF mit Unsicherheit auf Beim Kopieren kann es zu Problemen kommen
Anweisungen mit folgenden Funktionen können nicht kopiert werden:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (es sei denn, die Option –sysdate-is-now ist beim Start aktiviert)
INSERT … SELECT Erzeugt mehr Sperren auf Zeilenebene als RBR
Beim Kopieren eines UPDATE, das einen vollständigen Tabellenscan durchführen muss (in der WHERE-Anweisung wird kein Index verwendet), sind mehr Sperren auf Zeilenebene als RBR erforderlich Anfordern weiterer Sperren auf Zeilenebene
Bei InnoDB-Tabellen mit AUTO_INCREMENT-Feldern blockieren INSERT-Anweisungen andere INSERTs Anweisung
Bei einigen komplexen Anweisungen ist der Ressourcenverbrauch auf dem Slave-Server schwerwiegender und wirkt sich im RBR-Modus nur auf den geänderten Datensatz aus.
Gespeicherte Funktion (kein gespeicherter Prozess). ) führt die Funktion NOW() auch einmal aus, wenn sie aufgerufen wird. Dies kann eine schlechte oder eine gute Sache sein
Bestimmte UDF Es muss auch auf dem Slave-Server ausgeführt werden
Die Datentabelle muss nahezu konsistent mit dem Master-Server sein, sonst kann es zu Replikationsfehlern kommen
Wenn beim Ausführen komplexer Anweisungen Fehler auftreten, werden mehr Ressourcen verbraucht

RBR Vorteile:
Jede Situation kann repliziert werden, was für die Replikation am sichersten und zuverlässigsten ist.
Die gleichen Replikationsfähigkeiten wie bei den meisten anderen Datenbanksystemen.
In den meisten Fällen, wenn die Tabelle auf dem Slave-Server über die primäre verfügt Wenn der Schlüssel verwendet wird, wird die Replikation viel schneller sein
Es werden weniger Zeilensperren auftreten, wenn die folgenden Anweisungen repliziert werden:
* INSERT … SELECT
* INSERT
* mit dem AUTO_INCREMENT-Feld UPDATE ohne Bedingungen oder ohne Änderung vieler Datensätze Oder DELETE-Anweisung
Weniger Sperren beim Ausführen von INSERT-, UPDATE-, DELETE-Anweisungen
Es ist möglich, mehrere Threads zu verwenden, um die Replikation vom Server durchzuführen
RBR Nachteile:
Das Binlog ist viel größer
Bei komplexen Rollbacks enthält das Binlog eine große Datenmenge
Führen Sie UPDATE auf dem Hauptserver aus Anweisung werden alle geänderten Datensätze in das Binlog geschrieben, und SBR schreibt nur einmal, was zu häufigen Problemen beim gleichzeitigen Schreiben des Binlogs führt.
Großes BLOB, das von UDF generiert wird Der Wert führt zu einer Verlangsamung der Replikation.
Sie können dem Binlog nicht entnehmen, welche Anweisungen kopiert (verschlüsselt) wurden.
Beim Ausführen einer Reihe von SQL-Anweisungen für eine nicht-transaktionale Tabelle verwenden Sie am besten SBR Modus, da es sonst leicht zu Dateninkonsistenzen zwischen Master- und Slave-Servern kommt
Darüber hinaus lauten die Verarbeitungsrichtlinien für Änderungen in den Tabellen in der Systembibliothek MySQL wie folgt:
Sofern übernommen Wenn INSERT, UPDATE und DELETE die Tabelle direkt bedienen, wird das Protokollformat gemäß der Einstellung von binlog_format aufgezeichnet
Wenn es verwendet wird Wenn hierfür Verwaltungsanweisungen wie GRANT, REVOKE und SET PASSWORD verwendet werden, wird in jedem Fall die Aufzeichnung im SBR-Modus verwendet.
Hinweis: Es wird RBR verwendet Nach der Implementierung des Modus können viele ursprünglich aufgetretene Probleme bei der Duplizierung von Primärschlüsseln gelöst werden. Beispiel:
Zum Einfügen in db_allot_ids wählen Sie * aus db_allot_ids Diese Anweisung:
in BINLOG_FORMAT=STATEMENT Im Modus:
BINLOG-Protokollinformationen sind:
——————————————–
BEGIN
/*!*/;
# bei 173
#090612 16:05:42 Server-ID 1 end_log_pos 288 Abfrage thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
in db_allot_ids einfügen select * from db_allot_ids
/*!*/;
——————————————–

Im BINLOG_FORMAT=ROW-Modus:
BINLOG-Protokollinformationen sind :
——————————————–
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
— ————————————–

Schritte zum Löschen von Protokollen
1. Protokolldateien finden
mysql> Protokolle;
+----------------+---------+
| |
+---------+| ablelee.000002 |. 125 |
| ablelee.000003 | |
+----------+
2. Bin-Log löschen (löschen Sie das vor ablelee.000003 und enthält nicht ablelee.000003)
mysql> Binärprotokolle in „ablelee.000003“ löschen;
Abfrage OK, 0 Zeilen betroffen (0,16 Sek.)

3. Abfrageergebnisse (es gibt jetzt nur einen Datensatz.)

mysql eventsG

*************** * *********** 1.Reihe ***************************
Log_name: ablelee.000003
Pos: 4
Ereignistyp: Format_desc
Server_id: 1
End_log_pos: 106
Info: Serverversion: 5.1.26-rc-log, Binlog Version: 4
1 Zeile im Satz (0.01 sec)
(ablelee.000001 und ablelee.000002 wurden gelöscht)
mysql> Protokolle;
+----------------+---------+
| |
+----------------+---------++----------------+----------+
1 Reihe im Satz (0,00 Sek.)

(Andere Formate gelöscht!)
LÖSCHEN VON {MASTER | 'log_name'
　LÖSCHEN SIE {MASTER | BINARY} PROTOKOLLE VORHER 'Datum'
Wird zum Löschen aller im Protokollindex aufgeführten Binärprotokolle vor dem angegebenen Protokoll oder Datum verwendet. Diese Protokolle werden auch aus der in der Protokollindexdatei aufgezeichneten Liste entfernt, sodass das angegebene Protokoll an erster Stelle steht.
Zum Beispiel:
PURGE MASTER-LOGS ZU 'mysql-bin.010';
　MASTER-LOGS VOR DEM 22.06.2008 LÖSCHEN 13:00:00';
Binlog von vor 3 Tagen löschen
MASTER-LOGS VOR DATE_SUB( JETZT LÖSCHEN( ), INTERVALL 3 TAG);
Das Datumsargument der BEFORE-Variable kann „JJJJ-MM-TT“ sein hh:mm:ss'-Format. MASTER und BINARY sind Synonyme.
Wenn Sie einen aktiven Slave-Server haben, der gerade eines der Protokolle liest, die Sie löschen möchten, funktioniert diese Anweisung nicht und schlägt mit einem Fehler fehl. Wenn der Slave jedoch in den Ruhezustand versetzt wird und Sie zufällig eines der Protokolle löschen, die er lesen möchte, kann der Slave nach dem Start keine Replikation durchführen. Diese Anweisung kann sicher ausgeführt werden, während der Slave-Server repliziert. Sie müssen sie nicht aufhalten.
Um die Protokolle zu löschen, befolgen Sie diese Schritte:
1. Verwenden Sie auf jedem Slave SHOW SLAVE STATUS, um zu überprüfen, welches Protokoll er liest.
　2. Verwenden Sie SHOW MASTER LOGS ruft eine Reihe von Protokollen auf dem Master-Server ab.
　3. Bestimmen Sie das älteste Protokoll aller Slave-Server. Dies ist das Zielprotokoll. Wenn alle Slave-Server auf dem neuesten Stand sind, ist dies das letzte Protokoll in der Liste.

　4. Erstellen Sie eine Sicherungskopie aller Protokolle, die Sie löschen möchten. (Dieser Schritt ist optional, wird aber empfohlen.)

5. Bereinigen Sie alle Protokolle, aber nicht das Zielprotokoll

Das Obige ist der Inhalt der MySQL-Methode zum automatischen Bereinigen von Binlog-Protokollen. Weitere verwandte Artikel finden Sie auf der chinesischen PHP-Website (www.php.cn).