MySQL relaylog + SQL_Thread 增量恢复binlog

Posted 2022-07-30

一、设置3308实例的已经执行过的gtid号为当天全量备份结束时的gtid号

查看当天xtrabackup全量备份时结束的binlog文件名，binlog的pos 位置点，以及全量备份结束后的Gtid号：

[root@mgr01 backup]# cat /data/backup/db_3306_20190808/xtrabackup_info |grep binlog_pos
binlog_pos = filename ‘mysql-bin.000003‘, position ‘29571‘, GTID of the last change ‘bde7b592-b966-11e9-8c64-000c294f3e61:1-10296‘

使用xtrabackup工具恢复当天的全量备份到新的mysql 3308 实例：

 innobackupex  --apply-log   /data/backup/db_3306_20190808/
 190808 10:31:56 completed OK!
innobackupex --defaults-file=/data/mysql/mysql3308/my3308.cnf --copy-back /data/backup/db_3306_20190808/
 190808 10:41:38 completed OK!

给新实例3308的数据目录./data授权mysql用户权限：

 chown -R mysql.mysql  /data/mysql/mysql3308/data 

启动mysql 启动成功:

 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3308/my3308.cnf   &

由于mysql 3306和3308 都是开启gtid的，所以恢复全量备份数据到3308实例上，在启动3308实例后产生Gtid和实际的xtrabackup全量备份结束的Gtid号是不一样的，所以在恢复全备份到3308后，
启动并登录3308实例，reset master 清空当前的3308上的Gtid,然后再set global gtid_purged=‘bde7b592-b966-11e9-8c64-000c294f3e61:1-10296‘; 让3308 实例的Gtid号执行到全量备份结束时的这个Gtid号

(root@‘mgr01‘:mysql3308.sock)[(none)]>reset master;
Query OK, 0 rows affected (0.04 sec)
(root@‘mgr01‘:mysql3308.sock)[(none)]>show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 154
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 
1 row in set (0.00 sec)

(root@‘mgr01‘:mysql3308.sock)[(none)]>set global gtid_purged=‘bde7b592-b966-11e9-8c64-000c294f3e61:1-10296‘;
Query OK, 0 rows affected (0.06 sec)

(root@‘mgr01‘:mysql3308.sock)[(none)]>show master status\G
*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 154
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: bde7b592-b966-11e9-8c64-000c294f3e61:1-10296

(root@‘mgr01‘:mysql3308.sock)[(none)]>show global variables like "%Gtid%";
+----------------------------------+----------------------------------------------+
| Variable_name                    | Value                                        |
+----------------------------------+----------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                           |
| enforce_gtid_consistency         | ON                                           |
| gtid_executed                    | bde7b592-b966-11e9-8c64-000c294f3e61:1-10296 |
| gtid_executed_compression_period | 1000                                         |
| gtid_mode                        | ON                                           |
| gtid_owned                       |                                              |
| gtid_purged                      | bde7b592-b966-11e9-8c64-000c294f3e61:1-10296 |
| session_track_gtids              | OFF                                          |
+----------------------------------+----------------------------------------------+

二、开始MySQL relaylog + SQL_Thread 增量恢复binlog演示

3308 实例slave上操作：
2.1 change命令，是为了告诉MySQL自己为一个slave实例：

随便change master to master_host="192.168.1.10";

通过change命令，是为了告诉MySQL自己为一个slave实例，因为无需用到IO_Thread，故host，password，user等可以随意填写。
并且通过该步骤，生成relay.info文件。

CHANGE MASTER TO MASTER_HOST="192.168.1.10";

show slave status\G只要 
Auto_Position: 0 就行

2.2 关闭3308实例，将需要增量的binlog文件伪装成relaylog：

cp 3306binglog 日志文件到 mysql3308的数据目录data下

[root@mgr01 data]# cp /data/mysql/mysql3306/binlog/* /data/mysql/mysql3308/data/

rm -rf  /data/mysql/mysql3308/data/mysql-bin.index
cd /data/mysql/mysql3308/data/
rename mysql-bin relay-bin mysql-bin.*

