The company has a production mysqlAB replication architecture library, a master-slave architecture, every Monday at 0:00 days are automatically made full preparation.
Everything is normal, but today (assumed to be 6 weeks) accidentally accidentally deleted a table, accidentally deleted from the library will follow suit. Assuming that this table has several years of business data, how to restore it?
There are several ideas:
All of this requires binary log a few years before the merger, then this process to build the table to table looking for from all operations now out of order (of course, you want to get rid of the last piece of accidentally deleted by sed, grep, awk commands ), then lead back (too much data is not suggested)
First restore the full backup on Monday to test the library, and then restore a full backup to the current binary log (except accidentally deleted the phrase), then goes out guide table, back into production Libraries
There is a delay replication, then export this table in the delay library back into A, then the binary log restore accidentally deleted table in the delay time (except accidentally deleted the phrase)
From the above analysis, the recovery can be simplified delay replication in a certain procedure.
Maatkit is an open source written in Perl Mysql Administration Kit, which has a downloadable software package on www.maatkit.org website. I am here for the soft pack
mk-slave-delay
Maatkit-7540.tar.gz
Commands can be achieved delay replication.
Building process
You first need to build a good mysqlAB copy (traditional AB copy, copy-based GTIDs of AB, semi-synchronous replication and so can be), then do the following procedure
1, the delay needs to be done on the slave replication installation mattkit
(Note: master and slave without the normal installation)
2, to confirm the whole structure all the time synchronous machines
Since the delay is calculated by timing, the time must be consistent, all servers execute the following command, and compare time
3, run for the delay replication process
Consistent confirmation time, and AB in the case of normal copying, the following command on the slave
4, the test
View on slave replication status, you will find the SQL thread to NO, this is normal, because the delay in the IO thread is a real-time copy, but the SQL thread delayed
Then look at the master table insert a few test data, wait one minute, you will not see data replication success salve.