È sicuro eliminare i file mysql-bin?

  • Ho MM Replication in mysql e voglio spremere un po 'di spazio libero nella casella per eliminare i file non necessari, mi sono imbattuto in questi mysql-bin file all'interno /var/db/mysql/ Ci sono centinaia di quei file come mysql-bin.000123, mysql-bin.000223 ecc. Ho controllato la replica di mysql facendo show master status e show slave status stanno usando alcuni file mysql-bin in certe posizioni, ma immagino che tutti gli altri file bin lo siano avanzi che non verrà più utilizzato. In questo caso è sicuro eliminare tutti quei file mysql-bin tranne quelli a cui punta attualmente la replica?

    Se è sicuro eliminare, allora c'è qualcosa che potrei fare per automaticamente eliminare quei file una volta che non sono in uso?

  • RolandoMySQLDBA

    RolandoMySQLDBA Risposta corretta

    7 anni fa

    Si prega di non eliminarli semplicemente nel sistema operativo.

    Devi lasciare che mysqld lo faccia per te. Ecco come lo gestisce mysqld:

    Il file mysql-bin.[index] mantiene un elenco di tutti i log binari che mysqld ha generato e ruotato automaticamente. I meccanismi per ripulire i binlog insieme a mysql-bin.[index] siamo:

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

    Questi cancelleranno tutti i log binari prima del binlog o del timestamp appena specificato.

    Ad esempio, se corri

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

    questo cancellerà tutti i registri binari precedenti mysql-bin.000223.

    Se corri

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

    questo cancellerà tutti i log binari prima della mezzanotte di 3 giorni fa.

    Se vuoi che binlog ruoti automaticamente e rimanga per 3 giorni, imposta semplicemente questo:

    mysql> SET GLOBAL expire_logs_days = 3;
    

    quindi aggiungilo a /etc/my.cnf

    [mysqld]
    expire_logs_days=3
    

    e mysqld cancellerà i log per te

    MOSTRA STATO SLAVE \ G

    Questo è fondamentale. Quando corri SHOW SLAVE STATUS\G, vedrai due log binari dal Master:

    • Master_Log_File
    • Relay_Master_Log_File

    Quando la replica ha un ritardo minimo o nullo, di solito hanno lo stesso valore. Quando c'è molto ritardo di replica, questi valori sono diversi. Solo per semplificare, scegli qualunque cosa Relay_Master_Log_File è, e torna dal Maestro e corri

    PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';
    

    In questo modo, la replica non viene interrotta.

    Si prega di notare un errore di battitura - trattini bassi, non trattini: `[mysqld] expire_logs_days = 3` (e devi includere la sezione "[mysqld]"

    @changokun Non è un errore di battitura. my.cnf accetterà trattini. L'esecuzione di `SET GLOBAL expire_logs_days = 3;` dal client mysql non li accetterà. Esempio nei documenti MySQL: http://dev.mysql.com/doc/refman/5.5/en/mysqld-option-tables.html

    Questo funziona per me. Domanda, qual è la differenza tra ... `mysql> SET GLOBAL expire_logs_days = 3;` e `expire-logs-days = 3` in` / etc / my.cnf` .. Sono la stessa cosa? È ridondante o no? Oppure è importante eseguire "SET GLOBAL ..." e poi aggiungere "expire-logs-days = .."? Grazie.

    Rimuovere rapidamente tutti i registri, ovviamente: `` PURGE BINARY LOGS BEFORE DATE (NOW ()); `` perché non ci sono impostazioni predefinite sane per questo? Non ho mai modificato esplicitamente la dimensione del file di registro in una quantità gigantesca. Avevo 10,0 GB di file di registro, dopo aver eseguito questo comando la dimensione della mia cartella mysql.bin si è ridotta a 1,6 GB.

Licenza sotto CC-BY-SA con attribuzione


Contenuto datato prima del 26/06/2020 09:53