基本原理

主备数据都是使用binlog进行主备同步数据。

备用节点建议设置成只读（readonly）模式，这样做，有以下几个考虑：

  1. 有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作；
  2. 防止切换逻辑有 bug，比如切换过程中出现双写，造成主备不一致；
  3. 可以用 readonly 状态，来判断节点的角色。

备用节点设置成只读，也能执行与主库的同步操作。

因为 readonly 设置对超级 (super) 权限用户是无效的，而用于同步更新的线程，就拥有超级权限。

下面图中画出的就是一个update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。

主库接收到客户端的更新请求后，执行内部事务的更新逻辑，同时写 binlog。

备库B和主库A之间维持一个长连接。主库A内部有个线程专门服务备库B这个长连接。一个事务日志同步的完整过程是这样的：

  1. 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
  2. 在备库B上执行start slave命令，这时候备库会执行两个线程，就是上图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。
  3. 主库A校验完用户名和密码后，就开始按照备库B传过来的位置，从本地读取binlog，发给B。
  4. 备库B拿到binlog后，写到本地文件(relay log) 中转日志。
  5. sql_thread读取中转日志，解析出日志的命令执行。

常见的两种主备切换流程

M-S结构

M-S结构，两个节点，一个当主库、一个当备库，不允许两个节点互换角色。

在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。

当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库。

双M结构

双M结构，两个节点，一个当主库，一个当备库，允许两个节点互换角色。

对比前面的M-S结构图，可以发现，双M结构和M-S结构，其实区别只是多了一条线，即节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。

双M结构的循环复制问题

双 M 结构还有一个问题需要解决。业务逻辑在节点 A 上更新了一条语句，然后再把生成的 binlog 发给节点 B，节点 B 执行完这条更新语句后也会生成 binlog。（我建议你把参数 log_slave_updates 设置为 on，表示备库执行 relay log 后生成 binlog）。

那么，如果节点 A 同时是节点 B 的备库，相当于又把节点 B 新生成的 binlog 拿过来执行了一次，然后节点 A 和 B 间，会不断地循环执行这个更新语句，也就是循环复制了。

我们可以用下面的逻辑，来解决两个节点间的循环复制的问题：

  1. 规定两个库的 server id 必须不同，如果相同，则它们之间不能设定为主备关系；
  2. 一个备库接到 binlog 并在重放的过程中，生成与原 binlog 的 server id 相同的新的binlog；
  3. 每个库在收到从自己的主库发过来的日志后，先判断 server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。

按照这个逻辑，如果我们设置了双 M 结构，日志的执行流就会变成这样：

  1. 从节点 A 更新的事务，binlog 里面记的都是 A 的 server id；
  2. 传到节点 B 执行一次以后，节点 B 生成的 binlog 的 server id 也是 A 的 server id；
  3. 再传回给节点 A，A 判断到这个 server id 与自己的相同，就不会再处理这个日志。所以，死循环在这里就断掉了。