まず、3308の例は、一日フルバックアップの終わりにGTID数のGTID数を実行された設定
ビューのbinlogファイル名xtrabackup日のフルバックアップ終了、ポイントの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'新しいMySQL 3308例の日にフルバックアップを復元するためのツールをxtrabackup使用します。
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は、そう3308インスタンスへのフルバックアップデータを復元するために、3308にGTID及び3308のインスタンスが同じではありません開始後の実際xtrabackupフルバックアップGTID番号ので、復元されたフルバックアップの終わりを生成、オープンGTIDあるので後に
スタート3308は、例えばログ電流にマスタクリアGTID 3308をリセットし、その後設定グローバル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スレーブ上の操作の例：
2.1変更コマンドは、スレーブ・インスタンスとしてMySQLそのものを伝えることです。
=「192.168.1.10」をMASTER_HOSTする随便変更マスタ。
全く使用IO_THREADは、などのホスト、パスワード、ユーザー、ように記入して自由ではないので、変更命令によって、スレーブ・インスタンスとしてMySQL自体を指示します。
そしてrelay.infoファイルを生成するステップによって。
CHANGE MASTER TO MASTER_HOST="192.168.1.10";
show slave status\G只要
Auto_Position: 0 就行3308あなたがrelaylogを装っ増分ビンログファイルが必要になり、2.2のインスタンスを閉じました。
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.*迷彩MySQLの権限を与えられた権限に対応し、リレーログファイル
2.3、削除して、リレー・log.indexファイルrelay.infoファイルを変更します。
移除掉 /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.0000062.4は、ファイル名と場所posの位置から開始されたのSQL_THREAD増分relaylog 3308スレーブ・ファイルを伝えます。
[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;このオプションは、3308インスタンススレーブにデータを復元するためにリレーログファイルの実装の最初からどのリレーログファイルと位置posポイント（つまり、日のバイナリログファイルの名前と場所のPOSポイントの3306のフルバックアップインスタンス端である）SQL_THREADを伝えるために使用されて
回復していますデータの完全バックアップに3308の後、次のステップは、迷彩良いリレーログファイルを使用することである（つまり、3306のインスタンスのフルバックアップ一日の終わりに、バイナリログファイル名と位置posのポイントである）+ SQL_THREADスレッドがスレーブにデータを復元するために実行リレーログファイルを開始します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第三に、道この回復の概要
長所：
このような停止スレーブとしてブレークポイント、人間の制御の進行状況を、回復することができ、またはエラーが発生した場合に、ブレークポイントを復元することができます。
多数binlogの場合において良好な性能は、それが回復をスピードアップすることができます。
いくつかのバージョンではより高速な増分複製速度、回復をスピードアップするためにマルチスレッドを利用することができます。
短所：
mysqldを終了する必要があります。
手動プロセスを実行することはmysqlbinlogは方法よりも複雑です。
次のように第四に、疑問を解決します
全体的に、バイナリログのQ1とリレーログ構造が同じであるかどうか？？？
：全体は、バイナリログとリレーログ構造と一致している
Q2のbinlogファイル名とリレーログファイル名は関係ないのですか？
回答：必ずしも関連しない
BINLOGへQ3は、手動でリレーログが不可能な変わったのか？
A：それは可能である
ものに関連したレコード情報をリレーログQ4？
第五に、増分プロセスSQL_THREAD高速リカバリの概要を活用します：
1.あなたは= 1 master_auto_position使用することはできません
最初のmysqlのは、彼が奴隷を知っていたようにしなければなりません2.
ログイン構築リレー、MySQLをオフにします。3.
4. RELAY_LOG_FILEを使用するには、マスター= ...の変更、
; RELAY_LOG_POS = ...
5.START SLAVE SQL_THREAD MASTER_LOG_FILE = 'XXX'まで XXXXX MASTER_LOG_POS =
またはSTART SLAVE SQL_THREAD SQL_BEFORE_GTIDS UNTIL = '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参考ボーエンアドレス：
次の回復方法の参考資料：
http://blog.itpub.net/29773961/viewspace-2143726/