关于mysql:一个延迟库恢复的案例

41次阅读

共计 3688 个字符，预计需要花费 10 分钟才能阅读完成。

  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

  • 导语

在日常工作中可能会存在误删数据的状况，明天就简略介绍下如何利用提早库进行数据库的疾速复原。

步骤

1. 环境筹备

建设一个测试的主从库，写入一些测试数据，非本文要点，过程略。

2. 设置提早同步

在原有同步信息的根底上进行如下操作，设置提早同步 1 小时 

# 设置提早 1 小时
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  -> 设置后，这里能够看到提早的信息
          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. 假如在主库上进行了一个误删的操作 

# 误删一条 id=9998 的数据
mysql> delete from t1 where id=9998;
Query OK, 1 row affected (0.32 sec)

# 主库曾经没有了
mysql> select * from t1 where id=9998;
Empty set (0.00 sec)

# 从库还能查到数据
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. 解析主库的 binlog 文件

这个步骤目标是找到主库执行删除操作时候相应的 GTID 值的上一个 GTID 值 

# 先解析出 binlog
mysqlbinlog -vvv --base64-output=decode-rows mysql-bin.000001 > 01.sql

# 找到被删那条记录的 GTID, 再往上一条记录

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. 从库设置同步进行的工夫点

通过步骤 4 找到的删除操作的 GTID 值，咱们批改下从库的同步状态，须要阐明的是，当主库呈现误删数据的时候，提早库肯定要第一工夫进行同步。

# 从库同步到删数据的 gtid 值，再往上一条 gtid，设置同步截止点
mysql> STOP SLAVE;
mysql> START REPLICA UNTIL SQL_AFTER_GTIDS='4b4539dd-2fc1-11ec-949b-70b5e873a570:54229';
mysql> START SLAVE;

6. 复制同步进行 

# 期待同步到对应截止点后，同步的 SQL 线程会进行
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 -> 达到设定的 GTID 值后，SQL 线程会中断
              Until_Condition: SQL_AFTER_GTIDS -> 设置后这里会呈现同步截止的要害信息
             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. 数据恢复

后续咱们能够对这个表进行相应操作，例如把这个表导出再导入到主库，而后再复原两头的 logbin 数据。

总结

以上只是模仿一条数据误删的复原过程，通过闪回工具甚至手动找到相应误删的数据进行复原会更快，然而对于 truncate，drop，delete 忘了带 where 条件 的删除，用闪回工具可能就没方法了，相比备份复原用提早库效率会更高。

另外须要留神，如果从库开启了 MTS，须要留神开启 slave_preserve_commit_order=1 避免从库误删操作先执行了。

Enjoy GreatSQL :)

文章举荐：

面向金融级利用的 GreatSQL 正式开源
https://mp.weixin.qq.com/s/cI…

Changes in GreatSQL 8.0.25 (2021-8-18)
https://mp.weixin.qq.com/s/qc…

MGR 及 GreatSQL 资源汇总
https://mp.weixin.qq.com/s/qX…

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…

在 Linux 下源码编译装置 GreatSQL/MySQL
https://mp.weixin.qq.com/s/WZ…

# 对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr…

GitHub:

https://github.com/GreatSQL/G…

Bilibili：

https://space.bilibili.com/13…

微信 &QQ 群：

可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！

正文完
mysql
发表至： mysql
2022-04-11
 0
关于mysql:捉虫日记-MySQL-5720-tryacquirelockimpl-异常导致mysql-crash
关于mysql:Mysql源码分析基于行的复制实现之主从复制
关于mysql:2mysql架构
关于mysql:故障分析-没安装-validatepassword-插件为什么会有密码策略