启动从库的slave线程，再去从库看看当前的从库状态
可以看到从库又开始同步了，而且Exec_Master_Log_Pos=Read_Master_Log_Pos，还重新生成了一个slave-relay-bin.000011
再去从库看当前的slave log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000010
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000011
可以看到都是些空事务，也就是从库对于那些还没有执行的语句，全部抛弃了。强制将Exec_Master_Log_Pos移到了Read_Master_Log_Pos。
主库
从库
看到了吧，t1表中的20和30这两条记录就丢失了。
2. 将relay_log_recovery设置为on
在从库参数文件中设置参数(relay_log_recovery = 1)并重启从库
查看主库状态
查看从库状态
停掉重库的sql线程
(root@localhost)[hello]> stop slave sql_thread;
主库做点改动，这次选用t2表
从库查看t2表
从库查看状态
从库查看slave log
[root@mysqlb relaybin]# mysqlbinlog -vv slave-relay-bin.000013
可以看到日志已经进入到slave log中了
现在模拟从库意外宕机，等启动后删除从库最新的relay log，跟第一个实验步骤一致
[root@mysqlb relaybin]# reboot
[root@mysqlb relaybin]# rm -f slave-relay-bin.000013
[root@mysqlb relaybin]# service mysql start
查看从库的状态
可以看到Read_Master_Log_Pos已经由重启前的5429退回到了5124，跟Exec_Master_Log_Pos保持一致。
查看从库的relay log