使用场景
每次开启binlogserver 指定了mysql-bin.0000XX 后都会从该点从头进行传输一次
创建binlogserver
[root@mysql-zst3 binlogserver]# nohup mysqlbinlog --raw --read-from-remote-server --host=172.0.0.51 --port=3308 --user=repl3307 --password=repl --stop-never mysql-bin.000043 &
[2] 8009
此时sbtest_bk数据数，此时binlog位置，且binlogserver正常
进行truncate table
t1 表现在数据
进行truncate
在truncate table 修改主键 为跳跃性的id，紧接着应该进行flush log
"root@localhost:mysql3308.sock [systest]>truncate table t1;
Query OK, 0 rows affected (0.17 sec)
"root@localhost:mysql3308.sock [systest]>insert into t1(id) values(40000)
模拟继续插入数据
查看此时log-file
可以确认 有tuncate 的log-file 在46上
这次实验目的是学会使用全备+binlogserver 进行恢复数据
这里的全备使用的是xtrabackup，
恢复综述：
1使用xtrabackup 创建出一个实例（3011）
2在创建一个新实例（3012）存放binlogserver的日志作为3011的伪master
3.创建主从同步日志恢复到truncate前
可能遇到的问题：
1.binlogserver的日志中记录的是原库3308 的gtid，可能会有问题
解决办法是不是用auto_master_positon=1
但是在使用xtrabackup恢复的实例3011的gtid是否和3308一致？
创建3311 伪master
正确操作
在3311上进行操作：
1、reset master
2、关闭3311实例
3、删除3311实例logdir下所有文件
4、将binlog server下的binary log拷贝到logdir，生成mysql-bin.index文件，修改权限
5、启动3311，show master status
结果是
=========================================================================
这里记录一个错误
将binlogserver日志拷贝到3311实例的logs目录下，并修改权限
这里做的顺序是：先启动实例修改root密码，增加复制用户，关闭实例，修改mysql-bin.index .启动实例
修改mysql-bin.index方法
[root@mysql-zst3 logs]# ls /data/mysql/mysql3311/logs/mysql-bin.0000* > mysql-bin.index
此时3311实例的binlog 会发生变化
mysql-bin.00001是最开始生成的，mysql-bin.000048 是由于在第一次启动实例前把日志放到了log目下生成的因此增加复制用户的操作在000048上；mysql-bibn.000049 是修改mysql-bin.index后重启mysql生成的
其他的日志则是mysqlbinlogserver 的日志
注意这里的gtid的serverid（7709xxxx412:1-4)是新生成的和3308的是不一样的，因此在搭建主从的时候可能会影响，且并没有执行传进来的binlog。
这里有个错误：
关于execute_gtid_set这个值。这里我的操作是：初始化库之后修改root密码，添加复制账户。关库，复制binlogserver日志，修改index文件，启动库，因此这里的execute_gtid_set 没有读到日志里的3308的gtid。但是在次执行该操作时就会读出来，即使没有做reset master,但是建议适用reset master后进行重启库
则会读出3308的gtid
关于execute_gtid_set 和binlog_gtid_simple_recovery参数有关，大概作用是重启mysql时读取mysql-bin.index 中文件从头到尾的日志里的所有gtid集合
错误记录结束
=============================================================================
搭建3312 作为3311的slave进行恢复
这个3312实例：使用的是的3308 使用xtrabackup的全备进行恢复的。
这里做了一个特殊的操作，如果有需要的可以参考，不需要可不许操作:这里只恢复systest库因此我吧其他库都删除了
除了系统库只剩了systest库
此时观察xtrbackup_binlog_pos_innodb 内的日志位置和xtrabackup_info 是不同的
不过可以进行解析mysql-bin.000046 这里有没有操作（xtrabackup_info记录的是日志里的，因此会比xtabackup_binlog_pos_innodb(记录redo里的）可能会高一些。如果有操作需要手动进行恢复了如手动执行sql，或者日志导入，一般是ddl语句，ddl语句不记录到redo中。或者压根就没操作~~）
启动3312实例
systest库存在
此时3312的状态
搭建主从
1.使用MASTER_AUTO_POSITION=1
"root@localhost:mysql3312.sock [systest]>change master to
-> master_host='172.0.0.52',
-> master_port=3311,
-> master_user='repl',
-> master_password='repl',
-> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.11 sec)
指定停止点
"root@localhost:mysql3312.sock [systest]>start slave sql_thread until sql_before_gtids='e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:133'; 注意该value为一个值不是范围
Query OK, 0 rows affected (0.02 sec)
开启io_thread
start slave io_thread
2使用master_auto_positon=0搭建主从
确认logfile，logpos起始点
检查xtrabackup_binlog_info上的位置mysql-bin.000046 234 83bc1292-48fe-11e8-b4e2-000c29f1c412:1, 是没有操作的不需要从这开始）
因此确定logfie=mysql-bin.000045
logpos=
change master to
master_host='172.0.0.52',
master_port=3311,
master_user='repl',
master_password='repl',
master_log_file='mysql-bin.000045',
master_log_pos=5729109,
master_auto_position=0
注意点：
在开启主从也需要停止在truncate table 的事物位置前。
找到truncate table 的位置
mysql-bin.000046上解析，
SET @@SESSION.GTID_NEXT= 'e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:133'/*!*/;为truncate 操作
start slave sql_thread until master_log_file='mysql-bin.000046',master_log_pos=1910151;
在开启io_thread，检查t1表数据，已恢复
此时gtid会发生变化
转自
archer_66的有道云笔记
https://note.youdao.com/share/?id=d5ba0c54eaeea9cba421f9297a786a29&type=note#/
知数堂 - 最靠谱、最有品质的培训品牌
http://zhishutang.com/