1
MySQL Conference Liveblogging: Disaster Is Inevitable – Are You Prepared? (Tuesday 4:25PM)
Posted by Artem Russakovskii on April 15th, 2008 in Databases
- Suicide
- having no backups
- depending on slaves for backup
- keeping backups on same SAN
- having a single DBA – Frank didn't like this one at all
- not keeping binlogs
- Restoring from backup
- how much time?
- uncompressed backup ready to mount?
- separate network for recovery?
- In Fotolog, 1TB of data was severely hit.
- first problem: backup was highly compressed (tar.gz)
- uncompressing took hours
- so keep uncompressed backups (at least last N days)
- it should be mountable, rather than transferable
- Frank going over recovery modes at http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
- Row by row recovery
- row by row recovery (get the range of ids)
- custom scripts
- may not be able to use primary key
- foreign key based retrieval faster
- lose 4 seconds for each crashed record (in Fotolog, for some reason some values were crashing mysqld)
- Lessons
- SANs make sense (in some environments)
- try to replicate the whole SAN (in Fotolog, a SAN actually failed because of a bug in its maintenance program)
- everything will fail at some point
- backup everything (cron jobs, my.cnf, custom scripts)
- have backup in a form ready to restore
- don't count replication a backup
- be worried about 'routine' operations
- Peter Zaitsev of Percona takes the stage to talk about his homegrown tools for InnoDB recovery
- innodb-tools – will recover even if mysqld doesn't start, for example if half of RAID0 fails or somebody deleted some data. innodb-tools will recover using InnoDB tablespaces.
- We're out of time
In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.