MySQL _主备基本原理

MySQL 主备基本原理

学习检测

1. 主从流程？

学习总结

1. 主库事务提交，写入binlog 日志，从库有IO线程和主库建立长连接，接收二进制文件存到relay log，备库SQL线程负责将relay log 的内容复制到从库中
   
   在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。

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

在状态 1 中，虽然节点 B 没有被直接访问，但是我依然建议你把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：

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

你可能会问，我把备库设置成只读了，还怎么跟主库保持同步更新呢？

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

接下来，我们再看看节点 A 到 B 这条线的内部流程是什么样的。图 2 中画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。

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

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

这里需要说明，后来由于多线程复制方案的引入，sql_thread 演化成为了多个线程，跟我们今天要介绍的原理没有直接关系，暂且不展开。

binlog

学习检测

1. binlog 的三种形式及优缺点？

总结

1. 三种模式
   • statement 记录的是执行语句（原始sql语句），日志量小
   • row 记录的是数据修改前和后的值，日志量大
     • binlog_row_image 为FULL会记录所有的字段，minimal是记录必要的字段
       • 常用作数据的恢复
         • mixed 是statement 和row的结合