relay-log中继⽇志是连接master和slave的核⼼，我们来深⼊了解⼀下它的结构和使⽤。
relay-log的结构和binlog⾮常相似，只不过他多了⼀个master.info和relay-log.info的⽂件。
master.info记录了上⼀次读取到master同步过来的binlog的位置，以及连接master和启动复制必须的所有信息。
relay-log.info记录了⽂件复制的进度，下⼀个事件从什么位置开始，由sql线程负责更新。
上⼀篇⽂章我们提到了整个复制流程的过程⼤概是这个样⼦：
知道binlog和relay-log的结构之后，我们重新梳理⼀下整个链路的流程，这⾥我们假定master.info和
relay-log.info都是存在的情况：
1. Master收到客户端请求语句，在语句结束之前向⼆进制⽇志写⼊⼀条记录，可能包含多个事件。
2. 此时，⼀个Slave连接到Master，Master的dump线程从binlog读取⽇志并发送到Slave的IO线程。
3. IO线程从master.info读取到上⼀次写⼊的最后的位置。
4. IO线程写⼊⽇志到relay-log中继⽇志，如果超过指定的relay-log⼤⼩，写⼊轮换事件，创建⼀个新
的relay-log。
5. 更新master.info的最后位置
6. SQL线程从relay-log.info读取进上⼀次读取的位置
7. SQL线程读取⽇志事件
8. 在数据库中执⾏sql
9. 更新relay-log.info的最后位置
10. Slave记录⾃⼰的binlog⽇志
但是在这⾥IO和SQL线程有会产⽣重复事件的问题，举⼀个场景：
1. 先记录中继⽇志，然后更新master.info位置
2. 此时服务器崩溃，写⼊master.info失败
3. 服务器恢复，再次同步从master.info获取到的是上⼀次的位置，会导致事件重复执⾏
既然会有这个问题还为什么要这样做呢？假设反过来，先更新master.info再记录中继⽇志，这样带来的问题就是丢失数据了。⽽mysql认为丢失⽐重复更严重，所以要先刷新⽇志，保⼤还是保⼩mysql帮你做了决定。
网友评论