阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

通过MySQL复制线程SQL_Thread加快增量恢复binlog

239次阅读
没有评论

共计 4189 个字符,预计需要花费 11 分钟才能阅读完成。

数据回档常常是使用全量备份 +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/mysqlrelay.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 即可

⑤ 检查复制状态:

  1. mysql> SHOW SLAVE STATUS\G
  2. *************************** 1. row ***************************
  3. Slave_IO_State:
  4. Master_Host: 1
  5. Master_User: 1
  6. Master_Port: 3306
  7. Connect_Retry: 60
  8. Master_Log_File: 1
  9. Read_Master_Log_Pos: 4
  10. Relay_Log_File: mysql-relay.000003    — 已经执行到的日志名
  11. Relay_Log_Pos: 11529982        — 已经执行到日志 的位置
  12. Relay_Master_Log_File: 1
  13. Slave_IO_Running: No
  14. Slave_SQL_Running: Yes
  15. Replicate_Do_DB:
  16. Replicate_Ignore_DB:
  17. Replicate_Do_Table:
  18. Replicate_Ignore_Table:
  19. Replicate_Wild_Do_Table:
  20. Replicate_Wild_Ignore_Table:
  21. Last_Errno: 0
  22. Last_Error:
  23. Skip_Counter: 0
  24. Exec_Master_Log_Pos: 11529982
  25. Relay_Log_Space: 5347038913
  26. Until_Condition: None
  27. Until_Log_File:
  28. Until_Log_Pos: 0
  29. Master_SSL_Allowed: No
  30. Master_SSL_CA_File:
  31. Master_SSL_CA_Path:
  32. Master_SSL_Cert:
  33. Master_SSL_Cipher:
  34. Master_SSL_Key:
  35. Seconds_Behind_Master: 274354        — 若变为 0,则表示 已经增量完毕
  36. Master_SSL_Verify_Server_Cert: No
  37. Last_IO_Errno: 0
  38. Last_IO_Error:
  39. Last_SQL_Errno: 0
  40. Last_SQL_Error:
  41. Replicate_Ignore_Server_Ids:
  42. Master_Server_Id: 0
  43. Master_UUID:
  44. Master_Info_File: /data/mysql57/master.info
  45. SQL_Delay: 0
  46. SQL_Remaining_Delay: NULL
  47. Slave_SQL_Running_State: Reading event from the relay log
  48. Master_Retry_Count: 86400
  49. ………………………………

该测试使用的版本为:MySQL 5.7.16

场景 :可用于 恢复 将 innodb_force_recovery 设置为 6 仍然无法启动实例等 case
效果 :恢复 全备文件 +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 与 通过在启动 S QL_Thread 时指定 UNTIL RELAY_LOG_FILE = ‘log_name’, RELAY_LOG_POS = log_pos 等效:
用途都是指定结束执行的最后一个 position。

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-09/146648.htm

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-22发表,共计4189字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中