MySQL relaylog + SQL_Thread incremental recovery binlog

First, set the example of 3308 has been executed gtid number gtid number at the end of the day full backup

View binlog file name xtrabackup day when full backup end, binlog pos position of the point, and after the end of the full backup Gtid number:

[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'

Use xtrabackup tool to restore full backup to the day of the new mysql 3308 Example:

 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!

Examples of the data directory to the new 3308 ./data authorized mysql user privileges:

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

Start mysql start successfully:

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

Because mysql 3306 and 3308 are open gtid, so to restore full backup data to a 3308 instance, produce Gtid and the end of the actual xtrabackup full backup Gtid number after starting the 3308 instance is not the same, so the restored full backup to 3308 after
start 3308 and log example, reset master clear Gtid 3308 on the current, and then set global gtid_purged = 'bde7b592-b966-11e9-8c64-000c294f3e61 : 1-10296'; 3308 let to a number of executing instances full backup Gtid the number at the end of 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                                          |
+----------------------------------+----------------------------------------------+

Second, start MySQL relaylog + SQL_Thread incremental recovery binlog demo

Examples of operations on the 3308 slave:
2.1 Change command, is to tell MySQL itself as a slave instance:

随便change master to master_host="192.168.1.10";

By change orders, to tell MySQL itself as a slave instance, because no use IO_Thread, so the host, password, user, etc. are free to fill in.
And by the step of generating relay.info file.

CHANGE MASTER TO MASTER_HOST="192.168.1.10";

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

3308 closed 2.2 instance, you will require incremental binlog file disguised as 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.*

And relay-log files corresponding to the authority given to camouflage mysql permissions

2.3, delete and modify files relay.info relay-log.index file:

移除掉 /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, tell sql_thread incremental relaylog 3308 slave file of which file name and location pos point started from:

[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;

This option is used to tell SQL_Thread which relay log file and position pos point (that is, the 3306 full backup instances end of the day's binlog file name and location pos point) from the beginning of the implementation of relay log file to restore data to slave 3308 instance
that is in recovery data full backup to after 3308, the next step is the use of camouflage good relay log file (that is, binlog filename and position pos point on the 3306 instance full backup day's end) + sql_thread thread begins execution relay log file to restore data to a slave examples of 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

Third, the way this recovery summary

Pros:
can recover breakpoints, human control progress, such as stop slave or when an error is encountered, a breakpoint can be restored.
Good performance in a large number binlog case, it can speed up the recovery.
In some versions can take advantage of multi-threading to speed up incremental replication rate, recovery faster.
Cons:
needs to close mysqld.
Perform a manual process is more complicated than mysqlbinlog way.

Fourth, to resolve doubts as follows:

Overall, whether binlog Q1 and relay-log structure is the same? ? ?
A: The whole is consistent with the binlog and relay-log structure
Q2 binlog filename and the relay-log filename is not a relationship?
Answer: not necessarily related to the
Q3 to Binlog manually changed Relay-log is not feasible?
A: It is possible
Q4 Relay-log record information related to what?

Fifth, take advantage of the incremental process SQL_thread fast recovery Summary:

1. You can not use = 1 master_auto_position
2. must first let mysql knew he was a Slave
3. Turn off mysql, log-constructed Relay
4. Master to use RELAY_LOG_FILE = ... Change,
RELAY_LOG_POS = ...;
5.START SLAVE SQL_THREAD UNTIL MASTER_LOG_FILE = 'xxx', MASTER_LOG_POS = xxxxx
or START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 'xxxxx -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

Reference Bowen address:
The following recovery methods reference documentation:
http://blog.itpub.net/29773961/viewspace-2143726/