MySQL-binlog格式对主从复制的影响&MySQL主从复制的过程

---

官方文档

https://dev.mysql.com/doc/

如果英文不好的话，可以参考 searchdoc 翻译的中文版本

http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html

---

主从复制的分类

根据主节点配置的binlog的格式，可以分为

• 基于SQL语句的复制（statement-based replication，SBR），

  这种情况是主节点的binlog格式为 STATEMENT

• 基于行的复制（row-based replication，RBR)，

  这种情况是主节点的binlog格式为ROW

• 混合模式复制（mixed-based replication,MBR)。

  这种情况是主节点的binlog格式为MIXED

我们来看下，这三种格式对 主从复制的影响

---

基于SQL语句的复制-SBR

MySQL5.1.4 之前只有这种模式。 又称之为逻辑复制 。

主库记录SQL修改语句，从库回放这些SQL 。

---

优点

• 基于段的模式，binlog相对较小，因此生成的日志量少，节省网络传输I/O
• 并不要求主从数据库的表的定义完全相同。举个例子，比如主从上有个表的类型不同，但是是兼容的，碰巧这个表也是个大表 ，这样的话修改大表，可以先在从库修改，再切过去。
• 相比基于行的复制方式更为灵活

缺点

• 基于段的模式，对于非确定性的时间，无法保证主从复制的一致性， 比如UUID， now等函数（因为是执行SQL，那uuid这种函数相同的可能性基本为0），造成主从复制链路的中断
• 对于存储过程，触发器，自定义函数修改也可能造成数据不一致
• 相比基于行的复制方式在从节点上执行需要更多的行锁 。 当执行一条批量的SQL，在主库上锁定了一批数据，那么在从节点上也要锁定相同的一批数据。

---

基于行的复制 RBR

主库的二进制日志格式为ROW。

优点

• 因为binlog的格式row，所以可以应用于任何SQL的复制，包括非确定函数，存储过程、自定义函数等。因为它同步过去的是值，举个例子，UUID，从库执行的时候不是重新执行UUID，而是把主库的这个已经生成的值直接同步到从节点上。
• 可以减少数据库锁的使用

---

缺点

• 要求主从数据库的表结构必须要相同，对于相同的列，即使顺序不同，有可能会引起主从中断
• 无法在从节点单独执行触发器，有的时候你只想在从库上执行一些操作，是不行的。 但基于SQL语句的没问题，执行那些变更的SQL就行了，但是基于行的就不行了。

---

MySQL主从复制的过程

1.主节点将变更写入binlog , 因此主节点必须开启binlog .

2. 从节点读取主节点的binlog,并保存到从服务本地的relay log 中继日志

要完成保存到中继日志中，从服务器启动一个I/O 线程，连接到主库，主库上启动 bin log dump线程，从节点读取。

3. 启动SQL Log线程，在从节点上重返relay_log中的日志

基于SQL段的日志是在从库上重新执行记录的SQL

基于Row的日志这是在从库上直接应用对数据库行的修改