MySql Replication基本原理
Replication的思想是将資料在叢集的多個節點同步、備份，以提高叢集資料的可用性（HA）；Mysql使用Replication架構來實作上述目的，同時可以提升了叢集整體的并發能力。5.6版本作為一個裡程碑，對replication做了不少的優化調整，提高了叢集資料的一緻性、同步的性能以及資料自動恢複（recovery）的能力。（本文内容基于MySQL 5.6+，不過在5.7+版本仍有部分調整）
Replication架構通常由一個master和一個或者多個slaves構成，master接收應用的writes操作（事務中的read、write操作均有master處理），slaves接收read操作。在master上發生的資料變更，都将會複制給slaves，從直覺而言，replication架構解決了：1）資料多點備份，提高資料可用性。 2）讀寫分流，提高叢集的并發能力。（并非是負載均衡）3）讓一些非實時的資料操作，轉移到slaves上進行。
下文中提到的“變更操作”為“insert”、“update”、“delete”等，與MySQL中的“update events”、“事務操作”、“writes”同義。
Replication具有如下優點：
1）擴充：将負載分布在多個slaves上以提高性能，所有的writes以及事務中的read操作都将有master處理，其他reads将轉發給slaves；對于“讀寫比”較高的應用，replication可以通過增加slaves節點來提高并發能力；因為write隻能在master上送出，是以架構擴充對提升write并發能力并不明顯，對于writes密集性應用我們應該考慮其他架構。
2）資料安全：slave可以中斷自己的replication程序，這不會打斷master上的資料請求，是以可以在slave上運作backup服務，定期全量backup是保護資料的手段之一。（如果在master上執行backup，需要讓master處于readonly狀态，這也意味這所有的write請求需要阻塞）。
3）分析：資料在master上建立，那麼資料分析可以在slave上進行，這将不會影響master的性能。利用mysql做資料分析（或者資料分析平台的源資料），通常都是将某個slave作為資料輸入端。
4）遠距資料分布：如果master的實體位置較遠，你可以在臨近需求的地方部署slaves，以便就近使用資料，而不需要總是通路遠端的master，這在資料分析、資料備份與容災等方面有很大幫助。
MySQL架構的演變分多個階段，目前基于replication架構模式的更進階架構設計有“MySQL Fabric”和“MySQL Cluster”。本文主要講解基本的replication模式，如下為replication與Fabirc、Cluster的差別，以便我們做技術選型：
1、MySQL Fabirc
Farbic由replication基礎特性和一些擴充架構建構而成，用于管理MySQL Servers Farms，與基本的replicaiton相比，它實作了2個核心的特性：HA和sharding。Fabric叢集中任何時候隻有一個Primary（即master），其他的執行個體為Secondaries（即slaves）；通過使用replication，将資料在多個節點上備份，HA總是保持叢集的資料可用性。如下特性是replication所不具備的：
1）故障檢測和角色遷移（Failover）：Fabric程序用于監控叢集中的所有節點，如果發現primary失效，稍後他将從Secondaries中選擇一個“資料最新”的節點，并提升為primary；此後其他的secondaries将從新的priamry上同步資料變更操作。Connectors（比如Connector/J用戶端）發現primary故障時也會通知Fabirc，那麼Fabric将通知資訊作為決策的一部分來判定priamry的狀态。這個特性簡稱為“自動Failover”，是replication架構中必備的手段之一。
2）資料庫請求路由（Router）：當Fabric提升一個新的primary後，它将會更新state store（存儲replication的節點狀态等），此後Connectors将會擷取新的state資料并在用戶端本地cache。是以，application不需要時刻關注（aware）叢集中servers拓撲結構的變化，隻需要根據state cache中的server狀态，将writes發送給相應的primary即可。這種特性有Connectors用戶端與與Fabric共同實作，在普通的replication架構中，用戶端自動角色路由是無法完成的。如果cache中拓撲不是最新的，application的操作異常将會回報給Fabirc，參考1）。
Fabirc支援sharding，對較大規模的資料可以非常便捷的在叢集中分布而無需太多人工幹預，我們可以簡單的認為Fabric是replication模式的完善，支援自動Failover。對于網際網路應用，Fabric架構簡單而且有效，是首選方案。
2、MySQL Cluster
相對于Fabirc，MySQL Cluster支援更大規模的資料，其架構模式和原理也更加複雜。Cluster是一個易于擴充、實時的、ACID相容的事務性資料庫，支援“全分布式”、“多Master”架構，無單點問題；MySQL Cluster可以部署在普通的商業機器上，多節點水準擴充、Server間資料自動sharding和負載均衡，用于服務read、write都密集的應用，可以使用SQL和NOSQL接口通路資料。Cluster的架構思想與Hadoop非常類似，它設計的前提是“認為每個Node都是易于出錯的”、叢集規模巨大、多租戶，是以它提供了資料備份機制、自動遷移、自動Failover等特性，來保證可用性、健壯性。
MySQL Cluster使用了一個插件式的存儲引擎，與MySQL 存儲引擎（InnoDB、MySAM）架構有很大不同，我們在此不做詳細介紹，隻需要知道它的核心特性為：資料集并不是存儲某個特定的MySQL執行個體上，而是被分布在多個Data Nodes中，即一個table的資料可能被分散在多個實體節點上，任何資料都會在多個Data Nodes上備援備份。任何一個資料變更操作，都将在一組Data Nodes上同步（嚴格意義上的同步，synchronous，二階段送出？）以保證資料的一緻性。
由此可見，Replication架構簡單、易于管理；Fabric是Replicaiton模式的完善和補充，增加了自動Failover和sharding機制，以支撐更大規模的資料通路，減少人工幹預；Cluster是一個全分布式架構，是面向大規模資料存儲的解決方案。
一、基礎
Replication模式的主要目的是将master上的資料變更複制到一個或者多個slaves上，多個節點備份以提高資料的可用性，避免單點問題；如果隻有一個mysql節點，那麼當此節點的主控端器損壞，将可能導緻資料永久性丢失。Replication與Connector配合，可以實作讀寫分流的功能，進而提升叢集整體的并發能力。
根據實際需要，我們可以指定某個（些）Databases或者tables參replication，不過replication的表現态仍然是叢集中所有的執行個體上資料集一樣，這與Farbic、Cluster不同，在Cluster中不同的Data Nodes上資料集或許完全不同。
Repliction模式中，在master上發生的資料變更都将被立即寫入binlog，此後它們被slaves讀取到本地，并應用這些資料變更操作，進而實作據“replication”。slaves的資料同步隻會消耗較少的master資源（每個slave或許有1%的額外開支），通常一個master組合幾個slaves（3~5個）是比較常見的，而不會有數十個slaves，否則你應該考慮Cluster架構。
二、複制模式（Replication models）
replication支援兩種模式：asynchronous（異步）、semi-synchronous（半同步）；“synchronous”複制隻有Cluster才支援，本文不做介紹。複制模式會對資料完整性有很大影響。
1、Asynchronous複制
這是replication的預設模式，在master上送出的updates操作執行成功且寫入binlog之後，master繼續處理其他的write請求，而不會等待slaves對此update資訊的複制或者應用；此後的任何時候，slaves均可以與master建立連結并複制那些尚未擷取的變更日志，然後在本地應用（apply）。
異步模式，無法保證當master失效後所有的updates已經複制到了slaves上，隻有重新開機master才能繼續恢複這些資料，如果master因為主控端器實體損壞而無法修複，那些尚未複制到slaves上的updates将永久性丢失；是以異步方式存在一定的資料丢失的風險，但它的優點就是master支援的write并發能力較強，因為master上的writes操作與slaves的複制是互為獨立的。
不過這種模式，slaves總有一定的延後，這種延後在事務操作密集的應用中更加明顯，不過通常這種延後時間都極其短暫的。從另一個方面來說，異步方式不要求slaves必須時刻與master建立連結，可能slaves離線、中斷了replication程序或者連結的傳輸延遲很高，這都不會影響master對writes請求的處理效率。比如對于“遠距分布”的slaves，異步複制是比較好的選擇。
此模式下，如果master失效，我們通常的做法是重新開機master，而不是failover到其他的slave，除非master無法恢複；因為master上會有些updates尚未複制給slaves，如果此時failover則意味着那些updates将丢失。
2、Semi-synchronous
“半同步”并不是MySQL内置的replication模式，而且由插件實作，即在使用此特性之前，需要在master和slaves上安裝插件，且通過配置檔案開啟“半同步”。當slave與master建立連接配接時會表明其是否開啟了“半同步”特性；此模式正常運作，需要master和至少一個slaves同時開啟，否則仍将采用“異步”複制。
在master上執行事務送出的線程，在事務送出後将會阻塞，直到至少一個“半同步”的slave傳回确認消息（ACK）或者所有的半同步slave都等待逾時；slave将接收到事務的資訊寫入到本地的relay log檔案且flush到磁盤後，才會向master傳回确認消息，需要注意slave并不需要此時就執行事務送出，此過程可以稍後進行。當所有的半同步slaves均在指定的時間内沒有傳回确認消息，即timeout，那麼此後master将轉換成異步複制模式，直到至少一個半同步slave完全跟進才會轉換為半同步模式。在master阻塞結束後才會傳回給用戶端執行的狀态，此期間不會處理其他的事務送出，當write請求傳回時即表明此操作在master上送出成功，且在至少一個半同步slaves也複制成功或者逾時，阻塞逾時并不會導緻事務的rollback。（對于事務性的表，比如innodb，預設是事務自動送出，當然可以關閉“autocommit”而手動送出事務，它們在replication複制機制中并沒有差別）
半同步模式需要在master和slaves上同時開啟，如果僅在master上開啟，或者master開啟而slaves關閉，最終仍然不能使用半同步複制，而是采用異步複制。
與異步複制相比，半同步提高了資料一緻性，降低了資料丢失的風險。但是它也引入了一個問題，就是master阻塞等待slaves的确認資訊，在一定程度上降低了master的writes并發能力，特别是當slaves與master之間網絡延遲較大時；是以我們斷定，半同步slaves應該部署在與master臨近的網絡中，為了提高資料一緻性，我們有必要将半同步作為replication的首選模式。
在實際的部署環境中，并不要求所有的slaves都開啟半同步，我們可以将與master臨近的slaves開啟半同步，将那些“遠距分布”的slaves使用異步。
三、日志格式（Replication Formats）
Replication之是以能夠工作，主要還是歸結于binlog（binary log），是以在replication模式下必須開啟binlog功能；slave從masters上增量擷取binlog資訊，并在本地應用日志中的變更操作（即“重放”）。變更操作将根據標明的格式類型寫入binlog檔案，目前支援三種format：
1、statement-based replication（SBR）：master将SQL statements語句寫入binlog，slave也将statements複制到本地執行；簡單而言，就是在master上執行的SQL變更語句，也同樣在slaves上執行。SBR模式是MySQL最早支援的類型，也是replication預設類型。如論何種情況，DDL語句一定是SBR格式。
2、row-based replication（RBR）： master将每行資料的變更資訊寫入binlog，每條binlog資訊表示一行（row）資料的變更内容，對于slaves而言将會複制binlog資訊，然後單條或者批量執行變更操作。
3、mix-format replication：混合模式，在這種模式下，master将根據根據存儲引擎、變更操作類型等，從SBR、RBR中來選擇更合适的日志格式，預設為SBR；具體選擇那種格式，這取決于變更操作發生的存儲引擎、statement的類型以及特征，優先選擇“資料一緻性”最好的方式（RBR），然後才兼顧性能，比如statement中含有“不确定性”方法或者批量變更，那麼将選擇RBR方式，其他的将選擇SBR以減少binlog的大小。我們建議使用mix方式。
SBR和RBR都有各自的優缺點，對于大部分用而言，mix方式在兼顧資料完整性和性能方面是最佳的選擇。
SBR的優點：因為binlog中隻寫入了變更操作的statements，是以日志量将會很小；當使用SQL語句批量更新、删除資料時，隻需要在binlog中記錄statement即可，可以大大減少log檔案對磁盤的使用。當然這也意味着slave複制資訊量也更少，以及通過binlog恢複資料更加快速。
SBR的缺點：有些變更操作使用SBR方式會帶來資料不一緻的問題，一些結果具有不确定性的操作使用SBR将會引入資料不一緻的問題。
1）statement中使用了UDF，UDF的計算結果可能依賴于SQL執行的時機和系統變量，這可能在slave上執行的結果與master不同，此外如果使用了trigger，也會帶來同樣的問題。（User Defination Fuction）；
2）對于批量delete或者update操作中，使用了limit限定詞，但是沒有使用“order by”，這樣的SQL語句執行的結果是不确定的，無論是在master還是slaves，即使在同一個節點上不同時機執行結果都有可能不一樣，replication同理，這歸因于MySQL資料存儲的機制。（預設排序将采用底層資料檔案的實際存儲順序，innodb為primary key順序）；
3）statement中使用了如下函數的（舉例）：UUID()，SYSDATE()，RAND()等，不過NOW()函數可以正确的被replication（但在UDF或者觸發器中則不行）；這些函數的特點就是它們的值依賴于本地系統，RAND()本身就是随機是以值是不确定的。如果statement中使用了上述函數，那麼将會在日志中輸出warning資訊；
4）對于“INSERT … SELECT”語句，SBR将比RBR需要更多的行鎖。如果UPDATE語句中沒有使用索引而導緻全表掃描的話，SBR将比RBR需要更多的行鎖。（主要是為了保障資料一緻性，需要同時鎖定受影響的所有的行，而RBR則不必要）；
5）對于InnoDB，使用“AUTO_INCREMENT”的insert語句，将會阻塞其他“非沖突”的INSERT。（因為AUTO_INCREMENT，為了避免并發導緻的資料一緻性問題，隻能串行，但RBR則不需要）；
6）對于複雜的SQL語句，在slaves上仍然需要評估（解析）然後才能執行，而對于RBR，SQL語句隻需要直接更新相應的行資料即可；
7）在slave上評估、執行SQL時可能會發生錯誤，這種錯誤會随着時間的推移而不斷累加，資料一緻性的問題或許會不斷增加。
RBR的優點：
1）所有的變更操作，都可以被正确的replication，這事最安全的方式；
2）對于“INSERT … SELECT”、包含“AUTO_INCREMENT”的inserts、沒有使用索引的UPDATE/DELETE，相對于SBR将需要更少的行鎖。（意味着并發能力更強）；
RBR的缺點：
1）最大的缺點，就是RBR需要更多的日志量。任何資料變更操作都将被寫入log，受影響的每行都要寫入日志，日志包含此行所有列的值（即使沒有值變更的列）；是以RBR的日志條數和尺寸都将會遠大于SBR，特别是在批量的UPDATE/DELETE時，可能會産生巨大的log量，反而對性能帶來影響，盡管這确實保障了資料一緻性，确導緻replication的效率較低；
2）對于MyISAN存儲引擎，INSERT語句将會阻塞更長的時間，因為在RBR模式下，MyISAM表不支援并發插入；
3）盡管是RBR模式，但是如果slave在更新非事務性表時，server被關閉，将會導緻資料不一緻性問題；是以在後續的版本中，我們希望master、slaves所有的表均使用InnoDB這樣的事務性存儲引擎，事務的有序性可以保證slave在crash之後啟動，資料恢複時仍能夠保證資料一緻性。
由此可見，SBR和RBR各有優缺點，這是個需要權衡的事情，本人認為資料一緻性是資料庫的首要考慮的因素，replication性能次之，是以在新的版本中，我們建議使用RBR方式或者mixed，通常mixed是官方推薦的。
四、GTID
GTID全名“Global Transaction Identifiers”，全局事務性ID，每個事務都用一個ID辨別，用于跟蹤master和slavers上事務送出的“進度”；這也意味着在Failover時，slaves可以不需要向新的master傳遞自己已經執行的log的positions（binglog的offset），隻需要告知新的master自己已經執行的最後一條事務的ID即可，這極大的簡化了failover、日志replication的複雜度。因為GTID完全基于事務，可以非常簡單的判定master與slaves是否一緻，隻要slaves與master上的事務送出均按照相同的順序送出，資料一緻性是可以得到保證的，為了更加安全，我們建議使用RBR模式 + GTID。
每個GTID是全局唯一的，由master在建立事務時生成并與事務過程一并寫入binlog，slaves隻對GTID讀取而不修改。GTID由“source_id:trasaction_id”組合而成（中間有“:”分割），其中source_id為源server的UUID（建立事務的master的UUID），transaction_id就是事務ID，是一個序列數字表示事務的順序（long型），每個事務都有不同的transaction_id；這種組合決定GTID的全局一緻性，同時我們也可以根據GTID來判定事務在哪個server上建立的。一個GTID的事務執行後，在此後遇到相同GTID的事務将會被忽略，在master上送出的事務，可以在slaves上多次重複執行（有序執行），這對資料恢複和保證資料一緻性非常有幫助。
在沒有GTID時，slave需要告知master，其已經複制的binlog檔案的offset；當使用GTID時，那麼GTID就想binlog的主鍵索引一樣，slave隻需要傳遞GTID即可繼續進行replication，在使用“CHANGE MASTER TO”指令做failover時也不要指定“MASTER_LOG_FILE”/“MASTER_LOG_POS”選項，而是直接在指令中使用“MASTER_AUTO_POSITION”選項即可，這對運維操作非常便捷。（稍後參看運維部分）
1）事務在master上執行并送出，并将此事務操作寫入binlog；
2）master将binlog增量發送給slaves，slaves将其内容儲存在relay log中（同binlog，主要用于replication）；
3）slaves從relay log中讀取尚未執行的GTID，并将其值設為“gtid_next”；slave檢測并確定此GTID沒有被執行過，同時也確定沒有其他的線程也在讀取和操作此GTID（多線程replication時），然後再本地執行此transaction并将事務寫入本地的binlog中。
基于GTID的repliction，有些特性将不能很好的支援。比如，在一個事務中更新了非事務性表（MyISAM）和事務性表（InnoDB），這将破壞事務的嚴格性，因為這種“混合更新”的事務在整個過程将會在binlog中産生多個GTIDs記錄，對slaves複制将會帶來影響，是以replication中在開啟GTID時将不支援“混合更新”。
比如上圖架構圖，當master失效後，我們需要将其中一個slave提升為master，預設采用“異步複制”方式，是以B和C或許都沒有完全複制master上的事務，而且有可能B和C的複制進度有一些差異。我們假定，B比C更加超前，是以，B将被提升為master，此後C需要與B建立從屬關系，并從B中複制、執行那些尚未接收到的事務（由GTID判定）；當然B也需要從C中複制那些自己缺失的GTIDs，當B和C資料對齊之後，B正式提升為Master。
在新的replication協定中，當slave與master建立連結後，它将會發送自己已經執行和送出的事務GTIDs的範圍（gtid_executed），master将會向slave響應slaves缺失的事務清單；如上例所示，C向B發送id1，那麼B向C響應id2、id3。
五、實作原理
在上述介紹中我們已經基本了解了replication的原理：每個slaves與master建立連結，并從master“拉取”（pull）binlog副本并儲存在本地（relay log），不是master主動push給slaves；slaves從本地log檔案中讀取變更操作并執行。每個slave都是互相獨立的，各自的replication過程互不幹擾，當然每個slave可以根據需要啟動或者暫停replication程序，而不會影響master與其他slaves的複制。
replication功能有三個線程實作，其中一個在master上，另外2個在slaves上。
1、Binlog dump線程：master上建立一個線程用于向slave發送binlog内容，我們可以通過“SHOW PROCESSLIST”指令檢視到一個名為“Binlog Dump”的線程。dump線程會對binlog檔案擷取一個讀鎖，并讀取内容發送給slave，隻要一個變更操作讀取完畢後，鎖即釋放，即使内容尚未發送給slave；
2、Slave I/O線程：當在slave上執行“START SLAVE”後，将會建立一個I/O線程，它負責與master建立連結并請求需要的binlog，并儲存在本地的relay log中。在slave上執行“SHOW SLAVE STATUS”可以檢視“Slave_IO_running”的狀态；
master為每個slave建立一個單獨的Binlog dump線程，并同時與它們互動，每個slave持有各自的IO和SQL線程。slave使用2個單獨的線程來完成replication過程，以便它們互相影響，比如IO線程不會因為SQL線程執行較慢而拖累與master的讀取速率，當slave停止了一段時間後重新開機，那麼IO線程仍然可以快速的與master跟進，即使SQL線程已經落後太多；這種線程分離，最大的收益就是提高了slave複制的效率，避免slave與master差距太大，進而保證了資料安全。
我們可以通過“SHOW PROCESSLIST”來檢視上述線程的運作狀态。也可以使用“SHOW SLAVE STATUS”、“SHOW MASTER STATUS”來檢視與replication有關的更多狀态資訊。
在replication期間，master隻需要建立與更新binlog檔案即可，不過對于slave，為了複制和failover需要建立多種檔案。
1、relay log：我們在上文中已經提到，slave IO線程從master讀取的binlog資料首先儲存在本地的relay log中；此後SQL線程即可從relay log中讀取變更操作并在本地應用。嚴格意義上說，relay log的内容應該與master binlog逐位元組一緻的（byte-to-byte）；
2、master info：master-info log檔案儲存了slave與目前master建立連結的一些配置資訊和連結狀态，日志中包括：master的host名稱、login認證資訊，以及slave讀取master binlog的位置資訊。在5.6之前，資訊儲存在master.info檔案中，5.6之後，可以通過“–master-info-repository=TABLE”啟動參數（或者配置檔案）将資訊儲存在“mysql.slave_master_info”系統表中；
3、relay log info：用于記錄relay log執行點的狀态資訊，在5.6之前預設寫入relay-log.info檔案，5.6之後可以通過“–relay-log-info-repository=TABLE”将資訊寫入“mysql.slave_relay_log_info”系統表中。
為了避免crash對資料帶來的不一緻問題，強烈建議将master-info、relay-log-info采用事務性表，而且建議開啟“–relay-log-recovery”。不過很遺憾的是，在5.6.5之前的版本中，slave_master_info、slave_relay_log_info表預設為MyISAM，需要手動修改為InnoDB。
4、binlog：這個大家都很熟悉，slave上也可以開啟binlog功能，比如slave是其他slave的master時。
relay log内容格式與binlog一樣，也可以使用mysqlbinlog shell檢視。 relay log也是有多個檔案組成，和binlog非常相似，檔案名稱格式類似于“host_name-relay-bin.”，此外還有一個index檔案用來記錄那些relay log檔案還在使用中，不能被删除（對于master而言，binlog也是如此）。SQL線程執行完一個relay log中的變更操作後，将會自動删除此檔案，因為它不再需要。關于relay log、master info檔案的内容請參看連結。
六、架構拓撲
根據replication的機制，它可以有多種架構拓撲結構，如圖所示：
1、Master-slave、Master-slaves：這是目前最常見的架構模式，一個master與一個或者多個slaves組合，實施簡單而且有效，是首選方式之一，不僅實作了HA，而且還能讀寫分離，進而提升叢集的并發能力；
2、Master-slave-slaves：多級複制模式， 部分slave不與master跟進，而是與其他slave跟進，這在某些特殊場景下非常有效！我們知道如果master有太多的slave跟進，master将會損耗一部分性能用于replication，在上文中已經知道“半同步”的特性，那麼我們可以讓3~5個slaves與master跟進，并使用“半同步”複制模式，其他的slaves作為二級，與其他slave(s)跟進，采用“異步”複制模式，這樣不僅緩解了master的壓力，而且對資料一緻性并沒有負面影響；而且二級slaves可以作為“離線資料統計”、“遠距資料中心”等特殊使用場景，因為它們對資料的實時性要求不要；
七、優化調整
1、多線程
在slave上使用多線程方式進行replication過程，可以有效提高效率。
slave将多個線程根據database分割，其中一個線程為“coordinator”（協調器），從relay log中讀取變更操作，然後将不同database的操作發送給不同的worker線程，并由worker線程負責執行；可以通過“slave-parallel-workers”參數指定worker線程的個數。預設情況下slave隻有一個線程，即SQL線程，此線程負責讀取relay log并執行變更操作，那麼在多線程模式下，一個線程專門負責讀取relay log，并将讀取的變更操作根據database分發給不同的worker線程，那麼多個database中的變更操作将可以并行的執行，這将極大的提高了replication的效率。不過這也會引入一些問題，比如事務的順序可能會與master不同，我們稍後在“【配置參數】”部分介紹。
2、binlog批量送出（Group commit）
binlog資料最終要寫入磁盤，磁盤寫入的頻率越高，性能也就越低（磁盤IO效率低）；我們可以開啟binlog批量送出，而不是每個變更操作都立即寫入binlog，這樣可以有效的提高磁盤IO的性能。“sync_binlog”參數來控制磁盤寫入的頻率，預設為0，即有作業系統決定binlog檔案flush的時機，“1”表示每個變更操作寫入binlog後都立即flush磁盤，其他值表示多個變更操作後才flush磁盤。
3、RBR優化
前文已經提到，基于RBR複制時，master将會把變更操作影響的行的所有列的值都寫入binlog，這确實提高了資料的安全性，但是卻增加了binlog的日志量，也增加了master與slave之間的網絡傳輸量。我們可以通過“binlog-row-image”參數來控制binlog輸出：
2）minimal：隻記錄資料變更的列以及能夠标定此row的列（比如主鍵列）；此選項通常比較合适，日志量較少，而且實用。
3）noblob：記錄所有的列（包括未變更的列），但是不包括blob和text類型的沒有變更的列；簡而言之，就是沒有變更的大字段不會寫入binlog，其他字段無論是否變更均會寫入，具有“full”和“minimal”的優點。
轉自：https://www.cnblogs.com/nulige/p/9491850.html