Mysql 内部结构 / Replication | Binlog格式

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格式记录。