Mysql 數據庫日誌 模式分類以及mysql中binlog_format模式與配置詳解

mysql中binlog_format模式與配置詳解

www.111cn.net 更新:2014-12-02 編輯:kp878 來源:本站整理

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緩存大小

三 MIXED說明

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

如今來比較如下 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 模式後，能解決不少原先出現的主鍵重複問題。