Using MySQL master-slave replication delay to save erroneously deleted data

Introduction

In daily work, data may be deleted by mistake , Today, I will briefly introduce how to use master-slave replication to delay the rapid recovery of databases from the slave database .

step

1. Environmental preparation

Establish a master-slave library for testing , Write some test data , Non key points of this article , The process is brief .

2. Set delay synchronization

Based on the original synchronization information, perform the following operations , Set delay synchronization 1 Hours

#  Setup delay 1 Hours
mysql> stop slave;
mysql> CHANGE REPLICATION SOURCE TO SOURCE_DELAY=3600; 
mysql> start slave;
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting  for master to send event
                  Master_Host: 192.168.5.160
                  Master_User: repl
                  Master_Port: 3314
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 6536
                    SQL_Delay: 3600  ->  After setting , Here you can see the delay information
          SQL_Remaining_Delay: NULL
           Retrieved_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:2-53662
            Executed_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:1-36546,
d2c64073-2cb5-11ec-b4d1-70b5e873a570:1-2
1 row  in  set, 1 warning (0.00 sec)

3. Suppose a false deletion operation is performed on the main database

#  Delete one by mistake id=9998 The data of
mysql> delete from t1  where id=9998;
Query OK, 1 row affected (0.32 sec)

#  The main library is gone
mysql> select * from t1  where id=9998;
Empty  set (0.00 sec)

#  Data can also be found from the library
mysql> select * from t1  where id=9998;
+-----+------+------+------+------+
| id  | c1   | c2   | c3   | c4   |
+-----+------+------+------+------+
| 9998| 983  | xAP9 | mQeN | 8Eu2 |
+-----+------+------+------+------+
1 row  in  set (0.00 sec)

4. Resolve the main library of binlog file

The purpose of this step is to find the corresponding... When the main database is deleted GTID The previous of the value GTID value

#  First parse out binlog
mysqlbinlog -vvv --base64-output=decode-rows mysql-bin.000001 > 01.sql

#  Find the deleted record GTID, One more record

SET @@SESSION.GTID_NEXT=  '4b4539dd-2fc1-11ec-949b-70b5e873a570:54230'/*!*/;
# at 15959245
#211103 14:43:25 server id 33145160  end_log_pos 15959316       Query   thread_id=53817 exec_time=0     error_code=0
# at 15959377
#211103 14:43:25 server id 33145160  end_log_pos 15959436       Delete_rows: table id 270 flags: STMT_END_F
### DELETE FROM `test`.`t1`
### WHERE
###   @1=9998 /* INT meta=0 nullable=0 is_null=0 */
###   @2='983' /* VARSTRING(256) meta=256 nullable=1 is_null=0 */
###   @3='xAP9' /* VARSTRING(256) meta=256 nullable=1 is_null=0 */
###   @4='mQeN' /* VARSTRING(256) meta=256 nullable=1 is_null=0 */
###   @5='8Eu2' /* VARSTRING(256) meta=256 nullable=1 is_null=0 */
# at 15959436
#211103 14:43:25 server id 33145160  end_log_pos 15959463       Xid = 163705
COMMIT/*!*/;
# at 15959463

5. Set the point in time when synchronization stops from the library

Pass step 4 Delete operation found GTID value , Let's modify the synchronization status of the slave Library , It should be noted that , When the main database mistakenly deletes data , The delay library must stop synchronization at the first time .

#  From database synchronization to data deletion gtid value , One more gtid, Set the synchronization deadline , there gtids Be consistent with the main database
mysql> STOP SLAVE;
mysql> START REPLICA UNTIL SQL_AFTER_GTIDS= '4b4539dd-2fc1-11ec-949b-70b5e873a570:2-54229';
mysql> START SLAVE;

6. Replication synchronization stopped

#  Wait for synchronization to the corresponding cut-off point , synchronous SQL The thread will stop
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting  for master to send event
                  Master_Host: 192.168.5.160
                  Master_User: repl
                  Master_Port: 3314
                Connect_Retry: 60
             Slave_IO_Running: Yes
            Slave_SQL_Running: No ->  Reach the set GTID After value ,SQL The thread will break
              Until_Condition: SQL_AFTER_GTIDS ->  After setting, the key information of synchronization deadline will appear here
             Master_Server_Id: 33145160
                  Master_UUID: 4b4539dd-2fc1-11ec-949b-70b5e873a570
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
           Master_Retry_Count: 86400
           Retrieved_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:2-54230
            Executed_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:1-54229,
d2c64073-2cb5-11ec-b4d1-70b5e873a570:1-3
                Auto_Position: 1

7. Data recovery

Later, we can operate the table accordingly , For example, export this table and then import it to the main database , Then restore the middle binlog data .

summary

The above is just a simulation of the recovery process of a data deletion , It will be faster to recover through flashback tools or even manually finding the corresponding deleted data , But for truncate,drop,delete I forgot to bring it where Conditions The deletion of , There may be no way to use the flashback tool , Compared with backup and recovery, the delay library will be more efficient .

In addition, we need to pay attention to , If opened from the library MTS, Attention should be paid to opening slave_preserve_commit_order=1 To prevent accidental deletion from the library, first execute .

Enjoy GreatSQL :)