MySQL binlog 格式（Mixed，Statement，Row Level）

推薦用mixed，默認使用statement，基於上下文。

MySQL Replication複製能夠是基於一條語句(Statement level)，也能夠是基於一條記錄(Row level)，能夠在MySQL的配置參數中設定這個複製級別，不一樣複製級別的設置會影響到Master端的bin-log記錄成不一樣的形式。

Row Level：日誌中會記錄成每一行數據被修改的形式，而後在slave端再對相同的數據進行修改。

優勢：在row level模式下，bin-log中能夠不記錄執行的sql語句的上下文相關的信息，僅僅只須要記錄那一條記錄被修改了，修改爲什麼樣了。因此row level的日誌內容會很是清楚的記錄下每一行數據修改的細節，很是容易理解。並且不會出現某些特定狀況下的存儲過程，或function，以及trigger的調用和觸發沒法被正確複製的問題。

缺點：row level下，全部的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容，好比有這樣一條update語句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，執行以後，日誌中記錄的不是這條update語句所對應額事件(MySQL以事件的形式來記錄bin-log日誌)，而是這條語句所更新的每一條記錄的變化狀況，這樣就記錄成不少條記錄被更新的不少個事件。天然，bin-log日誌的量就會很大。尤爲是當執行alter table之類的語句的時候，產生的日誌量是驚人的。由於MySQL對於alter table之類的表結構變動語句的處理方式是整個表的每一條記錄都須要變更，實際上就是重建了整個表。那麼該表的每一條記錄都會被記錄到日誌中。

Statement Level:每一條會修改數據的sql都會記錄到 master的bin-log中。slave在複製的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。

優勢：statement level下的優勢首先就是解決了row level下的缺點，不須要記錄每一行數據的變化，減小bin-log日誌量，節約IO，提升性能。由於他只須要記錄在Master上所執行的語句的細節，以及執行語句時候的上下文的信息。

缺點：因爲他是記錄的執行語句，因此，爲了讓這些語句在slave端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證全部語句在slave端杯執行的時候可以獲得和在master端執行時候相同的結果。另外就是，因爲MySQL如今發展比較快，不少的新功能不斷的加入，使MySQL得複製遇到了不小的挑戰，天然複製的時候涉及到越複雜的內容，bug也就越容易出現。在statement level下，目前已經發現的就有很多狀況會形成MySQL的複製出現問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，好比：sleep()函數在有些版本中就不能真確複製，在存儲過程當中使用了last_insert_id()函數，可能會使slave和master上獲得不一致的id等等。因爲row level是基於每一行來記錄的變化，因此不會出現相似的問題。

從官方文檔中看到，以前的MySQL一直都只有基於statement的複製模式，直到5.1.5版本的MySQL纔開始支持row level的複製。從5.0開始，MySQL的複製已經解決了大量老版本中出現的沒法正確複製的問題。可是因爲存儲過程的出現，給MySQL Replication複製又帶來了更大的新挑戰。另外，看到官方文檔說，從5.1.8版本開始，MySQL提供了除Statement Level和Row Level以外的第三種複製模式：Mixed，實際上就是前兩種模式的結合。在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。新版本中的Statment level仍是和之前同樣，僅僅記錄執行的語句。而新版本的MySQL中隊row level模式也被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄，若是sql語句確實就是update或者delete等修改數據的語句，那麼仍是會記錄全部行的變動。

下面值得一讀：：

-- 基於SQL語句的複製(statement-based replication, SBR)，
-- 基於行的複製(row-based replication, RBR)，
-- 混合模式複製(mixed-based replication, MBR)。
相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認的。

在運行時能夠動態改動 binlog的格式，除了如下幾種狀況：
. 存儲流程或者觸發器中間
. 啓用了NDB
. 當前會話試用 RBR 模式，而且已打開了臨時表

若是binlog採用了 MIXED 模式，那麼在如下幾種狀況下會自動將binlog的模式由 SBR 模式改爲 RBR 模式。
. 當DML語句更新一個NDB表時
. 當函數中包含 UUID() 時
. 2個及以上包含 AUTO_INCREMENT 字段的表被更新時
. 行任何 INSERT DELAYED 語句時
. 用 UDF 時
. 視圖中必需要求運用 RBR 時，例如創建視圖是運用了 UUID() 函數

設定主從複製模式：
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

也能夠在運行時動態修改binlog的格式。例如
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

兩種模式各自的優缺點：

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 模式後，能處理不少原先出現的主鍵重複問題。