主从节点分配：
| 192.168.1.100 | master | binlog server读取节点 |
| 192.168.1.101 | slave | 备份节点 |
备注：binlog server从master节点备份binlog，xtrabackup从slave节点进行备份
备份过程忽略，备份后的目录结构如图：
backup-my.cnf ibdata1 monitor mysql panda_chongzhi performance_schema test xtrabackup_binlog_info xtrabackup_checkpoints xtrabackup_info xtrabackup_logfile
[root@appdb2v 20160530]# cat xtrabackup_binlog_info
mysql_bin.000014 455786786 a9f7c88d-0886-11e6-8a74-00163e0800ff:1-4,
d7fd53cd-0882-11e6-8a5b-00163e080703:1-23209940,
fbfda47c-d310-11e5-adda-00163e0e0823:1-45225558
从xtrabackup_binlog_info信息可以看到，备份时binlog为mysql_bin.000014，end_position是455786786，gtid事务点是d7fd53cd-0882-11e6-8a5b-00163e080703:1-23209940（备注：这个从节点是从级联节点复制过来的，所以事务id出现三个，其中uuid:d7fd53cd-0882-11e6-8a5b-00163e080703是这个从节点的master节点），在这种情况下，我们如何根据从节点上的备份和基于主节点的binlog server进行数据恢复呢？
思考：主从架构中，启动gtid模式，执行同一个事务，主从binlog中的pos点是不一定一致的，但是gtid肯定是一致的，那么我们可以基于gtid，在binlog server备份的binlog中，找到相应的pos点，然后指定--start-position
[root@appdb1v gaoquan]# mysqlbinlog -v --base64-output=DECODE-ROWS ./mysql_bin.000014|grep 23209941 -B10 -A 10
COMMIT/*!*/;
# at 232099219
#160527 0:25:27 server id 1083306 end_log_pos 232099267 CRC32 0xbf94f603 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= 'd7fd53cd-0882-11e6-8a5b-00163e080703:21348001'/*!*/;
# at 232099267
#160527 0:25:27 server id 1083306 end_log_pos 232099349 CRC32 0x911407dd Query thread_id=32313906 exec_time=0 error_code=0
SET TIMESTAMP=1464279927/*!*/;
BEGIN
/*!*/;
# at 232099349
#160527 0:25:27 server id 1083306 end_log_pos 232099415 CRC32 0xc56e7558 Table_map: ` mapped to number 113
# at 232099415
#160527 0:25:27 server id 1083306 end_log_pos 232099553 CRC32 0x753d029b Update_rows: table id 113 flags: STMT_END_F
# at 928426311
#160530 3:01:30 server id 1083306 end_log_pos 928426342 CRC32 0x2577d87f Xid = 337741726
COMMIT/*!*/;
# at 928426342
#160530 3:01:30 server id 1083306 end_log_pos 928426390 CRC32 0x8fe4f7c6 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= 'd7fd53cd-0882-11e6-8a5b-00163e080703:23209941'/*!*/;
# at 928426390
#160530 3:01:30 server id 1083306 end_log_pos 928426472 CRC32 0x0cc3a3ba Query thread_id=34214200 exec_time=0 error_code=0
SET TIMESTAMP=1464548490/*!*/;
BEGIN
/*!*/;
# at 928426472
#160530 3:01:30 server id 1083306 end_log_pos 928426538 CRC32 0x1e03877f Table_map: ` mapped to number 81
# at 928426538
#160530 3:01:30 server id 1083306 end_log_pos 928426676 CRC32 0x18a58faa Update_rows: table id 81 flags: STMT_END_F
由上面获取到的信息可知binlog中d7fd53cd-0882-11e6-8a5b-00163e080703:23209941对应的pos点位置是928426342，那么我们可以基于这个pos点进行数据库恢复
[root@appdb1v gaoquan]# mysqlbinlog --start-position=928426342 ./mysql_bin.000014|mysql -S /backup/data/mysql/3306/tmp/mysql.sock -uroot -p