89344

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, followthis 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 surę the table data is correct, as shown here when I started up from our mid-

INSERT

snapshot:

InnoDB: The log seąuence number in ibdata files does not match InnoDB: the log 3equence 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 seąuence number 0 1142807951 081109 16:00:03 [Notę] /slavepool/mysql-5.0.67-solarisl0-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 MylSAM tables, you might need to run REPAIR TABLE, and you might even

have lost some

information.