MySQL relaylog + SQL_Thread 增量恢復binlog

1、設置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                                          |
+----------------------------------+----------------------------------------------+

2、開始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.三、刪掉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.四、告訴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

3、此恢復的方式總結

優勢：
能夠斷點恢復，人爲控制進度，好比stop slave或者遇到錯誤時，能夠斷點恢復。
性能好，在大量binlog的狀況下，能夠加快恢復速度。
在某些版本能夠利用多線程複製來加快增量速度，時恢復更快。
缺點：
須要關閉mysqld。
手動執行過程較mysqlbinlog方式更爲複雜。

4、解決疑惑以下：

Q1總體上看binlog和relay-log結構是不是一致的？？？
答：總體上看binlog和relay-log結構上是一致的
Q2 binlog的filename和relay-log的filename是否是有關係？
答：沒必然的關係的
Q3 把Binlog手工改爲Relay-log是否是可行？
答：是能夠的
Q4 Relay-log相關的記錄信息有哪些？

5、利用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/