前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >通过MySQL relaylog + SQL_Thread 增量恢复binlog

通过MySQL relaylog + SQL_Thread 增量恢复binlog

作者头像
保持热爱奔赴山海
发布2019-09-17 14:38:45
1.4K0
发布2019-09-17 14:38:45
举报
文章被收录于专栏:数据库相关

原文地址:http://blog.itpub.net/29773961/viewspace-2143726/

数据回档常常是使用全量备份+binlog增量实现的。 而数据量很大的情况下,增量恢复binlog一直是一个苦恼的问题,因为恢复binlog速度十分慢,并且容易出错。 恢复binlog文件一般有两种方法: 〇 先解析成sql文件,再导入MySQL

  1. mysqlbinlog mysql-bin.000001 --start-position=n > /data/add.sql
  2. mysqlbinlog mysql-bin.000002 ... mysql-bin.n >> /data/add.sql
  3. mysql -u -p -S < /data/add.sql

〇 直接管道到MySQL中

  1. mysqlbinlog mysql-bin.000001 --start-position=n | mysql -u -p -S
  2. mysqlbinlog mysql-bin.000002 ... mysql-bin.n | mysql -u -p -S

关于这种方式的更多info,可以参考: https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html 然而这两种方式原理都是一样的,通过mysqlbinlog解析成sql并导入到MySQL中。 〇 优点:     操作方便,逻辑简单。     无需关闭mysqld。 〇 缺点:     遇到ERROR难以定位位置,难以“断点恢复”。     特殊字符或字符集的问题。     max_allowed_packet问题。     恢复速度慢。


因为relaylog和binlog本质实际上是一样的,所以是否可以利用MySQL自身的sql_thread来增量binlog呢? 〇 处理思路:     1)重新初始化一个实例,恢复全量备份文件。     2)找到第一个binlog文件的position,和剩下所有的binlog。     3)将binlog伪装成relaylog,通过sql thread增量恢复。 这里只介绍核心部分,即伪装成relaylog的过程。 ① 将relay log info的repository改到file中,并生成这个文件。

  1. SET GLOBAL relay_log_info_repository='FILE';
  2. CHANGE MASTER TO master_host='1',master_password='1',master_user='1',master_log_file='1',master_log_pos=4;

通过change命令,是为了告诉MySQL自己为一个slave实例,因为无需用到IO_Thread,故host,password,user等可以随意填写。 并且通过该步骤,生成relay.info文件。 ② 关闭实例,将需要增量的binlog文件伪装成relaylog。

  1. cp mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.000007 mysql-bin.000008 mysql-bin.000009 mysql-bin.000010 $relaylogdir
  2. cd $relaylogdir
  3. rename mysql-bin. mysql-relay. mysql-bin.0000*
  4. chown mysql:mysql -R .

通过cp命令将binlog移动到$relaylogdir里,该变量取决于实例的选项参数,默认放在datadir下。 再将binlog批量改名成relaylog,并且给予对应的权限,否则会报错OS error code  13:  Permission denied。 ③ 修改relay.info文件和relay-log.index文件 将relay.info的第二三行改成需要执行的第一个binlog(现在是relaylog)的文件名和position:

  1. /data/mysql57/relaylog/mysql-relay.000003
  2. 1276895

第二三行对应Relay_log_name和Relay_log_pos,等同于: mysqlbinlog mysql-relay.000003 --start-position=1276895 | mysql -u -p -S 修改该文件是为了告诉SQL_Thread从哪一个文件和哪一个position开始执行事务 再修改relay-log.index,清空原有信息,添加以下信息,为的是告诉SQL_Thread还有哪些relaylog是需要执行的。

  1. /data/mysql57/relaylog/mysql-relay.000003
  2. /data/mysql57/relaylog/mysql-relay.000004
  3. /data/mysql57/relaylog/mysql-relay.000005
  4. /data/mysql57/relaylog/mysql-relay.000006
  5. /data/mysql57/relaylog/mysql-relay.000007
  6. /data/mysql57/relaylog/mysql-relay.000008
  7. /data/mysql57/relaylog/mysql-relay.000009
  8. /data/mysql57/relaylog/mysql-relay.000010

④ 启动实例,开启SQL_Thread:

  1. START SLAVE sql_thread ;

只需要开启SQL_Thread即可 ⑤ 检查复制状态:

代码语言:javascript
复制
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 1
Master_User: 1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 1
Read_Master_Log_Pos: 4
Relay_Log_File: mysql-relay.000003 -- 已经执行到的日志名
Relay_Log_Pos: 11529982  -- 已经执行到日志的位置
Relay_Master_Log_File: 1
Slave_IO_Running: No
Slave_SQL_Running: Yes
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: 11529982
Relay_Log_Space: 5347038913
Until_Condition: None
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: 274354  -- 若变为0,则表示已经增量完毕
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: 0
Master_UUID:
Master_Info_File: /data/mysql57/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
Master_Retry_Count: 86400
………………………………

该测试使用的版本为:MySQL 5.7.16 效果:恢复全备文件+binlog恢复到故障前的最后一个position。 其他场景也适用,比如在某一时刻执行了错误的sql,如truncate等操作,同样也可以通过该办法。 只需要将START SLAVE sql_thread后添加一个 UNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos 即可。 该选项用于控制SQL_Thread执行到的最后的position,类似于mysqlbinlog mysql-bin.n --stop-position=$log_pos 。 除了更准确的能够恢复错误之外,还有一个最大的好处是加快了binlog增量的速度。 补充一个额外的测试数据 对于同一组binlog文件增量: 通过mysqlbinlog解析+导入的时间为69min。 而通过SQL_Thread的执行时间为41min。 并且在需要增量的binlog文件越大的情况下,效果越明显。 〇 优点:     可以断点恢复,人为控制进度,比如stop slave或者遇到错误时,可以断点恢复。     性能好,在大量binlog的情况下,可以加快恢复速度。     在某些版本可以利用多线程复制来加快增量速度,时恢复更快。 〇 缺点:     需要关闭mysqld。     手动执行过程较mysqlbinlog方式更为复杂。 〇 总结: mysqlbinlog --start-position 与 通过修改relay.info的第三行等效: 用途都是指定开始执行的第一个position。 mysqlbinlog --stop-position 与 通过在启动SQL_Thread时指定UNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos等效: 用途都是指定结束执行的最后一个position。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019/04/06 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档