平武建站

如何通过MySQLrelaylog+SQL_Thread增量恢复binlog

这篇文章给大家介绍如何通过MySQL relaylog + SQL_Thread 增量恢复binlog，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

创新互联公司服务项目包括黎川网站建设、黎川网站制作、黎川网页制作以及黎川网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，黎川网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到黎川省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

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

⑤ 检查复制状态：

  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

效果：恢复全备文件+binlog恢复到故障前的最后一个position。

其他场景也适用，比如在某一时刻执行了错误的sql，如truncate等操作，同样也可以通过该办法。
只需要将START SLAVE sql_thread后添加一个 UNTILRELAY_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。

关于如何通过MySQL relaylog + SQL_Thread 增量恢复binlog就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。


本文名称：如何通过MySQLrelaylog+SQL_Thread增量恢复binlog
网页地址：http://pwwzsj.com/article/jsiijg.html

其他资讯