17.1.2.2 Usage of Row-Based Logging and Replication 基于行复制的使用
MySQL 使用基于语句的记录(SBL),基于记录的记录(RBL) 或则混合记录。
这种类型的binary log 影响日志的大小和效率。因此选择在基于行复制或者基于语句的复制依赖你的应用
和环境。本章节描述基于行的日志,并讨论了在复制中使用它的一些最佳做法。
有关更多的信息,请参见Section 17.1.2, “Replication Formats”, and Section 17.1.2.1, “Advantages and
Disadvantages of Statement-Based and Row-Based Replication”.
基于行记录的临时表, 在Section 17.4.1.23指出,复制和临时表,
临时表不会被复制当使用基于行的格式。 当使用混合格式记录时, “safe” 语句使用临时表
被记录 使用基于语句的格式。更多的信息,请参见第17.1.2.1，”优势和基础，基于行的复制”语句的缺点。
临时表不会被复制当使用基于行格式的复制,因为没有必要.此外,
因为临时表是只读的 ,所以很少有负载它们,即使使用基于语句的格式。
在MySQL 5.6，你可以切换从基于语句的到基于行记录模式的切换, 即使当临时表被创建。
然而,当使用基于行的格式,MySQL server 不能确定记录模式 是否有效,当一个给定的临时表被创建。
由于这个原因,server 在这种情况下记录一个DROP TEMPORARY TABLE IF EXISTS 语句对于每个临时表
在MySQL 5.6.6 和早期版本, –disable-gtid-unsafe-statements 选项导致任何非事务的DML语句涉及临时表
抛出一个错误当使用基于行的记录,事实上,它们是不会写入binary log.在MySQL 5.6.7 以后,
这样的语句允许当binlog_format=ROW，对于任何被影响的非事务表。
RBL和同步非事务表, 当很多的记录受到影响,改变的组被分成几个events, 当语句提交时,
所有这些evnets被写入到binary log. 当在slave上执行时,一个table lock 是在所有的表上涉及,
然后行记录被应用于批处理模式中。(这个可能或者不能生效,依赖用于slave拷贝的表的引擎)
延迟和binary log size，RBL 写改变对于每个行到binary log，因此它的大小可以增加的很怪。
这个会显著的增加slave上匹配master 更改需要的时间。 你应该意识到 潜在的延迟。
读取binary log，mysqlbinlog 显示基于行的events 在binary log 使用BINLOG语句。
这个语句显示了 一个基于64编码的字符窜作为events，其含义是不明显的。
当调用 –base64-output=DECODE-ROWS and –verbose 选项, mysqlbinlog 格式binary log的内容对人类可读。
当binary log events 被写基于行的格式,你从复制或者数据库failure 需要读取或者恢复。
Binary log 执行错误和 slave_exec_mode.如果 slave_exec_mode 是幂等的，从RBL应用改变失败
因为原始的记录不能被找到 不触发一个错误或者导致复制失败 这意味着 它是可能的 更新没有被应用到slave，
因此master 和slave 不再是同步的。
注意:
slave_exec_mode=IDEMPOTENT 通常只用于某种循环复制或者多个master的复制在MySQL Cluster里
缺乏binary log 的checksums,RBL 不使用checksums，因此网络,磁盘,和其他错误不可能确定
当处理binary log时。 为了确保数据是传输的 在没有网络腐败使用SSL用于复制连接。
不支持基于server ID的过滤,在MySQL 5.6，你可以基于server id过滤 通过使用IGNORE_SERVER_IDS
选项来 CHANGE MASTER TO statement.这个选项和基于语句和基于行格式一起工作。
另外的方式是过滤出的变化在一些slave上来使用where 子句 包括@@server_id <> id_value关系的子句