Domanda

Ho un server MySQL con registrazione binaria attiva. Una volta al giorno log file è "ruotato", cioè MySQL sembra smettere di scrivere ad esso e crea e nuovo file di registro. Ad esempio, Al momento ho questi file in / var / lib / mysql

-rw-rw---- 1 mysql mysql 10485760 Jun  7 09:26 ibdata1
-rw-rw---- 1 mysql mysql  5242880 Jun  7 09:26 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Jun  2 15:20 ib_logfile1
-rw-rw---- 1 mysql mysql  1916844 Jun  6 09:20 mybinlog.000004
-rw-rw---- 1 mysql mysql 61112500 Jun  7 09:26 mybinlog.000005
-rw-rw---- 1 mysql mysql 15609789 Jun  7 13:57 mybinlog.000006
-rw-rw---- 1 mysql mysql       54 Jun  7 09:26 mybinlog.index

e mybinlog.000006 è in crescita.

è sufficiente che affronti mybinlog.000004 e mybinlog.000005, li up e il trasferimento zip a un altro server, o ho bisogno di fare qualcos'altro prima?

Quali informazioni sono memorizzate in mybinlog.index? Solo le informazioni sulle ultime log binario?

UPDATE: Capisco posso cancellare i log con ELIMINA BINARIO TRONCHI che aggiorna il file mybinlog.index. Tuttavia, ho bisogno di trasferire i log su un altro computer prima di eliminarli (I test se il backup è valida su un'altra macchina). Per ridurre le dimensioni di trasferimento, desidero bzip2 i file. Quale sarà PURGE BINARIO TRONCHI fare se i file di log non sono "là" più?

È stato utile?

Soluzione 2

Finalmente ho trovato la risposta sul sito di MySQL. Nel caso in cui qualcuno ha bisogno di queste informazioni:

Prima di MySQL 5.0.60, PURGE BINARIO registri per e spurgare BINARIO registri prima ha si comporta nello stesso modo (e nessuno si è comportato in modo corretto) quando i file di log binari elencati nel file .index erano stati rimossi dal sistema altri mezzi (come l'utilizzo di rm su Linux). A cominciare da MySQL 5.0.60, entrambe le varianti della dichiarazione falliscono con un errore in questi casi. (Bug # 18199, Bug # 18453) Per gestire tali errori, modificare il file .index (che è un semplice file di testo) manualmente per assicurarsi che elenca solo i file di log binari che sono effettivamente presenti, quindi eseguire nuovamente l'epurazione BINARIO TRONCHI dichiarazione che non è riuscita.

Questo significa che dovrei modificare il file manualmente .index e tutto andrà bene. La cosa interessante è che il file .index è un file di testo normale. Non ho nemmeno preavviso che fino ad ora.

Altri suggerimenti

È possibile eliminare i vecchi registri binari. Invece di eliminare direttamente, è più sicuro di utilizzare il PURGE BINARY LOGS MySQL-dichiarazione che aggiorna anche il file mybinlog.index. Questo file memorizza i nomi dei file che sono stati utilizzati per la registrazione binaria, vedere

http://dev.mysql.com/ doc / refman / 5.0 / it / spurgo-binary-logs.html

Inoltre, è possibile configurare il MySQL Server per eliminare automaticamente i vecchi registri binari. Impostare la max_binlog_size variabili e expire_logs_days nella configurazione del server per valori appropriati.

I file ibdata e ib_logfile non hanno nulla a che fare con la registrazione binaria. Essi sono utilizzati dal motore di storage InnoDB. Non essere scambiato per il fatto che essi non sembrano crescere: Se si dispone di InnoDB-tabelle sul server, questi file sono importanti e l'eliminazione di loro può causare la perdita di dati. Si può leggere di più su InnoDB nella documentazione:

http://dev.mysql.com/doc/ refman / 5.0 / it / InnoDB-configuration.html

mysql> PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY; 

eliminare tutti i file spazzatura prima di 3 giorni!

o

PURGE MASTER LOGS BEFORE '2010-10-08 00:00:00';

mysql-bin.index solito portano tutti i file .bin. Se u hanno rimosso alcuni file pls modificare il .index per riflettere quali sono tutti i file disponibili. Se u hanno rimosso tutti i file .bin rimuovere svuotare il file .index. Questo risolverà u r problema.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top