Wenn auf einem MySQL-Server die Platte voll läuft, so liegt es in 80% der Fälle nicht an den Database-Files selbst, sondern eher an den Binlog-Files. Obwohl die meisten MySQL-Installation die ich kenne, ohne Binlog-Files laufen, bin ich eher ein Fan von ihnen und schalte sie eigentlich per default immer an. Binlog-Files sind einfach fantastisch, wenn es um Datensicherheit geht. Mit Hilfe der Binlogs lassen sich wunderbar inkrementelle Backups der Datenbank herstellen. Sie sind einfach zu mehr zu gebrauchen als nur fürs Replizieren. Daher hier ein paar Notizen für mich zum Thema Binlogs:
- Vermeide Reset Master
Ist die Platte durch Binlogs vollgelaufen, so kann man die Binlogs einfach perRESET Master;
entsorgen. Schlau ist das allerdings nicht. Besser ist es alle Binlogs vor der letzten Vollsicherung zu löschen:
PURGE {MASTER | BINARY} LOGS BEFORE 'date'; - Binlogs und Database gehören nicht auf die gleiche Platte/Partition
Stichworte: Performance und Datensicherheit. Logisch, oder? - Point-In-Time-Recovery
Ab einem bestimmten Zeitpunkt (z.B. nach der letzten Vollsicherung) zurücksichern:mysqlbinlog --start-datetime="2005-04-20 10:01:00" /var/log/mysql/bin.123456 | mysql -u root -p
Oder bis zu einem bestimmten Zeitpunkt (z.B. an dem sich ein Logikfehler eingeschlichen hat)
mysqlbinlog --stop-datetime="2005-04-20 9:59:59" /var/log/mysql/bin.123456 | mysql -u root -p
- expire_logs_days nicht vergessen
Mit expire_logs_days legt man fest wie lange alte Binlogs aufgehoben werden sollen. Hier muss mindestens die maximale Anzahl der Tage seit dem letzten Vollbackup rein. Am besten noch mehr. Damit lassen sich dann Logikfehler wieder gerade ziehen. Also sowas wie:
expire_logs_days = 30