复制有效，因为写入binlog的事件是从主服务器读取的，然后在从服务器上处理。根据事件的类型，事件以不同的格式记录在binlog中。使用的不同复制格式对应于事件记录在主binlog中时使用的binlog记录格式。binlog记录格式与复制期间使用的术语之间的关联是：
使用statement-based binlog时，主服务器会将SQL语句写入二进制日志。通过在从上执行SQL语句，将主站复制到从站。这称为statement-based 的复制（可以缩写为SBR），它对应于基于MySQL语句的binlog记录格式。
使用row-based日志时，主服务器会将事件写入binlog，以指示各个表行的更改方式。通过将表示表行更改的事件复制到从，将主服务器复制到从服务器。这称为基于行的复制（可以缩写为RBR）。row-based日志是默认方法。
您还可以将MySQL配置为使用statement-based日志和row-based日志的混合，具体取决于哪个最适合要记录的更改。这称为mixed-format 日志。使用mixed-format 日志时，默认情况下使用statement-based的日志。根据某些语句以及正在使用的存储引擎，在特定情况下，日志会自动切换到row-based。使用mixed-format的复制称为 mixed-based 的复制或mixed-format 复制。
NDB Cluster。MySQL NDB Cluster 8.0中的默认二进制日志记录格式为MIXED。您应该注意，NDBCluster复制始终使用row-based的复制，并且NDB存储引擎与statement-based的复制不兼容。
使用mixed-format时，binlog格式部分取决于正在使用的存储引擎和正在执行的语句。
通过设置binlog_format服务器系统变量来控制正在运行的MySQL服务器中的日志记录格式。可以使用会话或全局范围设置此变量。管理新设置何时以及如何生效的规则与其他MySQL服务器系统变量相同。为当前会话设置变量仅持续到该会话结束，并且该更改对其他会话不可见。全局设置变量对更改后连接的客户端生效，但不会对任何当前客户端会话（包括更改变量设置的会话）生效。要使全局系统变量设置为永久性以便在服务器重新启动时应用，必须在选项文件中进行设置。在某些情况下，
您无法在运行时更改二进制日志记录格式，或者这样做会导致复制失败。
更改全局binlog_format值需要足以设置全局系统变量的权限。更改会话binlog_format值需要足以设置受限会话系统变量的权限。
statement-based和row-based的复制格式具有不同的问题和限制。
使用statement-based的复制，您可能会遇到复制存储的例程或触发器的问题。您可以通过使用row-based的复制来避免这些问题。
优缺点
每种二进制日志格式都有优点和缺点。对于大多数用户，混合复制格式应提供数据完整性和性能的最佳组合
statement-based复制的优点
成熟的技术。
写入日志文件的数据较少。当更新或删除影响许多行时，这会导致日志文件所需的存储空间大大减少。这也意味着可以更快地完成从备份中获取和恢复。
日志文件包含进行任何更改的所有语句，因此可用于审计数据库。
statement-based复制的缺点
对SBR不安全的语句。并非所有修改数据的语句（例如INSERT DELETE，UPDATE和REPLACE语句）都可以使用statement-based复制进行复制。使用基于语句的复制时，很难复制任何非确定性行为。详见
INSERT ... SELECT需要比row-based复制更多的行级锁。
需要进行表扫描的UPDATE语句（因为WHERE子句中没有使用索引）必须锁定比row-based复制更多的行。
对于InnoDB：使用AUTO_INCREMENT的INSERT语句会阻止其他非冲突的INSERT语句。
对于复杂语句，必须在更新或插入行之前在从服务器上评估和执行该语句。对于row-based复制，从服务器只需修改受影响的行，而不是执行完整语句。
如果从评估中存在错误，特别是在执行复杂语句时，statement-based复制可能会逐渐增加受影响行的错误范围。
请参见第17.4.1.28节“复制期间的从属错误”。
存储的函数使用与调用语句相同的NOW（）值执行。但是，存储过程并非如此。
必须在从上应用确定性UDF。
表定义在主服务器和从服务器上必须（几乎）相同。
row-based复制的优点
可以复制所有更改。这是最安全的复制形式。
更新mysql数据库中的信息的语句（如GRANT，REVOKE和触发器操作，存储的例程（包括存储过程）和视图）都使用 row-based复制复制到从服务器。
对于诸如CREATE TABLE ... SELECT之类的语句，将从表定义生成CREATE语句并使用statement-based格式进行复制，而行插入使用row-based格式复制。
对于以下类型的语句，主服务器上需要更少的行锁，从而实现更高的并发性：
INSERT ... SELECT
使用AUTO_INCREMENT的INSERT语句
使用WHERE子句的UPDATE或DELETE语句不使用键或不更改大多数检查的行。
对于任何INSERT，UPDATE或DELETE语句，从上都需要更少的行锁。
row-based复制的缺点
RBR可以生成更多必须记录的数据。要复制DML语句（例如UPDATE或DELETE语句），statement-based复制仅将语句写入binlog。相比之下，row-based复制将每个更改的行写入binlog。如果语句更改了许多行，则row-based复制可能会将更多数据写入binlog;即使对于回滚的语句也是如此。这也意味着制作和恢复备份可能需要更多时间。
此外，binlog被锁定较长时间来写入数据，这可能会导致并发问题。使用binlog_row_image = minimal可以大大减少缺点。
生成大型BLOB值的确定性UDF使用row-based复制比使用statement-based复制需要更长的时间来复制。这是因为记录了BLOB列值，而不是生成数据的语句。
您无法在从上看到从主站接收和执行的语句。但是，您可以使用带有选项--base64-output = DECODE-ROWS和--verbose的mysqlbinlog查看更改了哪些数据。
或者，使用binlog_rows_query_log_events变量，如果启用，则在使用-vv选项时将该语句添加到mysqlbinlog输出的Rows_query事件。
对于使用MyISAM存储引擎的表，当将INSERT语句作为row-based事件应用于binlog而不是将它们作为语句应用时，INSERT语句的从服务器需要更强的锁定。这意味着在使用row-based复制时，不支持在MyISAM表上进行并发插入。
