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:
Stop the script on the master, if it is still up and running.
Set the slave file system to be read/write:
root-shell> zfs set readonly=off slavepool
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.
© 2013, Oracle Corporation and/or its affiliates
User Comments
Add your own comment.