并且给予伪装后的relay-log文件对应的权限mysql的权限

2.3、删掉relay.info文件和修改relay-log.index文件：

移除掉 /data/mysql/mysql3308/data/ 下面的原有的relay-log.info  文件。
编辑 mgr01-relay-bin.index 文件，添加relay log文件名称到此文件，为的是告诉SQL_Thread还有哪些relaylog是需要执行的。
[root@mgr01 data]# cat mgr01-relay-bin.index 
./mgr01-relay-bin.000001
./relay-bin.000003
./relay-bin.000004
./relay-bin.000005
./relay-bin.000006

2.4、告诉3308 slave的sql_thread增量的relaylog文件要从哪个文件名以及pos位置点开始执行：

[root@mgr01 backup]# cat /data/backup/db_3306_20190808/xtrabackup_info |grep binlog_pos
binlog_pos = filename ‘mysql-bin.000003‘, position ‘29571‘, GTID of the last change ‘bde7b592-b966-11e9-8c64-000c294f3e61:1-10296‘

CHANGE MASTER TO   RELAY_LOG_FILE=‘relay-bin.000003‘,   RELAY_LOG_POS=29571;

该选项用于告诉SQL_Thread从哪个relay log文件以及pos位置点（也就是3306实例上当天的全量备份结束的binlog文件名和pos位置点）开始执行relay log文件恢复数据到slave 3308实例
也就是说在恢复全量备份的数据到3308 上后，接下来就是利用伪装好的relay log文件（也就是3306实例上当天的全量备份结束的binlog文件名和pos位置点）+sql_thread 线程 开始执行relay log文件恢复数据到slave 3308实例

START SLAVE   SQL_THREAD    UNTIL    MASTER_LOG_FILE = ‘mysql-bin.000005‘, MASTER_LOG_POS =15018; ##此处的Gtid是drop table test1_event 前的最近的一个binlog的文件的pos位置点
 或者是：
 START SLAVE   SQL_THREAD  UNTIL   SQL_BEFORE_GTIDS=‘bde7b592-b966-11e9-8c64-000c294f3e61:10445‘  ##此处的Gtid是drop table test1_event 前的最近的一个Gtid

三、此恢复的方式总结

优点：
可以断点恢复，人为控制进度，比如stop slave或者遇到错误时，可以断点恢复。
性能好，在大量binlog的情况下，可以加快恢复速度。
在某些版本可以利用多线程复制来加快增量速度，时恢复更快。
缺点：
需要关闭mysqld。
手动执行过程较mysqlbinlog方式更为复杂。

四、解决疑惑如下：

Q1整体上看binlog和relay-log结构是否是一致的？？？
答：整体上看binlog和relay-log结构上是一致的
Q2 binlog的filename和relay-log的filename是不是有关系？
答：没必然的关系的
Q3 把Binlog手工改成Relay-log是不是可行？
答：是可以的
Q4 Relay-log相关的记录信息有哪些？

五、利用SQL_thread快速恢复增量过程总结：

1.不能使用master_auto_position=1
2.先要让mysql知道他是一个Slave
3.关掉mysql，构建relay-log
4.利用change master to relay_log_file=... ,
relay_log_pos=...;
5.START SLAVE SQL_THREAD UNTIL MASTER_LOG_FILE=‘xxx‘,MASTER_LOG_POS=xxxxx
或者START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS=‘xxx--xx-x‘;

START SLAVE   SQL_THREAD    UNTIL    MASTER_LOG_FILE = ‘mysql-bin.000005‘, MASTER_LOG_POS =15018; ##此处的Gtid是drop table test1_event 前的最近的一个binlog的文件的pos位置点
 或者是：
 START SLAVE   SQL_THREAD  UNTIL   SQL_BEFORE_GTIDS=‘bde7b592-b966-11e9-8c64-000c294f3e61:10445‘  ##此处的Gtid是drop table test1_event 前的最近的一个Gtid

参考博文地址：
下面的恢复方法参考文档：
http://blog.itpub.net/29773961/viewspace-2143726/