MySQL复制安全分析
在MySQL复制中我们经常会遇到，Slave异常down机，当Slave再次启动时，会涉及到一个问题，如何能保证复制的正确性(可能是复制报错或者是数据异常)。
在5.6包括之前版本没有GTID情况下，需要将IO线程和SQL线程的复制信息都记录到表中并且每一个事物都要将位点信息更新，这样效率比较低，可以设置relay_log_recovey为ON，这样IO线程的位点信息就不用每次都更新了，提高了一定的性能，具体内容可以参考: <https://donghy-coredumped.github.io/2018/01/23/MySQL%E4%B8%BB%E4%BB%8E%E6%95%B0%E6%8D%AE%E4%B8%80%E8%87%B4%E6%80%A7/> , 此篇文章我们主要分析在GTID情况下的复制安全性
GTID下的复制安全
在官方文档中可以看到一个关于复制安全的表格:
从这个表格中看到，当GTID设置为ON时，并且是MASTER_AUTO_POSITION时，relay_log_recover和relay_log_info_repository设置为任何值对于复制都是安全的。
这里就有一些疑问了，如果将relay_log_recover设置为OFF，relay_log_info_repository设置为FILE，Slave意外down机重启后，根据文件中的信息去拉取日志，这时文件中的位点信息有可能不是最新的(因为放在文件中，无法用事务保证位点的信息和应用的事务是原子性的)，这样不就会出现问题嘛？
GTID下Slave向Master拉取日志的方式
GTID下，Slave向Master拉取日志，和以前基于位点这种方式并不一样，根据官方文档中手册描述，向Master申请拉取的GTID值是根据UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)算出来的
- global.gtid_executed 这个值可以通过Slave上的binlog获取到
- Retrieved_gtid_set 和last_received_GTID 都是可以从relay log中获取
这样可以看出来GTID模式下，向主库拉取日志的时候需要的值都可以在日志中取到，并不需根据位点信息，所以relay_log_recover和relay_log_info_repository 设置为任何值都是可以的。
详细的内容，可以看下文章最后面的两个链接。
关于还要读取mysql.slave_relay_log_info表的理解
上面我们知道了GTID的拉取方式，但是在实际环境中，我们发现Slave在异常down机重启后，还是会读取mysql.slave_relay_log_info这个表，这里我个人觉得读取这个表中的内容，就是用于定位要从哪个relay log文件和哪个位点开始扫描，去找Retrieved_gtid_set，并不是利用表里的位点去拉取binlog，因为这个位点信息有可能会是不准的(上面图片中红框的地方显示relay_log_info_repository可以设置为Any)。
参考文档
- https://mp.weixin.qq.com/s?__biz=MzU0MTczNzA1OA==&mid=2247484693&idx=1&sn=9f54fb01a92a11f478326834aea919fa&chksm=fb242c18cc53a50ef1810f84872c59dc89e7226fa78b7ff66c54f1bae9a3b6e265679241c817&mpshare=1&scene=1&srcid=0808sXwNnl5Bm5hfnUWvRz06&sharer_sharetime=1565273045106&sharer_shareid=696b16f7bf543a042f0c964a25755e34%23rd
- https://mp.weixin.qq.com/s?__biz=MzU0MTczNzA1OA==&mid=2247484696&idx=1&sn=1341c99926c662135d900c1b42f2c800&chksm=fb242c15cc53a50314894a1ada2facbddf8397d8b07c76b9b9601f8eab4ccee73d25d4082e7f&mpshare=1&scene=1&srcid=0808urpY9zSH24QHn9avvZkS&sharer_sharetime=1565273038980&sharer_shareid=696b16f7bf543a042f0c964a25755e34%23rd