MariaDB/Mysql之主從架構的複製原理及主從/雙主配置詳解(二)

緊接上篇博文《MariaDB/Mysql之主從架構的複製原理及主從/雙主配置詳解(一)》

3.深刻了解複製

3.一、基於語句的複製(Statement-Based Replication)

MySQL 5.0及以前的版本僅支持基於語句的複製（也叫作邏輯複製，logical replication），這在數據庫並不常見。master記錄下改變數據的查詢，而後，slave從中繼日誌中讀取事件，並執行它，這些SQL語句與master執行的語句同樣。
這種方式的優勢就是實現簡單。此外，基於語句的複製的二進制日誌能夠很好的進行壓縮，並且日誌的數據量也較小，佔用帶寬少——例如，一個更新GB的數據的查詢僅須要幾十個字節的二進制日誌。而mysqlbinlog對於基於語句的日誌處理十分方便。
   可是，基於語句的複製並非像它看起來那麼簡單，由於一些查詢語句依賴於master的特定條件，例如，master與slave可能有不一樣的時間。因此，MySQL的二進制日誌的格式不只僅是查詢語句，還包括一些元數據信息，例如，當前的時間戳。即便如此，仍是有一些語句，好比，CURRENT USER函數，不能正確的進行復制。此外，存儲過程和觸發器也是一個問題。
    另一個問題就是基於語句的複製必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。並非全部的存儲引擎都支持基於語句的複製。

3.二、基於記錄的複製(Row-Based Replication)

     MySQL增長基於記錄的複製，在二進制日誌中記錄下實際數據的改變，這與其它一些DBMS的實現方式相似。這種方式有優勢，也有缺點。優勢就是能夠對任何語句都能正確工做，一些語句的效率更高。主要的缺點就是二進制日誌可能會很大，並且不直觀，因此，你不能使用mysqlbinlog來查看二進制日誌。
對於一些語句，基於記錄的複製可以更有效的工做，如：
mysql> INSERT INTO summary_table(col1, col2, sum_col3)
   -> SELECT col1, col2, sum(col3)
   -> FROM enormous_table
   -> GROUP BY col1, col2;
    假設，只有三種惟一的col1和col2的組合，可是，該查詢會掃描原表的許多行，卻僅返回三條記錄。此時，基於記錄的複製效率更高。
   另外一方面，下面的語句，基於語句的複製更有效：
mysql> UPDATE enormous_table SET col1 = 0;
此時使用基於記錄的複製代價會很是高。因爲兩種方式不能對全部狀況都能很好的處理，因此，MySQL 5.1支持在基於語句的複製和基於記錄的複製以前動態交換。你能夠經過設置session變量binlog_format來進行控制。

3.三、複製相關的文件

除了二進制日誌和中繼日誌文件外，還有其它一些與複製相關的文件。以下：

(1)mysql-bin.index

服務器一旦開啓二進制日誌，會產生一個與二日誌文件同名，可是以.index結尾的文件。它用於跟蹤磁盤上存在哪些二進制日誌文件。MySQL用它來定位二進制日誌文件。

(2)mysql-relay-bin.index

該文件的功能與mysql-bin.index相似，可是它是針對中繼日誌，而不是二進制日誌。

(3)master.info

保存從服務器鏈接至主服務時所須要的信息，每行一個值保存master的相關信息。不要刪除它，不然，slave重啓後不能鏈接master。

(4)relay-log.info

保存了複製位置：包括二進制日誌和中繼日誌的文件及位置。

3.四、發送複製事件到其它slave

當設置log_slave_updates時，你可讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行本身的二進制日誌(binary log)，而後，它的slave能夠獲取這些事件並執行它。以下：

3.五、複製過濾(Replication Filters)

複製過濾可讓你只復***務器中的一部分數據，有兩種複製過濾：在master上過濾二進制日誌中的事件；在slave上過濾中繼日誌中的事件。以下：

4.複製的經常使用拓撲結構

複製的體系結構有如下一些基本原則：
(1)每一個slave能夠有一個或多個master；
(2)每一個slave只能有一個惟一的服務器ID；
(3)每一個master能夠有不少slave；
(4)若是設置log_slave_updates，slave能夠是其它slave的master，從而擴散master的更新。

