MYSQL-基于GTID进行时间点恢复
Posted monkeybron
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MYSQL-基于GTID进行时间点恢复相关的知识，希望对你有一定的参考价值。
基于mysqlgtid 进行时间点恢复
要求：恢复到tybdata deposit_activity 表10月7日04:59:59
1：选择10月6日的完全备份恢复到另外一个库,过程略.
2：找到10月7日4点到5点的binlog文件，解析gtid位置：
-rw-r-----. 1 mysql mysql 1073742964 Oct 7 01:00 mysql_bin.002564 -rw-r-----. 1 mysql mysql 1073742134 Oct 7 02:17 mysql_bin.002565 -rw-r-----. 1 mysql mysql 1073742368 Oct 7 03:55 mysql_bin.002566 -rw-r-----. 1 mysql mysql 1073742307 Oct 7 05:43 mysql_bin.002567 ---->解析该binlog -rw-r-----. 1 mysql mysql 1073743162 Oct 7 08:15 mysql_bin.002568 -rw-r-----. 1 mysql mysql 1073743188 Oct 7 09:33 mysql_bin.002569 -rw-r-----. 1 mysql mysql 1073742941 Oct 7 10:53 mysql_bin.002570
sudo mysqlbinlog -vvv --base64-output=DECODE-ROWS mysql_bin.002567 > 1.txt grep -n -C 10 "SET @@SESSION.GTID_NEXT" 1.txt > 2.txt
vim 2.txt
/191007 5:00:00
16784205 65054598-#191007 4:59:59 server id 111 end_log_pos 771918266 CRC32 0xf9d13b67 GTID last_committed=762918 sequence_number=762919 rbr_only=yes 16784206 65054599-/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; 16784207 65054600:SET @@SESSION.GTID_NEXT= ‘92d337cc-32c8-11e8-969b-6805ca408e49:3289185391‘/*!*/; 16784208 65054601-# at 771918266 16784209 65054602-#191007 4:59:59 server id 111 end_log_pos 771918329 CRC32 0xaed539cd Query thread_id=1087824590 exec_time=0 error_code=0 16784210 65054603-SET TIMESTAMP=1570395599/*!*/; 16784211 65054604-BEGIN 16784212 65054605-/*!*/; 16784213 65054606-# at 771918329 16784214 65054607-#191007 4:59:59 server id 111 end_log_pos 771918444 CRC32 0x8cc64b48 Rows_query 16784215 65054608-# UPDATE `member_api` SET `money` = ‘0.00‘ WHERE `api_id` = ‘32‘ AND `member_id` = ‘554111‘ 16784216 65054609-# at 771918444 16784217 65054610-#191007 4:59:59 server id 111 end_log_pos 771918519 CRC32 0x1eecffff Table_map: `tybdata`.`member_api` mapped to number 1174 16784218 -- 16784219 65054630-### @6=0.00 /* DECIMAL(16,2) meta=4098 nullable=0 is_null=0 */ 16784220 65054631-### @7=‘‘ /* VARSTRING(1020) meta=1020 nullable=1 is_null=0 */ 16784221 65054632-### @8=1539515523 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */ 16784222 65054633-### @9=1550546492 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */ 16784223 65054634-# at 771918677 16784224 65054635-#191007 4:59:59 server id 111 end_log_pos 771918708 CRC32 0x021658d7 Xid = 10586330904 16784225 65054636-COMMIT/*!*/; 16784226 65054637-# at 771918708 16784227 65054638-#191007 5:00:00 server id 111 end_log_pos 771918773 CRC32 0x23474a26 GTID last_committed=762919 sequence_number=762920 rbr_only=yes 16784228 65054639-/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; 16784229 65054640:SET @@SESSION.GTID_NEXT= ‘92d337cc-32c8-11e8-969b-6805ca408e49:3289185392‘/*!*/;
3:解读 SQL_BEFORE_GTIDS ，SQL_after_GTIDS
START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56导致从属 SQL 线程处理来自 master 的 master 的所有 transactions，
直到遇到序列号为 11 的 transaction;它然后停止而不处理此 transaction。换句话说，处理所有 transactions 直到并包括序列号为 10 的 transaction。
另一方面，执行START SLAVE SQL_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56会导致从 SQL 线程获取 master 中刚才提到的所有 transactions，
包括序列 numbers 11 到 56 的所有 transactions，然后停止而不处理任何额外的 transactions;也就是说，序列号为 56 的 transaction 将是从属 SQL 线程获取的最后一个 transaction。
4：开始进行时间点恢复，
CHANGE REPLICATION FILTER Replicate_Do_Table = (tybdata.deposit_activity) ; slave_skip_errors = ALL ---跳过一些故障事务 start slave UNTIL SQL_BEFORE_GTIDS =‘92d337cc-32c8-11e8-969b-6805ca408e49:3289185392‘;
5：利用slave 前滚
root@localhost[(none)]> show slave status G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.30.1 Master_User: backup Master_Port: 3306 Connect_Retry: 1000 Master_Log_File: mysql_bin.002639 Read_Master_Log_Pos: 123866921 Relay_Log_File: relay-log.000080 Relay_Log_Pos: 771918921 Relay_Master_Log_File: mysql_bin.002567 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 771918708 Relay_Log_Space: 77434499764 Until_Condition: SQL_BEFORE_GTIDS ——————>追到需要的时间点gtid Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL ---->显示为NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 143306 Master_UUID: 25d5fdd0-a92b-11e8-b580-e04f439bb65b Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 92d337cc-32c8-11e8-969b-6805ca408e49:3265269471-3358679623 Executed_Gtid_Set: 92d337cc-32c8-11e8-969b-6805ca408e49:1-3289185391 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)
6：验证：
root@localhost[tybdata]> select max(created_at),min(created_at) from deposit_activity; +---------------------+---------------------+ | max(created_at) | min(created_at) | +---------------------+---------------------+ | 2019-10-07 04:59:17 | 2018-01-25 16:40:20 | +---------------------+---------------------+ 1 row in set (0.12 sec)
以上是关于MYSQL-基于GTID进行时间点恢复的主要内容，如果未能解决你的问题，请参考以下文章
基于gtid的备份_恢复_注意事项_mysqldump_skip-gtids_include-gtids_exclude-gtids