binlog之四：mysql中binlog_format模式與配置詳解，binlog的日誌格式詳解

mysql複製主要有三種方式：基於SQL語句的複製(statement-based replication, SBR)，基於行的複製(row-based replication, RBR)，混合模式複製(mixed-based replication, MBR)。對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

 

① STATEMENT模式（SBR）

每一條會修改數據的sql語句會記錄到binlog中。優勢是並不須要記錄每一條sql語句和每一行的數據變化，減小了binlog日誌量，節約IO，提升性能。缺點是在某些狀況下會致使master-slave中的數據不一致(如sleep()函數， last_insert_id()，以及user-defined functions(udf)等會出現問題)

② ROW模式（RBR）

不記錄每條sql語句的上下文信息，僅需記錄哪條數據被修改了，修改爲什麼樣了。並且不會出現某些特定狀況下的存儲過程、或function、或trigger的調用和觸發沒法被正確複製的問題。缺點是會產生大量的日誌，尤爲是alter table的時候會讓日誌暴漲。

③ MIXED模式（MBR）

以上兩種模式的混合使用，通常的複製使用STATEMENT模式保存binlog，對於STATEMENT模式沒法複製的操做使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇日誌保存方式。
 
binlog複製配置

在mysql的配置文件my.cnf中，能夠經過一下選項配置binglog相關

binlog_format           = MIXED                         //binlog日誌格式，mysql默認採用statement，建議使用mixed
log-bin                 = /data/mysql/mysql-bin.log    //binlog日誌文件
expire_logs_days        = 7                           //binlog過時清理時間
max_binlog_size         = 100m                       //binlog每一個日誌文件大小
binlog_cache_size       = 4m                        //binlog緩存大小
max_binlog_cache_size   = 512m                     //最大binlog緩存大小

對於執行的SQL語句中包含now()這樣的時間函數，會在日誌中產生對應的unix_timestamp()*1000的時間字符串，slave在完成同步時，取用的是sqlEvent發生的時間來保證數據的準確性。另外對於一些功能性函數slave能完成相應的數據同步，而對於上面指定的一些相似於UDF函數，致使Slave沒法知曉的狀況，則會採用ROW格式存儲這些Binlog，以保證產生的Binlog能夠供Slave完成數據同步。三 MIXED說明

如今來比較如下 SBR 和 RBR 2中模式各自的優缺點：

SBR 的優勢：

歷史悠久，技術成熟
binlog文件較小
binlog中包含了全部數據庫更改信息，能夠據此來審覈數據庫的安全等狀況
binlog能夠用於實時的還原，而不只僅用於複製
主從版本能夠不同，從服務器版本能夠比主服務器版本高

SBR 的缺點：

不是全部的UPDATE語句都能被複制，尤爲是包含不肯定操做的時候。
調用具備不肯定因素的 UDF 時複製也可能出問題
使用如下函數的語句也沒法被複制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啓動時啓用了 --sysdate-is-now 選項)
INSERT ... SELECT 會產生比 RBR 更多的行級鎖
複製須要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，須要比 RBR 請求更多的行級鎖
對於有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其餘 INSERT 語句
對於一些複雜的語句，在從服務器上的耗資源狀況會更嚴重，而 RBR 模式下，只會對那個發生變化的記錄產生影響
存儲函數(不是存儲過程)在被調用的同時也會執行一次 NOW() 函數，這個能夠說是壞事也多是好事
肯定了的 UDF 也須要在從服務器上執行
數據表必須幾乎和主服務器保持一致才行，不然可能會致使複製出錯
執行復雜語句若是出錯的話，會消耗更多資源

RBR 的優勢：

任何狀況均可以被複制，這對複製來講是最安全可靠的
和其餘大多數數據庫系統的複製技術同樣
多數狀況下，從服務器上的表若是有主鍵的話，複製就會快了不少
複製如下幾種語句時的行鎖更少：
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者並無修改不少記錄的 UPDATE 或 DELETE 語句
執行 INSERT，UPDATE，DELETE 語句時鎖更少
從服務器上採用多線程來執行復製成爲可能