在早期的MySQL是不支持多主服務器複製(Multimaster Replication)——即一個slave能夠有多個master的場景,可是MariaDB目前已經支持。可是，經過一些簡單的組合，咱們卻能夠創建靈活而強大的複製體系結構。

4.一、單一master和多slave

由一個master和一個slave組成複製系統是最簡單的狀況。Slave之間並不相互通訊，只能與master進行通訊。

在實際應用場景中，MySQL複製90%以上都是一個Master複製到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。由於只要Master和Slave的壓力不是太大（尤爲是Slave端壓力）的話，異步複製的延時通常都不多不多。尤爲是自從Slave端的複製方式改爲兩個線程處理以後，更是減少了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只須要經過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多臺Slave的機器上面，便可經過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力仍是要比寫壓力大不少。這在很大程度上解決了目前不少中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用相似方案解決數據庫瓶頸。

以下：

若是寫操做較少，而讀操做很時，能夠採起這種結構。你能夠將讀操做分佈到其它的slave，從而減少master的壓力。可是， 當slave增長到必定數量時，slave對master的負載以及網絡帶寬都會成爲一個嚴重的問題。
這種結構雖然簡單，可是，它卻很是靈活，足夠知足大多數應用需求。一些建議：
(1)    不一樣的slave扮演不一樣的做用(例如使用不一樣的索引，或者不一樣的存儲引擎)；
(2)    用一個slave做爲備用master，只進行復制；
(3)    用一個遠程的slave，用於災難恢復；

你們應該都比較清楚，從一個Master節點能夠複製出多個Slave節點，可能有人會想，那一個Slave節點是否能夠從多個Master節點上面進行復制呢？這是徹底能夠實現的,目前在MariaDB中已經實現multi-master replication 功能;可參考《MariaDB多源(主)複製》

4.二、主動模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master複製的兩臺服務器，既是master，又是另外一臺服務器的slave。這樣，任何一方所作的變動，都會經過複製應用到另一方的數據庫中。

可能有些讀者朋友會有一個擔憂，這樣搭建複製環境以後，難道不會形成兩臺MySQL之間的循環複製麼？實際上MySQL本身早就想到了這一點，因此在MySQL的BinaryLog中記錄了當前MySQL的server-id，並且這個參數也是咱們搭建MySQLReplication的時候必須明確指定，並且Master和Slave的server-id參數值比須要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值以後，MySQL就很容易判斷某個變動是從哪個MySQLServer最初產生的，因此就很容易避免出現循環複製的狀況。並且，若是咱們不打開記錄Slave的BinaryLog的選項（--log-slave-update）的時候，MySQL根本就不會記錄複製過程當中的變動到BinaryLog中，就更不用擔憂可能會出現循環複製的情形了。

如圖：

   主動的Master-Master複製有一些特殊的用處。例如，地理上分佈的兩個部分都須要本身的可寫的數據副本。這種結構最大的問題就是更新衝突。假設一個表只有一行(一列)的數據，其值爲1，若是兩個服務器分別同時執行以下語句：
在第一個服務器上執行：
mysql> UPDATE tbl SET col=col + 1;
在第二個服務器上執行：
mysql> UPDATE tbl SET col=col * 2;
那麼結果是多少呢？一臺服務器是4，另外一個服務器是3，可是，這並不會產生錯誤。

實際上，MySQL並不支持其它一些DBMS支持的多主服務器複製(Multimaster Replication)，這是MySQL的複製功能很大的一個限制(多主服務器的難點在於解決更新衝突)，可是，若是你實在有這種需求，你能夠採用MySQL Cluster，以及將Cluster和Replication結合起來，能夠創建強大的高性能的數據庫平臺。可是，能夠經過其它一些方式來模擬這種多主服務器的複製。

示例:雙主模式配置:

環境：

Master1/Master2	Platfrom	IP	APP Version
Master1	CentOS6.5_X86-64	172.16.41.1	mariadb-10.0.10
Master2	CentOS6.5_X86-64	172.16.41.2	mariadb-10.0.10

