目录

• • 备库为什么要设置为只读模式？
  • 备库设置为只读，如何与主库保持同步更新？
  • A到B的内部流程如何？
  • binlog内容是什么？
  • `row`格式对于恢复数据有何好处
  • M-M结构的循环复制问题以及解决方案

备库为什么要设置为只读模式？

有这样几点考虑：

1、有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作

2、防止切换逻辑有bug，比如切换过程中出现双写（ 同时写两个库(A、B ）），造成主备不一致

3、可以用 readonly 状态，来判断节点的角色

备库设置为只读，如何与主库保持同步更新？

readonly的设置对于super权限用户是无效的。用于同步的线程，就拥有super权限。

A到B的内部流程如何？

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

备库B与主库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读取中转日志relay log ，解析日志里的命令，并执行

binlog内容是什么？

在解释内容之前，需要知道binlog的格式。

binlog有三种格式：statement 、row、mixed

statement

binlog_format=statement 时，binlog 里面记录的就是 SQL 语句的原文

statement格式的binlog的缺陷有个缺陷：

主备使用的索引可能是不一致的，最终导致执行删除时删除的数据不一致。

**row **

row 格式的 binlog 里没有了 SQL 语句的原文，而是替换成了两个 event： Table_map和Delete_rows.

1、 Table_map ， 用于说明操作的表是test库的表t

2、Delete_rows ， 用于定义删除的行为

当binlog_format = row，binlog里面记录了真实删除行的主键id，这样binlog传到备库去的时候，肯定不会出现主备删除不同行的问题

mixed

mixed格式用于哪些场景呢？

statement格式可能会导致主备不一致，所以要使用row格式

row格式比较占空间，同时也更要耗费IO资源，影响执行速度

所以采用这种方案，采用mixed格式，MySQL自己会判断这条SQL语句是否可能引起主备不一致，如果可能，使用row格式，否则使用statement格式。

row格式对于恢复数据有何好处

现在，越来越多场景要求使用row格式的binlog，可以从delete、insert、update三种sql语句角度看待这个问题。

使用delete语句，row格式会把被删除的行的整行信息保存。所以删错之后，只需要把binlog记录的delete语句转成insert就能恢复了。

使用insert语句，row格式会记录所有的字段信息。所以插入错误的时候，只需要把binlog记录的insert语句转成delete语句就能恢复了。

使用update语句，binlog会记录修改前整行的数据和修改后的整行数据。所以如果update误执行，只需要把event前后的两行信息对调，再去数据库执行，就能恢复数据了。

M-M结构的循环复制问题以及解决方案

M-S结构

M-M结构

图1是M-S结构，但是现在常用的是M-M结构，M-M结构区别在于：节点A与节点B总是互为主备关系，所以在切换的时候就不用修改主备关系了。

M-M存在循环复制问题：

在节点A更新一个语句，把生成的binlog发给节点B。

节点B执行完更新语句后也会生成binlog。

如果A同时为B的备库，A会把节点B新生成的binlog拿过去执行。节点A和B之间会不断循环执行这个更新语句。

解决方案：

已知MySQL在binlog中记录了命令第一次执行所在实例的server id。

1、规定两个库的server id 必须不同。若相同，则不能设定为主备关系

2、备库接到binlog，生成与原binlog的server id相同的新的binlog

3、每个库在收到从自己的主库发过来的日志后，先判断server id，如果和自己的相同，表示这个日志是自己生成的，丢弃这个日志。

所以使用M-M结构的日志执行流程如下：

1、从节点A更新的事务，binlog里记录的都是A的server id

2、传到节点B执行一次后，节点B生成的binlog的server id 也是A的server id

3、再传给节点A，A判断这个server id与自己的相同，不处理这个日志