MySQL -- 主备复制

1，主备一致性原理

1.1 主备执行流程图

主库接收到客户端的更新请求后，执行内部事务的更新逻辑，同时写 binlog
备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。

事务日志同步完整过程

备库 B 通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量
备库 B 执行 start slave 命令，备库会启动两个线程 io_thread 、sql_thread ， io_thread 负责与主库建立连接。
主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B
备库 B 拿到 binlog 后，写到本地文件，即中继日志（relay log）。
sql_thread 读取中转日志，解析出日志里的命令，并执行

1.2 主备模式（M-S）

1.3 双主模式（M-M）

双主binlog循环复制 ：双 M 结构和 M-S 结构，多了一条线，节点 A 和 B 互为主备关系。节点A生成binlog日志后同步给节点B实现主备，B实现后又会写binlog告诉A让其完成主备
解决方案

规定两个库的 server id 必须不同，如果相同，则它们之间不能设定为主备关系；
一个备库接到 binlog 并在重放的过程中，生成与原 binlog 的 server id 相同的新的 binlog；
每个库在收到从自己的主库发过来的日志后，先判断 server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。
即
从节点 A 更新的事务，binlog 里面记的都是 A 的 server id；
传到节点 B 执行一次以后，节点 B 生成的 binlog 的 server id 也是 A 的 server id；
再传回给节点 A，A 判断到这个 server id 与自己的相同，就不会再处理这个日志。

2，高可用

2.1 主备延迟

延迟：同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值
正常情况下，主备延迟主要是备库接收完 binlog 和执行完这个事务的时间差，
备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢

2.2 延迟分析

主备库资源不均衡<