mysql復(fù)制主要有三種方式：基于SQL語句的復(fù)制(statement-based replication, SBR)，基于行的復(fù)制(row-based replication, RBR)，混合模式復(fù)制(mixed-based replication, MBR)。對應(yīng)的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

① STATEMENT模式（SBR）

每一條會修改數(shù)據(jù)的sql語句會記錄到binlog中。優(yōu)點(diǎn)是并不需要記錄每一條sql語句和每一行的數(shù)據(jù)變化，減少了binlog日志量，節(jié)約IO，提高性能。缺點(diǎn)是在某些情況下會導(dǎo)致master-slave中的數(shù)據(jù)不一致(如sleep()函數(shù)， last_insert_id()，以及user-defined functions(udf)等會出現(xiàn)問題)

② ROW模式（RBR）

不記錄每條sql語句的上下文信息，僅需記錄哪條數(shù)據(jù)被修改了，修改成什么樣了。而且不會出現(xiàn)某些特定情況下的存儲過程、或function、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題。缺點(diǎn)是會產(chǎn)生大量的日志，尤其是alter table的時(shí)候會讓日志暴漲。

③ MIXED模式（MBR）

以上兩種模式的混合使用，一般的復(fù)制使用STATEMENT模式保存binlog，對于STATEMENT模式無法復(fù)制的操作使用ROW模式保存binlog，MySQL會根據(jù)執(zhí)行的SQL語句選擇日志保存方式。

binlog復(fù)制配置

在mysql的配置文件my.cnf中，可以通過一下選項(xiàng)配置binglog相關(guān)

binlog_format = MIXED ? ?//binlog日志格式，mysql默認(rèn)采用statement，建議使用mixed
log-bin = /data/mysql/mysql-bin.log??? //binlog日志文件
expire_logs_days = 7 ? ? ? ? ? ? ? //binlog過期清理時(shí)間
max_binlog_size = 100m ? ? ? ? ? ? //binlog每個(gè)日志文件大小
binlog_cache_size = 4m ? ? ? ? ? ? //binlog緩存大小
max_binlog_cache_size = 512m ? ? ? ?//最大binlog緩存大小

三 MIXED說明

對于執(zhí)行的SQL語句中包含now()這樣的時(shí)間函數(shù)，會在日志中產(chǎn)生對應(yīng)的unix_timestamp()*1000的時(shí)間字符串，slave在完成同步時(shí)，取用的是sqlEvent發(fā)生的時(shí)間來保證數(shù)據(jù)的準(zhǔn)確性。另外對于一些功能性函數(shù)slave能完成相應(yīng)的數(shù)據(jù)同步，而對于上面指定的一些類似于UDF函數(shù)，導(dǎo)致Slave無法知曉的情況，則會采用ROW格式存儲這些Binlog，以保證產(chǎn)生的Binlog可以供Slave完成數(shù)據(jù)同步。

現(xiàn)在來比較以下 SBR 和 RBR 2中模式各自的優(yōu)缺點(diǎn)：

SBR 的優(yōu)點(diǎn)：

歷史悠久，技術(shù)成熟
binlog文件較小
binlog中包含了所有數(shù)據(jù)庫更改信息，可以據(jù)此來審核數(shù)據(jù)庫的安全等情況
binlog可以用于實(shí)時(shí)的還原，而不僅僅用于復(fù)制
主從版本可以不一樣，從服務(wù)器版本可以比主服務(wù)器版本高

SBR 的缺點(diǎn)：

不是所有的UPDATE語句都能被復(fù)制，尤其是包含不確定操作的時(shí)候。
調(diào)用具有不確定因素的 UDF 時(shí)復(fù)制也可能出問題
使用以下函數(shù)的語句也無法被復(fù)制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動時(shí)啟用了 --sysdate-is-now 選項(xiàng))
INSERT ... SELECT 會產(chǎn)生比 RBR 更多的行級鎖
復(fù)制需要進(jìn)行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時(shí)，需要比 RBR 請求更多的行級鎖
對于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其他 INSERT 語句
對于一些復(fù)雜的語句，在從服務(wù)器上的耗資源情況會更嚴(yán)重，而 RBR 模式下，只會對那個(gè)發(fā)生變化的記錄產(chǎn)生影響
存儲函數(shù)(不是存儲過程)在被調(diào)用的同時(shí)也會執(zhí)行一次 NOW() 函數(shù)，這個(gè)可以說是壞事也可能是好事
確定了的 UDF 也需要在從服務(wù)器上執(zhí)行
數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行，否則可能會導(dǎo)致復(fù)制出錯(cuò)
執(zhí)行復(fù)雜語句如果出錯(cuò)的話，會消耗更多資源

RBR 的優(yōu)點(diǎn)：

任何情況都可以被復(fù)制，這對復(fù)制來說是最安全可靠的
和其他大多數(shù)數(shù)據(jù)庫系統(tǒng)的復(fù)制技術(shù)一樣
多數(shù)情況下，從服務(wù)器上的表如果有主鍵的話，復(fù)制就會快了很多
復(fù)制以下幾種語句時(shí)的行鎖更少：
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句
執(zhí)行 INSERT，UPDATE，DELETE 語句時(shí)鎖更少
從服務(wù)器上采用多線程來執(zhí)行復(fù)制成為可能

RBR 的缺點(diǎn)：

binlog 大了很多
復(fù)雜的回滾時(shí) binlog 中會包含大量的數(shù)據(jù)
主服務(wù)器上執(zhí)行 UPDATE 語句時(shí)，所有發(fā)生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫問題
UDF 產(chǎn)生的大 BLOB 值會導(dǎo)致復(fù)制變慢
無法從 binlog 中看到都復(fù)制了寫什么語句
當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語句時(shí)，最好采用 SBR 模式，否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生

另外，針對系統(tǒng)庫 mysql 里面的表發(fā)生變化時(shí)的處理規(guī)則如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據(jù) binlog_format 的設(shè)定而記錄
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那么無論如何都采用 SBR 模式記錄
注：采用 RBR 模式后，能解決很多原先出現(xiàn)的主鍵重復(fù)問題。
本文出自http://www.111cn.net/database/mysql/71702.htm

轉(zhuǎn)載于:https://blog.51cto.com/lookingdream/1887316

總結(jié)

以上是生活随笔為你收集整理的mysql中binlog_format模式与配置详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。