mysql binlog线程恢复_使用MySQL SQL线程回放Binlog实现恢复

最新推荐文章于 2024-03-03 10:57:24 发布

胃泰小胃君

最新推荐文章于 2024-03-03 10:57:24 发布

阅读量217

点赞数

CC 4.0 BY-SA版权

文章标签： mysql binlog线程恢复

本文链接：https://blog.youkuaiyun.com/weixin_35675818/article/details/113261825

本文详细介绍了如何使用MySQL的SQL线程回放binlog进行数据恢复，包括全量备份、模拟数据变化、恢复流程、单库和单表恢复、指定GTID点恢复以及效率优化。通过实验对比，表明SQL线程恢复相比mysqlbinlog具有更高的效率和灵活性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 需求部分

1.1 基于MySQL复制同步特性，尝试使用Replication的SQL线程来回放binlog，可基于以下逻辑模拟场景

做全量xtrabackup备份模拟日常备份

执行sysbench压测4张表，20个线程，压测10分钟，模拟大量binlog

删除实例模拟数据库被误删除或硬件故障(binlog需要保留)

使用xtrabackup恢复全量备份

使用MySQL Replication SQL线程回放binlog(提示:恢复前需要将relay_log_recocery参数设置为0)

1.2 基于题目1.1，考虑是否可以做到以下场景的恢复

只恢复单个库的数据

只恢复单个表的数据

将数据恢复到指定的GTID或者position点(如恢复到误操作drop之前的GTID)

是否可以通过参数调整提升回放效率，列出提升效率的参数并实际测试用SQL线程回放binlog和直接使用mysqlbinlog回放binlog的性能对比

2.操作部分

2.1 环境准备及故障模拟

使用mysqlbinlog将binlog文件实时转储到备份目录(当前环境备份目录配置在/data/mysql/backup)

[root@10-186-61-162 ~]# mkdir -p /data/mysql/backup/binlog

[root@10-186-61-162 ~]# mysqlbinlog --raw --read-from-remote-server -h10.186.61.162 -urepl -pxxx -P3306 --result-file=/data/mysql/backup/binlog/ mysql-bin.000001 --stop-never --stop-never-slave-server-id=100 &

生成sysbench测试数据,创建4张表，每张各100W数据库并压测一分钟模拟数据变化

## 插入基础数据

[root@10-186-61-162 ~]# sysbench /usr/local/share/sysbench/oltp_read_write.lua --db-ps-mode=disable --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=sysbench --mysql-password=xxx --mysql-db=sbtest --tables=4 --table-size=1000000 --report-interval=1 --time=600 --threads=20 prepare

## 执行sysbench压测模拟数据变化，压测1分钟

执行物理备份模拟每天的全量备份

[root@10-186-61-162 ~]# innobackupex --host=10.186.61.162 --port=3306 --user=backup --password=xxx /data/mysql/backup/

继续执行压测，模拟备份后的数据变化，压测10分钟，模拟大量binlog

停止并删除数据库数据库模拟误操作或硬件故障

[root@10-186-61-162 ~]# systemctl stop mysql_3306

[root@10-186-61-162 ~]# rm -rf /data/mysql/data/*

2.2 数据恢复

还原xtrabackup全量备份

[root@10-186-61-162 ~]# cd /data/mysql/backup

[root@10-186-61-162 backup]# innobackupex --apply-log 2020-03-02_17-39-07/

[root@10-186-61-162 backup]# innobackupex --defaults-file=/etc/my.cnf --copy-back 2020-03-02_17-39-07/

将binlog转换为relay log并拷贝到数据目录以便SQL线程回放数据

[root@10-186-61-162 backup]# cd /data/mysql/backup/binlog/

## 将binlog重命名为relay log

[root@10-186-61-162 binlog]# rename mysql-bin mysql-relay mysql-bin*

## 创建relay log index文件

[root@10-186-61-162 binlog]# ls ./mysql-relay.0000* >mysql-relay.index

## 拷贝relay log到数据目录

[root@10-186-61-162 binlog]# cp mysql-relay.* /data/mysql/data/