1.配置雙主:

#Master1的配置：

(1)修改server-id

主配置文件/etc/my.cnf [mysqld]段中,修改以下行：

server-id  =  1

(2)啓用中繼日誌,二進制日誌

主配置文件/etc/my.cnf [mysqld]段中,修改以下行：

log-bin = /mydata/binlogs/master1-bin relay-log = /mydata/relaylogs/relay-bin 確保中繼日誌選項開啓 MariaDB [(none)]> SHOW GLOBAL  VARIABLES LIKE 'relay_log'; +---------------+-----------------------------+ | Variable_name | Value                       | +---------------+-----------------------------+ | relay_log     | /mydata/relaylogs/relay-bin | +---------------+-----------------------------+ 1 row in set (0.00 sec)

(3)添加下面兩項,以免在MySQL自動爲INSERT語句選擇不互相沖突的值

auto-increment-offset = 1     //起始值 auto-increment-increment = 2   //步長 確保自動增加選項已開啓： MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name            | Value | +--------------------------+-------+ | auto_increment_increment | 2     | | auto_increment_offset    | 1     | +--------------------------+-------+

(4)建立有複製權限的用戶,命令以下：

MariaDB [(none)]> CREATE USER 'luccy'@'172.16.41.2' IDENTIFIED BY 'qazwsx123'; MariaDB [(none)]> REVOKE ALL PRIVILEGES ,GRANT OPTION FROM 'luccy'@'172.16.41.2'; MariaDB [(none)]> GRANT RELOAD,LOCK TABLES, REPLICATION CLIENT ,REPLICATION SLAVE ON *.* TO 'luccy'@'172.16.41.2'; MariaDB [(none)]> FLUSH PRIVILEGES;

#Master2的配置：

(1)修改server-id#

主配置文件/etc/my.cnf [mysqld]段中,修改以下行：

server-id  =  2

(2)啓用中繼日誌,二進制日誌

log-bin = /mydata/binlogs/master2-bin   relay-log = /mydata/relaylogs/relay-bin 確保中繼日誌選項開啓 MariaDB [(none)]> SHOW GLOBAL  VARIABLES LIKE 'relay_log'; +---------------+-----------------------------+ | Variable_name | Value                       | +---------------+-----------------------------+ | relay_log     | /mydata/relaylogs/relay-bin | +---------------+-----------------------------+

(3)添加下面兩項,以免在MySQL自動爲INSERT語句選擇不互相沖突的值

auto-increment-offset = 2     //起始值 auto-increment-increment = 2   //步長 確保自動增加選項已開啓： MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name            | Value | +--------------------------+-------+ | auto_increment_increment | 2    | | auto_increment_offset    | 2    | +--------------------------+-------+

(4)建立有複製權限的用戶,命令以下：

MariaDB [(none)]> CREATE USER 'jerry'@'172.16.41.1' IDENTIFIED BY 'qazwsx123'; MariaDB [(none)]> REVOKE ALL PRIVILEGES ,GRANT OPTION FROM 'jerry'@'172.16.41.1'; MariaDB [(none)]> GRANT RELOAD,LOCK TABLES, REPLICATION CLIENT ,REPLICATION SLAVE ON *.* TO 'jerry'@'172.16.41.1'; MariaDB [(none)]> FLUSH PRIVILEGES;

   若是此時兩臺服務器均爲新創建，且無其它寫入操做，各服務器只需記錄當前本身二進制日誌文件及事件位置，以之做爲另外的服務器複製起始位置便可

#Master1: MariaDB [(none)]> SHOW MASTER STATUS; +--------------------+----------+--------------+------------------+ | File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | +--------------------+----------+--------------+------------------+ | master1-bin.000001 |      969 |              |                  | +--------------------+----------+--------------+------------------+ #Master2: MariaDB [(none)]> SHOW MASTER STATUS; +--------------------+----------+--------------+------------------+ | File               | Position | Binlog_Do_DB | Binlog_Ignore_DB | +--------------------+----------+--------------+------------------+ | master2-bin.000001 |      314 |              |                  | +--------------------+----------+--------------+------------------+

   各服務器接下來指定對另外一臺服務器爲本身的主服務器

