官方文档
如果英文不好的话，可以参考 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
扫描二维码关注公众号，回复： 9032498 查看本文章
-
混合模式复制（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的日志这是在从库上直接应用对数据库行的修改
