MySQL-Server: Platte voll …

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 … „MySQL-Server: Platte voll …“ weiterlesen

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:

  1. Vermeide Reset Master
    Ist die Platte durch Binlogs vollgelaufen, so kann man die Binlogs einfach per

    RESET 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';
  2. Binlogs und Database gehören nicht auf die gleiche Platte/Partition
    Stichworte: Performance und Datensicherheit. Logisch, oder?
  3. 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
    
  4. expire_logs_days nicht vergessen
  5. 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 
    

MySQL Dumps/Strukturen kopieren

Wie oft bin ich zum Kopieren für MySQL-Dumps so vorgegangen: mysqldump -u user -p db | gzip > db.gz scp db.gz user@remote.server.net:/var/tmp zcat db.gz | mysql -u user -p db Nur weil ich zu faul war mir das mit MySQL und SSH genauer zu merken. Daher schreib ich mir das jetzt mal wieder auf. Komplette … „MySQL Dumps/Strukturen kopieren“ weiterlesen

Wie oft bin ich zum Kopieren für MySQL-Dumps so vorgegangen:

mysqldump -u user -p db | gzip > db.gz
scp db.gz user@remote.server.net:/var/tmp
zcat db.gz | mysql -u user -p db

Nur weil ich zu faul war mir das mit MySQL und SSH genauer zu merken. Daher schreib ich mir das jetzt mal wieder auf.

  1. Komplette DBs via mysql kopieren:
    mysqldump db | mysql -h remote.server.net db
  2. Komplette DBs via ssh kopieren:
    mysqldump db | ssh user@remote.server.net mysql db
  3. Oder nur die Struktur per ssh kopieren:
    mysqldump -d db | ssh user@remote.server.net mysql db

Na hoffentlich tue ich mir den scp Umweg nicht nochmal an.