#Master1指向Master2 MariaDB [(none)]> CHANGE MASTER TO MASTER_USER='luccy',MASTER_HOST='172.16.41.2',MASTER_PASSWORD='qazwsx123',MASTER_LOG_FILE='master2-bin.000005',MASTER_LOG_POS=328; #Master2指向Master1 MariaDB [(none)]> CHANGE MASTER TO MASTER_USER='jerry',MASTER_HOST='172.16.41.1',MASTER_PASSWORD='qazwsx123',MASTER_LOG_FILE='master1-bin.000005',MASTER_LOG_POS=1592;

   啓動個服務器複製進程

#Master1 MariaDB [(none)]> START SLAVE; MariaDB [mysql]> SHOW SLAVE STATUS\G *************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.16.41.2                  Master_User: jerry                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: master2-bin.000006          Read_Master_Log_Pos: 328               Relay_Log_File: relay-bin.000004                Relay_Log_Pos: 617        Relay_Master_Log_File: master2-bin.000006             Slave_IO_Running: Yes            Slave_SQL_Running: Yes              Replicate_Do_DB:                ..........                .......... #Master2 MariaDB [(none)]> START SLAVE; MariaDB [(none)]> SHOW SLAVE STATUS\G *************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 172.16.41.1                  Master_User: luccy                  Master_Port: 3306                Connect_Retry: 60              Master_Log_File: master1-bin.000005          Read_Master_Log_Pos: 1592               Relay_Log_File: relay-bin.000002                Relay_Log_Pos: 537        Relay_Master_Log_File: master1-bin.000005             Slave_IO_Running: Yes            Slave_SQL_Running: Yes              Replicate_Do_DB:                ..........                ..........

雙主測試：

(1)在Master1上建立數據庫 testdb: MariaDB [(none)]> CREATE DATABASE testdb; MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database           | +--------------------+ | information_schema | | mysql              | | performance_schema | | test               | | testdb            | +--------------------+ 在Master2上查看結果與在Master1上所查得結果同樣！ (2)在Master1上建立數據庫 mydb: MariaDB [(none)]> SHOW DATABASES; +--------------------+ | Database           | +--------------------+ | information_schema | | mydb               | | mysql              | | performance_schema | | test               | | testdb             | +--------------------+ 在Master1上查看結果與在Master2上所查得結果同樣！ (3)在Master1的mydb上面新建一張表mytable1,並插入語句 MariaDB [(none)]> use mydb MariaDB [mydb]> CREATE TABLE mytable1 (ID INT AUTO_INCREMENT UNIQUE KEY, Name CHAR(20)); MariaDB [mydb]> DESC mytable1; +-------+----------+------+-----+---------+----------------+ | Field | Type     | Null | Key | Default | Extra          | +-------+----------+------+-----+---------+----------------+ | ID    | int(11)  | NO   | PRI | NULL    | auto_increment | | Name  | char(20) | YES  |     | NULL    |                | +-------+----------+------+-----+---------+----------------+ MariaDB [mydb]> INSERT INTO mytable1(Name) VALUES ('larry'),('jim'),('jerry'); Query OK, 3 rows affected (0.01 sec) Records: 3  Duplicates: 0  Warnings: 0 MariaDB [mydb]> SELECT * FROM mytable1; +----+-------+ | ID | Name  | +----+-------+ |  1 | larry|  //自動增加的效果,在Master1上定義的起始值爲1,步徑爲2 |  3| jim  | |  5 | jerry| +----+-------+ 在Master2上面插入字段(以上內容已經同步到Master2) MariaDB [mydb]>INSERT INTO mytable1(Name) VALUES ('Zhang San'),('Li Si'),('Wang Wu'); MariaDB [mydb]> SELECT * FROM mytable1; +----+-----------+ | ID | Name      | +----+-----------+ |  1 | larry     | |  3 | jim      | |  5 | jerry     | |  6 | Zhang San | |  8 | Li Si     | | 10 | Wang Wu   | +----+-----------+ //看來不是想要的結果,雖說MySQL自動爲INSERT選擇的值不會再出現互相沖突的狀況,可是貌似沒有按數字排序,找不到解決這個問題的辦法,除非不選擇用雙主模式！

