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 quetschen, um unnötige Dateien zu löschen. Ich bin auf diese gestoßen mysql-bin Dateien im Inneren /var/db/mysql/ Es gibt Hunderte solcher Dateien wie mysql-bin.000123, mysql-bin.000223 usw. Ich habe die MySQL-Replikation dabei überprüft show master status und show slave status Sie verwenden einige MySQL-Bin-Dateien an bestimmten Positionen, aber ich denke, alle anderen Bin-Dateien sind Reste die nicht mehr verwendet wird. 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 irgendetwas tun automatisch diese Dateien löschen, wenn sie nicht verwendet werden?

  • 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 Reinigen 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 zuvor gelöscht mysql-bin.000223.

    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 entfernt wird und 3 Tage bei bleibt, stellen Sie einfach Folgendes ein:

    mysql> SET GLOBAL expire_logs_days = 3;
    

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

    [mysqld]
    expire_logs_days=3
    

    und mysqld löscht diese Protokolle für Sie

    SHLA SLAVE STATUS \ G.

    Dies ist kritisch. Wenn du rennst SHOW SLAVE STATUS\Gsehen Sie zwei binäre Protokolle vom Master:

    • 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 was auch immer Relay_Master_Log_File ist, und gehe zurück zum Meister und renne

    PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';
    

    Auf diese Weise wird die Replikation nicht unterbrochen.

    Bitte beachten Sie einen Tippfehler - Unterstriche, keine Bindestriche: `[mysqld] expire_logs_days = 3` (und Sie müssen den Abschnitt `[mysqld]` einschließen

    @changokun Das ist kein Tippfehler. my.cnf akzeptiert Bindestriche. Wenn Sie "SET GLOBAL expire_logs_days = 3;" vom MySQL-Client ausführen, werden diese nicht akzeptiert. Beispiel in den MySQL-Dokumenten: http://dev.mysql.com/doc/refman/5.5/en/mysqld-option-tables.html

    Das funktioniert bei mir. Frage, was ist der Unterschied zwischen ... `mysql> SET GLOBAL expire_logs_days = 3;` und `expire-logs-days = 3` in` / etc / my.cnf` .. Sind sie gleich? Ist das überflüssig oder nicht? Oder ist es wichtig, "SET GLOBAL ..." auszuführen und dann "expire-logs-days = .." hinzuzufügen? Vielen Dank.

    Entfernen Sie schnell alle Protokolle, offensichtlich: `` `BINARY LOGS VOR DATUM (JETZT ()) LÖSCHEN;` `` Warum gibt es dafür keine vernünftigen Standardeinstellungen? Ich habe nirgendwo explizit die Größe der Protokolldatei auf eine gigantische Menge geändert. Ich hatte 10,0 GB Protokolldateien. Nachdem ich diesen Befehl ausgeführt hatte, schrumpfte meine Ordnergröße mysql.bin auf 1,6 GB.

Lizenz unter CC-BY-SA mit Zuschreibung


Inhoud eerder gedateerd 26.06.2020 09:53