今天就跟大家聊聊有關(guān)MySQL5.7主從同步中binlog同步模式是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

成都創(chuàng)新互聯(lián)公司專注于額敏企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站制作。額敏網(wǎng)站建設(shè)公司,為額敏等地區(qū)提供建站服務(wù)。全流程按需開發(fā)，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

mysql5.7主從同步中binlog同步模式(binlog_format)中MIXED模式效率和穩(wěn)定性最好。

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

一、同步模式

1.STATEMENT模式(SBR)

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

2.ROW模式(RBR)

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

3.MIXED模式(MBR)

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

二、binlog復(fù)制配置

在mysql的配置文件my.cnf中，可以通過一下選項配置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過期清理時間
max_binlog_size         = 100m                       //binlog每個日志文件大小
binlog_cache_size       = 4m                        //binlog緩存大小
max_binlog_cache_size   = 512m                     //最大binlog緩存大小

三、MIXED說明

對于執(zhí)行的SQL語句中包含now()這樣的時間函數(shù)，會在日志中產(chǎn)生對應(yīng)的unix_timestamp()*1000的時間字符串，slave在完成同步時，取用的是sqlEvent發(fā)生的時間來保證數(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)缺點：

SBR 的優(yōu)點：

歷史悠久，技術(shù)成熟

binlog文件較小

binlog中包含了所有數(shù)據(jù)庫更改信息，可以據(jù)此來審核數(shù)據(jù)庫的安全等情況

binlog可以用于實時的還原，而不僅僅用于復(fù)制

主從版本可以不一樣，從服務(wù)器版本可以比主服務(wù)器版本高

SBR 的缺點：

不是所有的UPDATE語句都能被復(fù)制，尤其是包含不確定操作的時候。

調(diào)用具有不確定因素的 UDF 時復(fù)制也可能出問題

使用以下函數(shù)的語句也無法被復(fù)制：

* LOAD_FILE()

* UUID()

* USER()

* FOUND_ROWS()

* SYSDATE() (除非啟動時啟用了 --sysdate-is-now 選項)

INSERT ... SELECT 會產(chǎn)生比 RBR 更多的行級鎖

復(fù)制需要進(jìn)行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，需要比 RBR 請求更多的行級鎖

對于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其他 INSERT 語句

對于一些復(fù)雜的語句，在從服務(wù)器上的耗資源情況會更嚴(yán)重，而 RBR 模式下，只會對那個發(fā)生變化的記錄產(chǎn)生影響

存儲函數(shù)(不是存儲過程)在被調(diào)用的同時也會執(zhí)行一次 NOW() 函數(shù)，這個可以說是壞事也可能是好事

確定了的 UDF 也需要在從服務(wù)器上執(zhí)行

數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行，否則可能會導(dǎo)致復(fù)制出錯

執(zhí)行復(fù)雜語句如果出錯的話，會消耗更多資源

RBR 的優(yōu)點：

任何情況都可以被復(fù)制，這對復(fù)制來說是最安全可靠的

和其他大多數(shù)數(shù)據(jù)庫系統(tǒng)的復(fù)制技術(shù)一樣

多數(shù)情況下，從服務(wù)器上的表如果有主鍵的話，復(fù)制就會快了很多

復(fù)制以下幾種語句時的行鎖更少：

* INSERT ... SELECT

* 包含 AUTO_INCREMENT 字段的 INSERT

* 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句

執(zhí)行 INSERT，UPDATE，DELETE 語句時鎖更少

從服務(wù)器上采用多線程來執(zhí)行復(fù)制成為可能

RBR 的缺點：

binlog 大了很多

復(fù)雜的回滾時 binlog 中會包含大量的數(shù)據(jù)

主服務(wù)器上執(zhí)行 UPDATE 語句時，所有發(fā)生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫問題

UDF 產(chǎn)生的大 BLOB 值會導(dǎo)致復(fù)制變慢

無法從 binlog 中看到都復(fù)制了寫什么語句

當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語句時，最好采用 SBR 模式，否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生

另外，針對系統(tǒng)庫 mysql 里面的表發(fā)生變化時的處理規(guī)則如下：

如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據(jù) binlog_format 的設(shè)定而記錄

如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那么無論如何都采用 SBR 模式記錄

注：采用 RBR 模式后，能解決很多原先出現(xiàn)的主鍵重復(fù)問題。

看完上述內(nèi)容，你們對mysql5.7主從同步中binlog同步模式是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。