Handling MySQL Recovery with ZFS
When using ZFS replication to provide a constant copy of your data, ensure that you can recover your
tables, either manually or automatically, in the event of a failure of the original system.
In the event of a failure, follow this sequence:
1. Stop the script on the master, if it is still up and running.
2. Set the slave file system to be read/write:
root-shell zfs set readonly=off slavepool
3. Start up mysqld on the slave. If you are using InnoDB, you get auto-recovery, if it is needed,
to make sure the table data is correct, as shown here when I started up from our mid-INSERT
snapshot:
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
081109 15:59:59 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
081109 16:00:03 InnoDB: Started; log sequence number 0 1142807951
081109 16:00:03 [Note] /slavepool/mysql-5.0.67-solaris10-i386/bin/mysqld: ready for connections.
Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
Use InnoDB tables and a regular synchronization schedule to reduce the risk for significant data
loss. On MyISAM tables, you might need to run REPAIR TABLE, and you might even have lost some
information.
... zobacz całą notatkę
Komentarze użytkowników (0)