RBR 的缺點：

binlog 大了不少
複雜的回滾時 binlog 中會包含大量的數據
主服務器上執行 UPDATE 語句時，全部發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會致使頻繁發生 binlog 的併發寫問題
UDF 產生的大 BLOB 值會致使複製變慢
沒法從 binlog 中看到都複製了寫什麼語句
當在非事務表上執行一段堆積的SQL語句時，最好採用 SBR 模式，不然很容易致使主從服務器的數據不一致狀況發生

另外，針對系統庫 mysql 裏面的表發生變化時的處理規則以下：
若是是採用 INSERT，UPDATE，DELETE 直接操做表的狀況，則日誌格式根據 binlog_format 的設定而記錄
若是是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來作的話，那麼不管如何都採用 SBR 模式記錄
注：採用 RBR 模式後，能解決不少原先出現的主鍵重複問題。

 

2、使用mysqlbinlog解析binlog後的日誌格式

MIXED（STATEMENT）：

# at 193（開始位置）

#110708 10:03:06（時間截） server id（產生該事件的服務id） 1  end_log_pos（日誌的結束位置） 280  Query（事件類型）  thread_id=10    exec_time=0     error_code=0

SETTIMESTAMP=1310090586/*!*/;

insert into tvalues(17)

/*!*/;

 

ROW模式：

BEGIN

/*!*/;

# at 174

# at 214

#110708 10:49:22server id 1  end_log_pos 214   Table_map: `test`.`t` mapped to number 14

#110708 10:49:22server id 1  end_log_pos 248   Write_rows: table id 14 flags: STMT_END_F

 

BINLOG '

MnAWThMBAAAAKAAAANYAAAAAAA4AAAAAAAEABHRlc3QAAXQAAQMAAQ==

MnAWThcBAAAAIgAAAPgAAAAAAA4AAAAAAAEAAf/+MgAAAA==

'/*!*/;

# at 248

#110708 10:49:22server id 1  end_log_pos 317   Query  thread_id=1     exec_time=0     error_code=0

SETTIMESTAMP=1310093362/*!*/;

COMMIT

 

3、binlog導出的日誌文件內容格式詳解

每一個binlog的開始都是由4個字節：fe 62 69 6e，組成的魔數（後面三個字節就是bin）。

而後接下來的就是一條記錄的內容它包括：Common-Header，這部分不一樣版本的大小不同，4.0以上的都是19個字節。在這個以後就是BODY。

Common-Header格式：（單位：字節）

Timestamp(4)

Type(1)

Server_id(4)

Total_size(4)

End_log_pos(4)

Flag(2)

Timestamp:從1970開始

Type:此log event type如FORMAT_DESCRIPTION_EVENT、QUERY、LOAD_EVENT等，其中每一個binlog的第一條記錄的類型都是FORMAT_DESCRIPTION_EVENT，它記錄了該binlog的相關信息，如版本，這些信息對於後序分析binlog記錄是有用的，因此對於任務要讀取binlog的內容的工具都必須先讀取第一條記錄。QUERY包括咱們常常操做的如：create,drop,update,insert等。

Server_id：建立這個事件的server id。防止循環主從致使的主機被從寫。The master's server id (is preserved in therelay log; used to prevent from infinite loops in circular replication).

Total_size：該記錄的大小，包括common_header及body。

End_log_pos：此下一條記錄的開始位置。也是此條記錄結束位置的上一個字節。

Flag：標誌位。

 

QUERY類型的記錄：

QUERY類型的記錄除了開始的common-header以外，在body的開頭是一個Post-header，而後以後纔是真正的body內容。

Query Post-Header：（單位字節）

Thread_id(4)

Exec_time(4)

Db_len(1)

Error_code(2)

Status_var_len(2)

Thread_id：is used to distinguish temporary tables that belong to differentclients.

Exec_time：The time from whenthe query started to when it was logged in the binlog, in seconds.QUERY到達到這個binlog事件生成的時間間隔。

Db_len：當前數據庫的名稱長度。

Error_code：執行出錯的錯誤號。