MySQL replication format big analysis

Preface

The following content is based on MySQL5.7 official documents

Copy format

Replication is effective because events written to the binary log are read from the source and then processed on the replica. According to the type of event, the event is recorded in the binary log in different formats. The replication format used corresponds to the binary logging format used when the event is recorded in the source's binary log. There are three binary logging formats:

1. When using statement-based binary logging, the source writes SQL statements to the binary log. Copying the source to the copy can be done by executing SQL statements on the copy. This is called
   statement-based replication (can be abbreviated as SBR), which corresponds to the binary logging format based on MySQL statements.
2. When using row-based logging, the source writes events to the
   binary log to indicate how to change individual table rows. The source can be copied to the copy by copying the event that represents the changes made to the table row to the copy. This is called row-based replication (can be abbreviated as RBR).
3. You can also configure MySQL to use statement-based records and row-based records at the same time, depending on which record is best for record changes. This is called mixed format logging. When using mixed format logging, statement-based logging is used by default. Depending on certain statements and the storage engine used, the log will automatically switch to a row-based log under certain circumstances. Copying using mixed formats is called mixed-based copying or mixed-format copying.

Before MySQL 5.7.7, the statement-based format was the default format. In MySQL 5.7.7 and later, the row-based format is the default format.

The logging format in the running MySQL server is achieved by setting the binlog_format system variable. This variable can be set using session or global scope. . Setting the variables of the current session only lasts until the end of the session, and other sessions cannot see the change. The global setting variables take effect on the client connected after the change, but it does not apply to any current client session, including the session where the variable setting is changed. To make the global system variable settings permanent, so that they can be applied to the server after restart, it must be set in the configuration file.

Advantages and disadvantages of statement-based replication and row-based replication

Each binary logging format has advantages and disadvantages. For most users, the hybrid replication format should provide the best combination of data integrity and performance. However, if you want to take advantage of features specific to statement-based or row-based copy formats when performing certain tasks, you can use the information in this section (this summary outlines their relative advantages and disadvantages) to achieve the following: OK The copy format that best suits your needs.

Advantages of statement-based replication

1、成熟的技术。

2、写入日志文件的数据更少。当更新或删除影响许多行时，这将导致 日志文件所需的存储空间大大减少。这也意味着可以更快地完成备份的备份和还原。

3、日志文件包含所有进行了任何更改的语句，因此它们可用于审核数据库。

Disadvantages of statement-based replication

1、使用基于语句的复制时，很难复制任何不确定性的行为。例如：DELETE和 UPDATE使用不带LIMIT子句的 语句ORDER BY是不确定的。

2、确定性UDF必须应用于副本。

3、使用基于语句的复制无法正确复制使用以下任何功能的语句：

LOAD_FILE()

UUID()， UUID_SHORT()

USER()

FOUND_ROWS()

SYSDATE()（除非源和副本都使用该--sysdate-is-now 选项启动 ）

GET_LOCK()

IS_FREE_LOCK()

IS_USED_LOCK()

MASTER_POS_WAIT()

RAND()

RELEASE_LOCK()

SLEEP()

VERSION()

但是，所有其他功能都可以使用基于语句的复制正确地复制，包括 NOW()等等。


使用基于语句的复制无法正确复制的语句会记录一条警告，如下所示：

[Warning] Statement is not safe to log in statement format.

4、INSERT ... SELECT的语句复制与基于行的复制相比，需要更多的行级锁。

5、UPDATE WHERE的语句复制与基于行的复制相比，要求进行表扫描的语句（因为在子句中未使用索引 ）必须锁定更多的行。

6、对于InnoDB：使用AUTO_INCREMENT的INSERT语句会 阻塞其他非冲突的INSERT 语句。

7、对于复杂的语句，在更新或插入行之前，必须在副本上评估并执行该语句。对于基于行的复制，副本仅需修改受影响的行，而无需执行完整语句。

8、如果对副本的评估存在错误，尤其是在执行复杂的语句时，基于语句的复制可能会随着时间的流逝缓慢地增加受影响行上的错误余量。请参见 第16.4.1.27节“复制过程中的复制错误”。

9、存储的函数以与NOW()调用语句相同的值执行 。但是，存储过程不是这样。

10、确定性UDF必须应用于副本。

11、表定义在源和副本上必须（几乎）相同。

Advantages of row-based replication

1、所有更改都可以复制。这是最安全的复制形式。

2、对于以下类型的语句，源上需要的行锁更少，从而实现更高的并发性:
使用AUTO_INCREMENT的插入语句

UPDATE或DELETE语句，其中的WHERE子句不使用键或不更改大多数已检查的行。

UPDATE或 DELETE带有WHERE不使用键或不更改大部分已检查行的子句的语句 。

3、对于任何INSERT、UPDATE或DELETE语句，副本上所需的行锁更少。

Disadvantages of row-based replication

1、RBRhh会生成更多记录的数据。为了复制DML语句(例如更新或删除语句)，基于语句的复制只将该语句写入二进制日志。相反，基于行的复制将每个更改的行写入二进制日志。如果该语句更改了很多行，基于行的复制可能会向二进制日志写入更多的数据;即使对于回滚的语句也是如此。这也意味着，创建和恢复备份可能需要更多的时间。此外，二进制日志被锁定较长时间以写入数据，这可能会导致并发性问题。使用binlog_row_image=minimal可以大大减少这个缺点。

2、生成大型BLOB值使用基于行的复制比使用基于语句的复制花费更长的时间。这是因为记录的是BLOB列值，而不是生成数据的语句。

3、您无法在副本上看到从源接收和执行了哪些语句。但是，您可以看到使用mysqlbinlog更改了哪些数据。

4、对于使用MyISAM 存储引擎的表，将副本INSERT作为基于行的事件应用于二进制日志时，与将副本作为语句应用于语句相比，在副本上需要对语句进行更强的锁定。这是因为在MyISAM使用基于行的复制时，不支持在表上进行并发插入。