行级日志记录的临时表.  如第19.5.1.31节，“复制和临时表”所提到的，使用行级或混合格式时，临时表不被复制。欲了解更多信息，请见第19.2.1.1节，“语句级和行级复制的优缺”。

临时表在使用行级或混合格式时不被复制，因为没有必要。在临时表只能从创建它们的线程中读取，因此，即使使用语句级格式，也很少有必要从临时表复制数据。

您可以在运行时将语句级日志记录格式更改为行级日志记录格式，即使临时表已经创建。但是，您不能在运行时将行级或混合格式日志记录格式更改为语句级格式，因为在之前的模式下，CREATE TEMPORARY TABLE语句将被忽略。

MySQL 服务器跟踪每个临时表创建时的日志记录模式。当客户端会话结束时，服务器将记录每个临时表的DROP TEMPORARY TABLE IF EXISTS语句。如果使用行级或混合格式日志记录时创建了临时表，该语句将不被记录。

非事务性DML语句涉及临时表时，在使用binlog_format=ROW时允许，只要涉及语句的非事务性表都是临时表。

RBL和非事务性表的同步.  当许多行被影响时，变化将被分割成多个事件；当语句提交时，这些事件将被写入日志记录。在复制时，所有涉及的表上将获取锁，然后将行应用于批处理模式。根据复制的表引擎，这可能或可能不有效。

延迟和二进制日志大小。 RBL 将每行更改写入二进制日志，因此其大小可以快速增加。这可能会增加在匹配源的副本上应用更改所需的时间。您应该注意可能的延迟在应用程序中。

读取二进制日志。 mysqlbinlog 使用 BINLOG 语句将基于行的事件在二进制日志中显示。该语句将事件显示为一个base64编码的字符串，意义不明。使用 --base64-output=DECODE-ROWS 和 --verbose 选项时，mysqlbinlog 将二进制日志的内容格式化为人类可读。要读取或从复制或数据库故障中恢复二进制日志事件，可以使用该命令。更多信息，请见 Section 6.6.9.2, “mysqlbinlog Row Event Display”。

二进制日志执行错误和副本执行模式。 使用 replica_exec_mode=IDEMPOTENT 通常只在 MySQL NDB 集群复制中有用，其中 IDEMPOTENT 是默认值。 (见 Section 25.7.10, “NDB Cluster Replication: Bidirectional and Circular Replication” )。当 replica_exec_mode 是 IDEMPOTENT 时，因为原始行找不到，无法应用更改，系统不会出现错误或导致复制失败。这意味着可能会出现更新不被应用于副本，从而使源和副本不再同步。延迟问题和使用非事务表格与 RBR 时 replica_exec_mode 是 IDEMPOTENT 可能会使源和副本更加分歧。更多关于 replica_exec_mode 的信息，请见 Section 7.1.8, “Server System Variables”。

对于其他场景，设置 replica_exec_mode 到 STRICT 通常足够；这是在除 NDB 之外的存储引擎中的默认值。

不支持基于服务器ID的过滤 。您可以使用IGNORE_SERVER_IDS选项来CHANGE REPLICATION SOURCE TO。该选项适用于语句日志和行日志格式，但不能在gtid_mode=ON时使用。另一种方法是使用UPDATE和DELETE语句的WHERE子句，其中包括关系@@server_id <> id_value，例如：WHERE @@server_id <> 1。然而，这在行日志格式中不起作用。要使用server_id系统变量进行语句过滤，使用语句日志格式。

RBL、非事务表和停止的副本 。在使用行日志格式时，如果副本服务器在更新非事务表时停止，副本数据库可能会达到不一致的状态。因此，建议使用事务存储引擎，如InnoDB，用于使用行日志格式的所有表。使用STOP REPLICA或STOP REPLICA SQL_THREAD在关闭副本MySQL服务器前，帮助预防问题的出现，并且无论使用哪种日志格式或存储引擎都建议使用。