Mysql 内部结构 / Replication | Binlog格式

摘要: 本文为翻译mysql官方文档 的 MySQL Internals Manual

19.3.1 Binlog Formats

Status of this subsection: Complete but not reviewed 2009-10-21

The binlog is organized as a linear sequence of events. An SQL query that modifies the database will generate one or more events and append them to the binlog. There are also auxiliary event types that describe the structure of the binlog.

Queries can be logged in two ways:

In statement format: the SQL query is written to the binlog in text.

In row format: rows that changed are written to the binlog in a binary format. Each row may consist of a Before Image (BI) and/or an After Image (AI). The BI identifies the row to modify and the AI describes the row after the change. There are three types of log_events:

Write_rows_log_event: adds a new row to a table. Has only AI.

Update_rows_log_event: modifies an existing row in a table. Has both BI and AI.

Delete_rows_log_event: removes an existing row from a table. Has only BI.

Which of the two formats to use is configured with the @@session.binlog_format variable, which takes the values STATEMENT, ROW, or MIXED. The following principles shall hold:

(P-binlog_format-statement) @@session.binlog_format=STATEMENT:

We do not guarantee correct logging.

The client may not generate row events.

If the server cannot determine that a statement is correctly logged, a warning or error shall be issued:

If it is possible that the user (through application-specific logic) knows that the statement is correctly logged, then a warning shall be issued.

If it is inherently impossible for the user to determine that the statement will be correctly logged, an error shall be issued and the statement shall not execute.

(P-binlog_format-row) @@session.binlog_format=ROW:

We guarantee correct logging. If a statement cannot be correctly logged, then an error shall be generated and the statement shall not execute.

DML changes may only be logged in row format, not in statement format. If a DML change cannot be logged in row format, then an error shall be generated and the statement shall not execute.

(P-binlog_format-mixed) @@session.binlog_format=MIXED:

We guarantee correct logging. If a statement cannot be correctly logged, then an error shall be generated and the statement shall not execute.

If correct logging can be guaranteed by logging in statement format, then statement format shall be used. Otherwise, row format shall be used.

Clarification: If it cannot be determined in a practical manner that statement format leads to correct logging, then row format shall be used.

19.3.1二进制日志格式

本款状态：已完成，但没有审查2009-10-21

二进制日志是按线性序列后的event（这里不应该翻译，特有名词） 集组织成的。修改数据库内容的SQL查询将生成一个或多个events，并将其追加到binlog。也有描述binlog日志结构的辅助event类型。

查询可以以两种方式被记录：

statement 格式：SQL查询被按文本格式写入binlog。

row 格式：每行数据的更改都用二进制写入binlog。每行包含一个的 前镜像（BI）和/或 后镜像（AI，这里的镜像指的是格式化后的原数据） 。在BI标识行修改内容和AI描述了改变后的行内容。有三种类型的log_events的：

Write_rows_log_event：添加一个新行到表。只有AI。

Update_rows_log_event：修改表中的现有行。既有BI和AI。

Delete_rows_log_event：从表中删除现有行。只有BI。

这两种格式使用@@session.binlog_format变量进行配置，该变量取值为STATEMENT，ROW或MIXED。以下原则将持有：

（P-binlog_format-statement） @@session.binlog_format=STATEMENT：

不保证正确记录。

该客户端可能无法产生连续的event集。

如果服务器无法判定一个语句被正确的方式记录，会报出警告或错误：

如果是用户（通过应用特定逻辑）知道该语句被正确记录，则予以警告。

如果是本来就不可能为用户确定该语句将被正确的方式记录，应发出错误并且该语句将不会执行。

（P-binlog_format-row） @@session.binlog_format=ROW：

保证正确的记录。如果语句不能正确记录，然后将产生一个错误并且该语句将不会执行。

DML的变化只在row 格式记录，而不是在statement 格式。如果一个DML变化无法行格式被记录下来，然后将产生一个错误并且该语句将不会执行。

（P-binlog_format-mixed） @@session.binlog_format=MIXED：

保证正确的记录。如果语句不能正确记录，然后将产生一个错误并且该语句将不会执行。

如果正确的记录可以通过statement 格式记录得到保证正确记录，那么会使用statement 格式。否则，则使用row 格式。

说明：如果不能用statement 格式中的一种可实现的方式来确定该记录被正确记录，则应该用row格式记录。