4.三、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具備容錯和高可用性的系統。它的不一樣點在於其中一個服務只能進行只讀操做。如圖：

4.4 級聯複製架構 Master –Slaves - Slaves

在有些應用場景中，可能讀寫壓力差異比較大，讀壓力特別的大，一個Master可能須要上10臺甚至更多的Slave纔可以支撐注讀的壓力。這時候，Master就會比較吃力了，由於僅僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點的時候，Master端由於複製就會消耗較多的資源，很容易形成複製的延時。

遇到這種狀況如何解決呢？這時候咱們就能夠利用MySQL能夠在Slave端記錄複製所產生變動的BinaryLog信息的功能，也就是打開—log-slave-update選項。而後，經過二級（或者是更多級別）複製來減小Master端由於複製所帶來的壓力。也就是說，咱們首先經過少數幾臺MySQL從Master來進行復制，這幾臺機器咱們姑且稱之爲第一級Slave集羣，而後其餘的Slave再從第一級Slave集羣來進行復制。從第一級Slave進行復制的Slave，我稱之爲第二級Slave集羣。若是有須要，咱們能夠繼續往下增長更多層次的複製。這樣，咱們很容易就控制了每一臺MySQL上面所附屬Slave的數量。這種架構我稱之爲Master-Slaves-Slaves架構

這種多層級聯複製的架構，很容易就解決了Master端由於附屬Slave太多而成爲瓶頸的風險。下圖展現了多層級聯複製的Replication架構。

固然，若是條件容許，我更傾向於建議你們經過拆分紅多個Replication集羣來解決

上述瓶頸問題。畢竟Slave並無減小寫的量，全部Slave實際上仍然仍是應用了全部的數據變動操做，沒有減小任何寫IO。相反，Slave越多，整個集羣的寫IO總量也就會越多，咱們沒有很是明顯的感受，僅僅只是由於分散到了多臺機器上面，因此不是很容易表現出來。

此外，增長複製的級聯層次，同一個變動傳到最底層的Slave所須要通過的MySQL也會更多，一樣可能形成延時較長的風險。而若是咱們經過分拆集羣的方式來解決的話，可能就會要好不少了，固然，分拆集羣也須要更復雜的技術和更復雜的應用系統架構。

4.五、帶從服務器的Master-Master結構(Master-Master with Slaves)

這種結構的優勢就是提供了冗餘。在地理上分佈的複製結構，它不存在單一節點故障問題，並且還能夠將讀密集型的請求放到slave上。

級聯複製在必定程度上面確實解決了Master由於所附屬的Slave過多而成爲瓶頸的問題，可是他並不能解決人工維護和出現異常須要切換後可能存在從新搭建Replication的問題。這樣就很天然的引伸出了DualMaster與級聯複製結合的Replication架構，我稱之爲Master-Master-Slaves架構

和Master-Slaves-Slaves架構相比，區別僅僅只是將第一級Slave集羣換成了一臺單獨的Master，做爲備用Master，而後再從這個備用的Master進行復制到一個Slave集羣。

這種DualMaster與級聯複製結合的架構，最大的好處就是既能夠避免主Master的寫入操做不會受到Slave集羣的複製所帶來的影響，同時主Master須要切換的時候也基本上不會出現重搭Replication的狀況。可是，這個架構也有一個弊端，那就是備用的Master有可能成爲瓶頸，由於若是後面的Slave集羣比較大的話，備用Master可能會由於過多的SlaveIO線程請求而成爲瓶頸。固然，該備用Master不提供任何的讀服務的時候，瓶頸出現的可能性並非特別高，若是出現瓶頸，也能夠在備用Master後面再次進行級聯複製，架設多層Slave集羣。固然，級聯複製的級別越多，Slave集羣可能出現的數據延時也會更爲明顯，因此考慮使用多層級聯複製以前，也須要評估數據延時對應用系統的影響。