MySQL主從和雙主架構的適用場景

MySQL主從和雙主架構對於大家來講有一些幫助了，在這裡我們來看一篇關於MySQL主從和雙主架構的適用場景的例子。

MySQL 主從架構的適用場景是讀寫分離，通過主庫寫，從庫讀，大多數場景是讀的情況比較多，單一 master 多 slave 的架構可以很好解決讀壓力大的問題。

MySQL 雙主架構的適用場景舉個例子，比如一個應用前台和後台用的不同的服務器，數據庫大多數是主從結構，但是日志數據庫，需要共用一個，這個時候可以把兩邊的日志數據庫設為雙主。

雙主數據庫一個特點是，在 A 數據庫上的任何操作，在 B 數據庫也進行了同樣的操作，反過來也是。還有一個現象可以發現，A，B 兩個數據庫插入數據的自增 ID 的遞增值一般都是 2，這是避免主鍵沖突。

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

3.2、基於記錄的復制(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.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.4、發送復制事件到其它slave
當設置log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行自己的二進制日志(binary log)，然後，它的slave可以獲取這些事件並執行它。如下：
wKioL1NOPNPSXgYeAAGOF1KjhsU124.jpg

3.5、復制過濾(Replication Filters)
復制過濾可以讓你只復***務器中的一部分數據，有兩種復制過濾：在master上過濾二進制日志中的事件；在slave上過濾中繼日志中的事件。如下：
wKioL1NOPYSwF1NvAAF4FoH_Luk325.jpg

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.1、單一master和多slave
由一個master和一個slave組成復制系統是最簡單的情況。Slave之間並不相互通信，只能與master進行通信。
在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之後，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多台Slave的機器上面，即可通過分散單台數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
如下：
wKiom1NOQB6wKpInAACPFzueKiI373.jpg
如果寫操作較少，而讀操作很時，可以采取這種結構。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當slave增加到一定數量時，slave對master的負載以及網絡帶寬都會成為一個嚴重的問題。
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
(1)    不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲引擎)；
(2)    用一個slave作為備用master，只進行復制；
(3)    用一個遠程的slave，用於災難恢復；
大家應該都比較清楚，從一個Master節點可以復制出多個Slave節點，可能有人會想，那一個Slave節點是否可以從多個Master節點上面進行復制呢？這是完全可以實現的,目前在MariaDB中已經實現multi-master replication 功能;可參考《MariaDB多源(主)復制》

4.2、主動模式的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中，就更不用擔心可能會出現循環復制的情形了。
如圖：
wKioL1NOP_SAmSANAABJisdmItQ735.jpg
   主動的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.3、主動-被動模式的Master-Master(Master-Master in Active-Passive Mode)
這是master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在於其中一個服務只能進行只讀操作。如圖：
wKiom1NRQvyD4Q1dAABIsY-WKGc195.jpg

 

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架構。
wKiom1NRQv6RNnTtAAEAh7azRwo469.jpg
當然，如果條件允許，我更傾向於建議大家通過拆分成多個Replication集群來解決
上述瓶頸問題。畢竟Slave並沒有減少寫的量，所有Slave實際上仍然還是應用了所有的數據變更操作，沒有減少任何寫IO。相反，Slave越多，整個集群的寫IO總量也就會越多，我們沒有非常明顯的感覺，僅僅只是因為分散到了多台機器上面，所以不是很容易表現出來。
此外，增加復制的級聯層次，同一個變更傳到最底層的Slave所需要經過的MySQL也會更多，同樣可能造成延時較長的風險。而如果我們通過分拆集群的方式來解決的話，可能就會要好很多了，當然，分拆集群也需要更復雜的技術和更復雜的應用系統架構。

4.5、帶從服務器的Master-Master結構(Master-Master with Slaves)
這種結構的優點就是提供了冗余。在地理上分布的復制結構，它不存在單一節點故障問題，而且還可以將讀密集型的請求放到slave上。
wKioL1NRQtPwj73_AACDaBTeaWw819.jpg
級聯復制在一定程度上面確實解決了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集群可能出現的數據延時也會更為明顯，所以考慮使用多層級聯復制之前，也需要評估數據延時對應用系統的影響。