binlog-format

下面的這些是在網上找的！沒有寫明出處！如果有問題，聯系我，我删掉！

MySQL 5.1 中，在複制方面的改進就是引進了新的複制技術：基于行的複制。簡言之，這種新技術就是關注表中發生變化的記錄，而非以前

的照抄 binlog 模式。從 MySQL 5.1.12 開始，可以用以下三種模式來實作：基于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() 函數

設定主從複制模式的方法非常簡單，隻要在以前設定複制配置的基礎上，再加一個參數：

當然了，也可以在運作時動态修改binlog的格式。例如

現在來比較以下 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 模式後，能解決很多原先出現的主鍵重複問題。