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:session
In statement format: the SQL query is written to the binlog in text.app
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:ide
Write_rows_log_event: adds a new row to a table. Has only AI.this
Update_rows_log_event: modifies an existing row in a table. Has both BI and AI.spa
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:orm
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.
本款狀態:已完成,但沒有審查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格式記錄。