it-swarm.com.de

Ist es sicher, MySQL-Bin-Dateien zu löschen?

Ich habe MM Replication in MySQL, und ich möchte etwas freien Speicherplatz in der Box drücken, um unnötige Dateien zu löschen. Ich bin auf diese mysql-bin - Dateien in /var/db/mysql/ Stoßen. Es gibt Hunderte dieser Dateien wie mysql-bin.000123, mysql-bin.000223 Usw. Ich habe die MySQL-Replikation mit show master status Und show slave status Überprüft. Sie verwenden einige MySQL-Bin-Dateien an bestimmten Positionen, aber ich denke alle Die anderen Bin-Dateien sind Reste , die nicht mehr verwendet werden. Ist es in diesem Fall sicher, alle diese MySQL-Bin-Dateien zu löschen, mit Ausnahme derjenigen, auf die die Replikation derzeit verweist?

Wenn das Löschen sicher ist, kann ich dann automatisch diese Dateien löschen, sobald sie nicht verwendet werden?

100
user18530

Bitte löschen Sie sie nicht einfach im Betriebssystem.

Sie müssen mysqld das für Sie tun lassen. So schafft es mysqld:

Die Datei mysql-bin.[index] Führt eine Liste aller Binärprotokolle, die mysqld generiert und automatisch gedreht hat. Die Mechanismen zum Bereinigen der Binlogs in Verbindung mit mysql-bin.[index] Sind:

PURGE BINARY LOGS TO 'binlogname';
PURGE BINARY LOGS BEFORE 'datetimestamp';

Dadurch werden alle Binärprotokolle vor dem soeben angegebenen Binlog oder Zeitstempel gelöscht.

Zum Beispiel, wenn Sie ausführen

PURGE BINARY LOGS TO 'mysql-bin.000223';

dadurch werden alle Binärprotokolle vor mysql-bin.000223 gelöscht.

Wenn du läufst

PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;

dadurch werden alle Binärprotokolle vor 3 Tagen vor Mitternacht gelöscht.

Wenn Sie möchten, dass binlog automatisch weggedreht wird und 3 Tage Zeit bleibt, stellen Sie einfach Folgendes ein:

mysql> SET GLOBAL expire_logs_days = 3;

dann füge dies zu /etc/my.cnf hinzu

[mysqld]
expire_logs_days=3

und mysqld löscht diese Protokolle für Sie

SHLA SLAVE STATUS\G.

Das ist kritisch. Wenn Sie SHOW SLAVE STATUS\G Ausführen, werden zwei Binärprotokolle vom Master angezeigt:

  • Master_Log_File
  • Relay_Master_Log_File

Wenn die Replikation nur eine geringe oder keine Verzögerung aufweist, sind diese normalerweise gleich. Wenn es eine große Replikationsverzögerung gibt, sind diese Werte unterschiedlich. Um es einfach zu machen, wählen Sie Relay_Master_Log_File Und gehen Sie zurück zum Master und rennen Sie los

PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';

Auf diese Weise wird die Replikation nicht unterbrochen.

148
RolandoMySQLDBA

Dies hängt wirklich von Ihrer Sicherungsstrategie ab. Einer der Hauptgründe, um die Binärprotokolle beizubehalten, ist die Wiederherstellung Ihrer Datenbank zu einem "Zeitpunkt". Wenn Ihre Datenbank abstürzt und wiederhergestellt werden muss, stellen Sie die letzte vollständige Sicherung wieder her und spielen dann die Binärprotokolle ab der Position der vollständigen Sicherung ab.

Wenn Sie also jeden Tag eine vollständige Sicherung durchführen und über Binärprotokolle im Wert von 7 Tagen verfügen, können Sie wahrscheinlich die Binärprotokolle der letzten 4 bis 6 Tage löschen. Mit der Einstellung expire_logs_days Können Sie steuern, wie viele Tage Binärprotokolle aufbewahrt werden.

Sie können die nicht benötigten Binärprotokolle löschen, indem Sie zuerst das älteste Protokoll anzeigen, das Sie aufbewahren möchten:

ls -lh /path/to/binary/logs/mysql-bin.0*

und dann in mysql:

mysql> PURGE BINARY LOGS TO 'mysql-bin.XXXXX';
22
Derek Downey

Versuche dies:

RESET MASTER;

wie das Dokument sagte:

Mit RESET MASTER können Sie alle binären Protokolldateien und die zugehörige binäre Protokollindexdatei löschen und den Master in den Status zurückversetzen, bevor die binäre Protokollierung gestartet wurde.

Dadurch werden alle zugehörigen binären Protokolldateien gelöscht, die möglicherweise nicht Ihren Wünschen entsprechen.

6
Xiaofeng