MYSQL復制的幾種模式

MySQL 5.1 中，在復制方面的改進就是引進了新的復制技術：基于行的復制。

MYSQL復制的幾種模式

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表時【NDB為分布式所創】
. 當函數中包含 UUID() 時
. 2個及以上包含 AUTO_INCREMENT 字段的表被更新時
. 行任何 INSERT DELAYED 語句時
. 用 UDF 時
. 視圖中必須要求使用 RBR 時，例如創建視圖是使用了 UUID() 函數

設定主從復制模式的方法非常簡單，只要在以前設定復制配置的基礎上，再加一個參數：
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 模式后，能解決很多原先出現的主鍵重復問題。

?

實例:?
對于insert into db_allot_ids select * from db_allot_ids 這個語句:?
在BINLOG_FORMAT=STATEMENT 模式下:?
BINLOG日志信息為:?
-----------------------------------------
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids?
/*!*/;
-----------------------------------------

在BINLOG_FORMAT=ROW 模式下:
BINLOG日志信息為:
-----------------------------------------
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
-----------------------------------------
確實看不懂里面記的是啥.

二、Replication 實現級別

　　由于MySQL Replication 是基于 Binary Log 實現的，所以Replication 的實現級別實際上是由Binary Log 的存儲格式所決定。Binary Log 中記錄 Eent 的方式可以是基于一條語句(Statement Level)，也可以是基于一條記錄(Row level)，這可以在 MySQL 的配置參數(—binlog-format)中設定這個格式。

　　1. Row Level：Binary Log 中會記錄成每一行數據被修改的形式，然后在 Slave 端再對相同的數據進行修改。

　　優點：在 Row Level 模式下，Binary Log 中可以不記錄執行的sql語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以 Row Level 的日志內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確復制的問題。

　　缺點：Row Level下，所有的執行的語句當記錄到 Binary Log 中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，比如有這樣一條update語句：UPDATE group_message SET group_id = 1 where group_id = 2，執行之后，日志中記錄的不是這條update語句所對應的事件(MySQL以事件的形式來記錄 Binary Log 日志)，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，Binary Log 日志的量就會很大。尤其是當執行ALTER TABLE 之類的語句的時候，產生的日志量是驚人的。因為MySQL對于 ALTER TABLE 之類的 DDL 變更語句的處理方式是重建整個表的所有數據，也就是說表中的每一條記錄都需要變動，那么該表的每一條記錄都會被記錄到日志中。

　　2. Statement Level:每一條會修改數據的 Query 都會記錄到 Master的 Binary Log 中。Slave在復制的時候 SQL 線程會解析成和原來 Master 端執行過的相同的 Query 來再次執行。

　　優點：Statement Level下的優點首先就是解決了Row Level下的缺點，不需要記錄每一行數據的變化，減少 Binary Log 日志量，節約了 IO 成本，提高了性能。因為他只需要記錄在Master上所執行的語句的細節，以及執行語句時候的上下文的信息。

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

　　3.?Mixed Level: 從 5.1.8 版本開始，MySQL 提供了除Statement Level和Row Level之外的第三種 Mixed Level，實際上就是前兩種模式的結合。在Mixed模式下，MySQL會根據執行的每一條具體的 Query 語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。除了MySQL認為通過STATEMENT方式可能造成復制過程中Master與Slave之間產生不一致數據(如特殊Procedure和Function的使用，UUID()函數的使用等特殊情況)的時候MySQL會選擇ROW的模式來記錄變更之外，都會使用STATEMENT模式來記錄變更。當然，這里需要排除的特殊情況并不僅僅只有上面所描述的這幾種，具體請參考 MySQL 官方的詳細手冊。

　　老版本的 MySQL 一直都只有基于 Statement 的復制模式，直到5.1.5版本的 MySQL 才開始支持Row Level的復制。從5.0開始，MySQL 的復制已經解決了大量老版本中出現的無法正確復制的問題。但是由于存儲過程的出現，給 MySQL 的復制又帶來了更大的新挑戰。另外，看到官方文檔說，從5.1.8版本開始，MySQL 開始提供 Mixed Level，新版本中的Statment level還是和以前一樣，僅僅記錄執行的語句。而新版本的Mysql中隊Row Level模式也被做了優化，并不是所有的修改都會以Row Level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果 Query 語句確實就是 UPDATE 或者 DELETE 等修改數據的語句，那么還是會記錄所有行的變更。

來源：http://blog.csdn.net/adparking/article/details/7586054

?

?

轉載于:https://blog.51cto.com/longzhiyi/903894

總結

以上是生活随笔為你收集整理的MYSQL复制的几种模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。