## 修改数据目录权限

[root@10-186-61-162 binlog]# chown -R mysql:mysql /data/mysql/data/

修改relay_log_recovery参数，设置为0并启动数据库,relay_log_recovery为1时，relay log会在复制线程启动时被清除重新拉

## 获取备份文件中的binlog位点信息及GTID点对应的relay log文件

[root@10-186-61-162 ~]# cd /data/mysql/backup/2020-03-02_17-39-07/

[root@10-186-61-162 2020-03-02_17-39-07]# cat xtrabackup_binlog_info

mysql-bin.00000780456866f41abe78-5c62-11ea-abf1-02000aba3da2:1-52013

## 启动数据库

[root@10-186-61-162 2020-03-02_17-39-07]# systemctl start mysql_3306

## change master指定一个空的主库，创建SQL线程

root@localhost[(none)]> reset master;

## 指定备份文件中对应的binlog位点

root@localhost[(none)]> CHANGE MASTER TO MASTER_HOST='1.1.1.1',RELAY_LOG_FILE='mysql-relay.000007',RELAY_LOG_POS=80456866;

## 查看指定的位点是否生效

root@localhost[(none)]> select * from mysql.slave_relay_log_info;

+-----------------+----------------------+---------------+-----------------+----------------+-----------+-------------------+----+--------------+

+-----------------+----------------------+---------------+-----------------+----------------+-----------+-------------------+----+--------------+

| 7 | ./mysql-relay.000007 | 80456866 | | 0 | 0 | 0 | 1 | |

+-----------------+----------------------+---------------+-----------------+----------------+-----------+-------------------+----+--------------+

## 只需要开启SQL线程对指定的relay log开始回放即可

root@localhost[(none)]> START SLAVE SQL_THREAD;

## 持续执行可看到binlog数据开始回放

root@localhost[(none)]> show slave status\G

## 待binlog恢复完成且数据校验无问题后后可将复制关系重置

root@localhost[(none)]> stop slave;

root@localhost[(none)]> reset slave;

root@localhost[(none)]> reset slave all;

2.3 只恢复单个库的数据

由于备份是全量备份，无法单库还原(如果已知表结构可使用可传输表空间方式单库还原)，可先将全量恢复后对只对单库做binlog还原

只需在2.2数据恢复的基础上增加一条以下命令即可实现对sbtest单库的binlog还原

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('sbtest.%');

2.4 只恢复单个表的数据

该步骤与单库还原类似，只需将复制过滤属性指定为具体的表，如

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('sbtest.sbtest1','sbtest.sbtest2');

可在开启binlog还原前后对sbtest1-4表做checksum，验证是否只有sbtest1和sbtest2做了binlog还原

checksum table sbtest1,sbtest2,sbtest3,sbtest4;

2.5 恢复到指定的GTID或position点

该步骤只需在2.2数据恢复的基础上，将START SLAVE SQL_THREAD改为START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS，如只恢复到GTID=499999

START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 'f41abe78-5c62-11ea-abf1-02000aba3da2:500000;

2.6 提升恢复效率的参数优化

set global sync_binlog=0;

set global innodb_flush_log_at_trx_commit=0;

set global slave_parallel_type=LOGICAL_CLOCK;

set global slave_parallel_workers=8;

关闭binlog

2.7 使用复制线程与使用mysqlbinlog恢复的效率对比

mysqlbinlog

恢复耗时 722s

SQL线程

恢复耗时 151s

2.8 总结

使用SQL线程恢复binlog数据相对比mysqlbinlog有以下优势

只需配置好复制让数据库自动恢复数据即可

可以使用MySQL并行复制特性，提升恢复效率

可以精细化的控制恢复的库表

可以指定恢复到具体的GTID点以及跳过误操作的GTID

2.9 恢复优化

假设一个每天凌晨备份，某天早上8点数据库被误操作drop了业务库，请说明恢复的流程

保持主库当前状态

使用主库的备份恢复一个实例

使用change master to后在启动开启START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS方式让复制同步数据到drop操作之前

跳过drop操作的gtid

继续同步复制