MySQL ROW复制的特点

MySQL基于行的复制可以最大化保证主从复制的一致性，对于RBR（基于行复制） 和SBR（基于语句复制），相信大家已经很熟知，下面记录的是行复制在二进制日志总记录的情况。

基于行的复制是与位置相关的，binlog里面只记录相关表发生改变的列的数据。其中引入了四个新的事件： Table_map, Write_rows，Delete_rows,Update_rows.

一条语句执行后，在binlog里面，Table_map事件中包含表ID，和列的类型（没有列名,slave 可以利用这些信息对比和master上的表结构是否一致），后面跟着其他三个事件，结束标志为STMT_END_F.

事件在slave 端执行过程：

1、SQL线程从中继日中读取各个事件。

2、对与Table_map事件，SQL线程将提取出表信息，保存表的定义。

3、锁定要改变的表，并检查master和slave上表结构是否一致。

4、如果表schema不一致，则停止复制，否则继续执行行事件，直至遇到结束标志符：STMT_END_F.

对于Update_rows和Delete_rows事件，SQL线程要先定位到具体的行，查找操作的步骤：

1、主键或者

优先选择slave上的主键。这是最好的办法。当找到匹配的主键值的时候，就认为已经找到匹配的行，行的其他列的内容则不去匹配。

2、非空唯一索引扫描

这个也只比较键值

3、其他索引或者全表扫描

此时会比较整个行的数据在master和slave上是否一致（确实能保证主从复制的一致性，但也是最慢的）

MySQL在5.1版本以后，提供了基于ROW 模式的复制模式，从而大大提高了数据复制的可靠性；但这种模式在以下场景下会让备库的数据延时很大；

1) 存在没有主键的表，导致备库应用每个Event 都需要全表扫描 ;
2) 主库执行了大表DDL 或大事务，导致备库也要相同时间执行完 ;

ROW模式数据复制

ROW 模式之所以能保证复制可靠性，是其在BINLOG里记录每一行完整记录，包括所有列的值；在备库应用日志时，MySQL 会先尝试用行里的主键去匹配自身的记录，如果没有主键， 则进行全表扫描所有的行，每一行都与日志进行匹配，直到发现完全匹配的行；

图2- ROW模式日志匹配处理流程

在保证主备数据复制可靠性的前提下，减小主备延时，尽量为每个表建立一个主键或唯一索引。