在基于binlog文件位置的复制下，要保证crash safe slave，配置下面的参数即可。
relay_log_info_repository = TABLE
relay_log_recovery = ON
这样可行的原因是，relay_log_info_repository = TABLE时，apply event和更新relay_log_info表的操作被包含在同一个事务里，
innodb要么让它们同时生效，要么同时不生效,保证位点信息和已经应用的事务精确匹配。同时relay_log_recovery = ON时，
会抛弃master_log_info中记录的复制位点，根据relay_log_info的执行位置重新从Master获取binlog，
这就回避了由于未同步刷盘导致的binlog文件接受位置和实际不一致以及relay log文件被截断的问题。
在同时使用MTS(multi-threaded slave)时，为保证crash safe slave基于binlog文件位置的复制还需要设置sync_relay_log=1,
因为MySQL在Crash恢复时必须先通过读取relay log补齐MTS导致的事务空洞。
上面的设置并不适用于基于GTID的复制。在基于GTID的复制下，crash的Slave重启后，
从binlog中解析的gtid_executed决定了要apply哪些binlog记录，所以binlog必须和innodb存储引擎的数据保持一致。
要做到这一点，需要把sync_binlog和innodb_flush_log_at_trx_commit都设置为1，即所谓的"双1"。
另外MySQL启动时，会从relay log文件中获取已接收的GTIDs并更新Retrieved_Gtid_Set。由于relay log文件可能不完整，
所以需要抛弃已接收的relay log文件。因此relay_log_recovery = ON也是必须的。
这样，对于基于GTID的复制，保证crash safe slave的设置就是下面这样。
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
relay_log_recovery = ON
如果是MySQL 5.7可以关闭log_slave_updates，这样MySQL会将已执行的GTIDs实时记录到系统表mysql.gtid_executed中，
mysql.gtid_executed是和用户事务一起提交的，因此可以保证和实际的数据一致。
log_slave_updates = OFF
relay_log_recovery = ON
如果是MySQL 5.6可以采用如下变通的方式。
按照基于binlog文件复制时crash safe slave的要求设置relay_log_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON
在Slave crash后，根据relay_log_info_repository设置相应的gitd_purged再开启复制，步骤如下。
1.启动MySQL，但不开启复制
mysqld --skip-slave-start
2.在Slave上修改为基于binlog文件位置的复制
change master to MASTER_AUTO_POSITION = 0
3.启动slave IO线程
start slave io_thread
这里不能启动SQL线程，如果接受到的GTID已经在Slave的gtid_executed里了，会被Slave skip掉。
4.检查binlog传输的开始位置(即Retrieved_Gtid_Set的值)
show slave statusG
假设输出的Retrieved_Gtid_Set值为e10c75be-5c1b-11e6-ab7c-000c296078ae:7-10
5.在Master上检查gtid_executed
show master status
假设输出的Executed_Gtid_Set值为e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10
6.在Slave上设置gitd_purged为binlog传输位置的前面的GTID的集合
reset master;
set global gitd_purged='e10c75be-5c1b-11e6-ab7c-000c296078ae:1-6';
7.修改回auto position的复制
change master to MASTER_AUTO_POSITION = 1
8.启动slave SQL线程
start slave sql_thread
但是，这种变通的方法不适合多线程复制。因为多线程复制可能产生gtid gap和Gap-free low-watermark position，
这会导致Salve上重复apply已经apply过的event。后果就是数据不一致或者复制中断，
除非设置binlog格式为row模式并且slave_exec_mode=IDEMPOTENT,
slave_exec_mode=IDEMPOTENT允许Slave回放binlog时忽略重复键和找不到键的错误，使得binlog回放具有幂等性，
但这也意味着如果真的出现了主备数据不一致也会被它忽略。
到这里，我们可以看出master_info_repository 和relay_log_info_repository默认值被设置为TABLE（默认innodb）,
主要还是从安全的方面考虑，依赖数据库的事务，可以保证relay_log_info_repository存储的点和数据库真正执行的点一致，
这一点FILE方式是无法做到的。同时在性能上，和文件系统的直接交互会增加io，而写table是直接写内存中的buffer pool，
在性能上也能有一定的提升。
首先都设置为TABLE是必要的，对性能有提升作用。
如果开启了gtid，就不需要太care了，因为不会重复执行同一个事务。
如果没有开启gtid，那就应该slave_relay_log_info的存储引擎支持事务，然后开启relay_log_recover即可。
https://mp.weixin.qq.com/s/7ZMj1LdD4MGttsLglcjD4g
https://mp.weixin.qq.com/s/IF1Pld-wGW0q2NiBjMXwfg?
http://www.ywnds.com/?p=12800