环境：主库双1模式
一。单SQL线程
1.pos模式
1.1 position mode 模式（最安全）
master_info_repository table
relay_log_info_repository table
recovery_relay_log off
sync_master_info 1
sync_relay_log 1
sync_relay_log_info 默认1000
这个情况recovery_relay_log设置为off，异常重启后IO会从宕机前的位置继续拉取主库的binary log event,比如宕机的时候IO线程可能正在拉取某个事物的某个event，重启之后就需要拉取余下的event 写入到relay log，因此relay log 文件的完整性和slave_master_info表的信息的正确就非常重要。异常重启后SQL线程会从宕机前继续读取relay log进行应用，也需要保证relay log文件的完整性。那么sync_master_info和sync_relay_log都必须设置为1，虽然很安全，但是性能很差
1.2安全配置，性能较为优异
master_info_repository table
relay_log_info_repository table
recovery_relay_log on
sync_master_info 默认10000
sync_relay_log 默认10000
sync_relay_log_info 默认10000
2.GTID AUTO_POSITION MODE模式
2.1 最安全配置，性能不佳
master_info_repository table
relay_log_info_repository table
recovery_relay_log off
sync_master_info 10000
sync_relay_log 1
sync_relay_log_info 默认1000
这种情况下recover_relay_log设置为off，虽然主库IO线程使用Retrieved_gtid_set和execute_gtid_set的并集进行确认binary log的拉取
但是异常重启后SQL线程会从宕机前的位置继续读取relay log进行应用，因此需要保证relay log 文件的完整，其次实例初始的时候通过relay log初始化Retrieved_gtid_set。因此这个情况下sync_relay_log必须设置为1
2.2 较为安全，性能优异
master_info_repository table
relay_log_info_repository table
recovery_relay_log on
sync_master_info 10000
sync_relay_log 10000
sync_relay_log_info 默认1000
二。MTS模式
sync_binlog 参数
表示多少次事务提交后，MySQL调用文件系统 将 数据库的binlog 刷到磁盘上去。
默认值：0
sync_binlog=0
表示MySQL不控制binlog 刷到磁盘上去，由文件系统自己控制 刷到磁盘上去。
这时候的性能是最好的，但是风险也是最大的。一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
sync_binlog=1
最安全的方式，即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。
性能损耗最大
表示每次事务提交，MySQL都会把binlog刷到磁盘。
对于高并发事务的系统来说，"sync_binlog"设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。所以很多MySQL DBA设置的sync_binlog并不是最安全的1，而是2或者是0。这样牺牲一定的一致性，可以获得更高的并发和性能。
innodb_flush_log_at_trx_commit 参数
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。
