3.深入了解復(fù)制

3.1、基于語句的復(fù)制(Statement-Based Replication)MySQL 5.0及之前的版本僅支持基于語句的復(fù)制（也叫做邏輯復(fù)制，logical replication），這在數(shù)據(jù)庫并不常見。master記錄下改變數(shù)據(jù)的查詢，然后，slave從中繼日志中讀取事件，并執(zhí)行它，這些SQL語句與master執(zhí)行的語句一樣。這種方式的優(yōu)點(diǎn)就是實(shí)現(xiàn)簡單。此外，基于語句的復(fù)制的二進(jìn)制日志可以很好的進(jìn)行壓縮，而且日志的數(shù)據(jù)量也較小，占用帶寬少——例如，一個(gè)更新GB的數(shù)據(jù)的查詢僅需要幾十個(gè)字節(jié)的二進(jìn)制日志。而mysqlbinlog對(duì)于基于語句的日志處理十分方便。但是，基于語句的復(fù)制并不是像它看起來那么簡單，因?yàn)橐恍┎樵冋Z句依賴于master的特定條件，例如，master與slave可能有不同的時(shí)間。所以，MySQL的二進(jìn)制日志的格式不僅僅是查詢語句，還包括一些元數(shù)據(jù)信息，例如，當(dāng)前的時(shí)間戳。即使如此，還是有一些語句，比如，CURRENT USER函數(shù)，不能正確的進(jìn)行復(fù)制。此外，存儲(chǔ)過程和觸發(fā)器也是一個(gè)問題。另外一個(gè)問題就是基于語句的復(fù)制必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。并不是所有的存儲(chǔ)引擎都支持基于語句的復(fù)制。

3.2、基于記錄的復(fù)制(Row-Based Replication) MySQL增加基于記錄的復(fù)制，在二進(jìn)制日志中記錄下實(shí)際數(shù)據(jù)的改變，這與其它一些DBMS的實(shí)現(xiàn)方式類似。這種方式有優(yōu)點(diǎn)，也有缺點(diǎn)。優(yōu)點(diǎn)就是可以對(duì)任何語句都能正確工作，一些語句的效率更高。主要的缺點(diǎn)就是二進(jìn)制日志可能會(huì)很大，而且不直觀，所以，你不能使用mysqlbinlog來查看二進(jìn)制日志。對(duì)于一些語句，基于記錄的復(fù)制能夠更有效的工作，如：mysql> INSERT INTO summary_table(col1, col2, sum_col3) -> SELECT col1, col2, sum(col3) -> FROM enormous_table -> GROUP BY col1, col2; 假設(shè)，只有三種唯一的col1和col2的組合，但是，該查詢會(huì)掃描原表的許多行，卻僅返回三條記錄。此時(shí)，基于記錄的復(fù)制效率更高。另一方面，下面的語句，基于語句的復(fù)制更有效： mysql> UPDATE enormous_table SET col1 = 0;此時(shí)使用基于記錄的復(fù)制代價(jià)會(huì)非常高。由于兩種方式不能對(duì)所有情況都能很好的處理，所以，MySQL 5.1支持在基于語句的復(fù)制和基于記錄的復(fù)制之前動(dòng)態(tài)交換。你可以通過設(shè)置session變量binlog_format來進(jìn)行控制。

3.3、復(fù)制相關(guān)的文件除了二進(jìn)制日志和中繼日志文件外，還有其它一些與復(fù)制相關(guān)的文件。如下：

(1)mysql-bin.index服務(wù)器一旦開啟二進(jìn)制日志，會(huì)產(chǎn)生一個(gè)與二日志文件同名，但是以.index結(jié)尾的文件。它用于跟蹤磁盤上存在哪些二進(jìn)制日志文件。MySQL用它來定位二進(jìn)制日志文件。

(2)mysql-relay-bin.index該文件的功能與mysql-bin.index類似，但是它是針對(duì)中繼日志，而不是二進(jìn)制日志。

(3)master.info保存從服務(wù)器連接至主服務(wù)時(shí)所需要的信息，每行一個(gè)值保存master的相關(guān)信息。不要?jiǎng)h除它，否則，slave重啟后不能連接master。

(4)relay-log.info 保存了復(fù)制位置：包括二進(jìn)制日志和中繼日志的文件及位置。

3.4、發(fā)送復(fù)制事件到其它slave

當(dāng)設(shè)置log_slave_updates時(shí)，你可以讓slave扮演其它slave的master。此時(shí)，slave把SQL線程執(zhí)行的事件寫進(jìn)行自己的二進(jìn)制日志(binary log)，然后，它的slave可以獲取這些事件并執(zhí)行它。如下：

QTlBTWGdZZUFBR09GMUtqaHNVMTI0LmpwZw==" border="0" height="349" hspace="0" src="http://www.it165.net/uploadfile/files/2014/0419/201404190833212.jpg" title="yyyy.jpg" vspace="0" width="733" />

3.5、復(fù)制過濾(Replication Filters)

復(fù)制過濾可以讓你只復(fù)***務(wù)器中的一部分?jǐn)?shù)據(jù)，有兩種復(fù)制過濾：在master上過濾二進(jìn)制日志中的事件；在slave上過濾中繼日志中的事件。如下：

4.復(fù)制的常用拓?fù)浣Y(jié)構(gòu)復(fù)制的體系結(jié)構(gòu)有以下一些基本原則：(1)每個(gè)slave可以有一個(gè)或多個(gè)master；(2)每個(gè)slave只能有一個(gè)唯一的服務(wù)器ID；(3)每個(gè)master可以有很多slave；(4)如果設(shè)置log_slave_updates，slave可以是其它slave的master，從而擴(kuò)散master的更新。

在早期的 MySQL 是不支持多主服務(wù)器復(fù)制(Multimaster Replication)——即一個(gè)slave可以有多個(gè)master的場(chǎng)景,但是MariaDB目前已經(jīng)支持。但是，通過一些簡單的組合，我們卻可以建立靈活而強(qiáng)大的復(fù)制體系結(jié)構(gòu)。

4.1、單一master和多slave由一個(gè)master和一個(gè)slave組成復(fù)制系統(tǒng)是最簡單的情況。Slave之間并不相互通信，只能與master進(jìn)行通信。

在實(shí)際應(yīng)用場(chǎng)景中， MySQL 復(fù)制90%以上都是一個(gè)Master復(fù)制到一個(gè)或者多個(gè)Slave的架構(gòu)模式，主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫端廉價(jià)擴(kuò)展解決方案。因?yàn)橹灰狹aster和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復(fù)制的延時(shí)一般都很少很少。尤其是自從Slave端的復(fù)制方式改成兩個(gè)線程處理之后，更是減小了Slave端的延時(shí)問題。而帶來的效益是，對(duì)于數(shù)據(jù)實(shí)時(shí)性要求不是特別Critical的應(yīng)用，只需要通過廉價(jià)的pcserver來擴(kuò)展Slave的數(shù)量，將讀壓力分散到多臺(tái)Slave的機(jī)器上面，即可通過分散單臺(tái)數(shù)據(jù)庫服務(wù)器的讀壓力來解決數(shù)據(jù)庫端的讀性能瓶頸，畢竟在大多數(shù)數(shù)據(jù)庫應(yīng)用系統(tǒng)中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫壓力瓶頸問題，甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫瓶頸。

如下：

如果寫操作較少，而讀操作很時(shí)，可以采取這種結(jié)構(gòu)。你可以將讀操作分布到其它的slave，從而減小master的壓力。但是，當(dāng)slave增加到一定數(shù)量時(shí)，slave對(duì)master的負(fù)載以及網(wǎng)絡(luò)帶寬都會(huì)成為一個(gè)嚴(yán)重的問題。這種結(jié)構(gòu)雖然簡單，但是，它卻非常靈活，足夠滿足大多數(shù)應(yīng)用需求。一些建議：(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存儲(chǔ)引擎)；(2) 用一個(gè)slave作為備用master，只進(jìn)行復(fù)制；(3) 用一個(gè)遠(yuǎn)程的slave，用于災(zāi)難恢復(fù)；

大家應(yīng)該都比較清楚，從一個(gè)Master節(jié)點(diǎn)可以復(fù)制出多個(gè)Slave節(jié)點(diǎn)，可能有人會(huì)想，那一個(gè)Slave節(jié)點(diǎn)是否可以從多個(gè)Master節(jié)點(diǎn)上面進(jìn)行復(fù)制呢？這是完全可以實(shí)現(xiàn)的,目前在MariaDB中已經(jīng)實(shí)現(xiàn)multi-master replication 功能;可參考《MariaDB多源(主)復(fù)制》

4.2、主動(dòng)模式的Master-Master(Master-Master in Active-Active Mode)Master-Master復(fù)制的兩臺(tái)服務(wù)器，既是master，又是另一臺(tái)服務(wù)器的slave。這樣，任何一方所做的變更，都會(huì)通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。可能有些讀者朋友會(huì)有一個(gè)擔(dān)心，這樣搭建復(fù)制環(huán)境之后，難道不會(huì)造成兩臺(tái)MySQL之間的循環(huán)復(fù)制么？實(shí)際上MySQL自己早就想到了這一點(diǎn)，所以在MySQL的BinaryLog中記錄了當(dāng)前MySQL的server-id，而且這個(gè)參數(shù)也是我們搭建MySQLReplication的時(shí)候必須明確指定，而且Master和Slave的server-id參數(shù)值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判斷某個(gè)變更是從哪一個(gè)MySQLServer最初產(chǎn)生的，所以就很容易避免出現(xiàn)循環(huán)復(fù)制的情況。而且，如果我們不打開記錄Slave的BinaryLog的選項(xiàng)（--log-slave-update）的時(shí)候，MySQL根本就不會(huì)記錄復(fù)制過程中的變更到BinaryLog中，就更不用擔(dān)心可能會(huì)出現(xiàn)循環(huán)復(fù)制的情形了。如圖：

主動(dòng)的Master-Master復(fù)制有一些特殊的用處。例如，地理上分布的兩個(gè)部分都需要自己的可寫的數(shù)據(jù)副本。這種結(jié)構(gòu)最大的問題就是更新沖突。假設(shè)一個(gè)表只有一行(一列)的數(shù)據(jù)，其值為1，如果兩個(gè)服務(wù)器分別同時(shí)執(zhí)行如下語句：在第一個(gè)服務(wù)器上執(zhí)行：mysql> UPDATE tbl SET col=col + 1;在第二個(gè)服務(wù)器上執(zhí)行：mysql> UPDATE tbl SET col=col * 2;那么結(jié)果是多少呢？一臺(tái)服務(wù)器是4，另一個(gè)服務(wù)器是3，但是，這并不會(huì)產(chǎn)生錯(cuò)誤。

實(shí)際上，MySQL并不支持其它一些DBMS支持的多主服務(wù)器復(fù)制(Multimaster Replication)，這是MySQL的復(fù)制功能很大的一個(gè)限制(多主服務(wù)器的難點(diǎn)在于解決更新沖突)，但是，如果你實(shí)在有這種需求，你可以采用MySQL Cluster，以及將Cluster和Replication結(jié)合起來，可以建立強(qiáng)大的高性能的數(shù)據(jù)庫平臺(tái)。但是，可以通過其它一些方式來模擬這種多主服務(wù)器的復(fù)制。

示例:雙主模式配置 :

環(huán)境：

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)啟用中繼日志,二進(jìn)制日志

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

log-bin = /mydata/binlogs/master1-bin

relay-log = /mydata/relaylogs/relay-bin

確保中繼日志選項(xiàng)開啟

(3)添加下面兩項(xiàng),以避免在MySQL自動(dòng)為INSERT語句選擇不互相沖突的值

auto-increment-offset = 1 //起始值

auto-increment-increment = 2 //步長

確保自動(dòng)增長選項(xiàng)已開啟：

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%';

+--------------------------+-------+

| Variable_name | Value |

+--------------------------+-------+

| auto_increment_increment | 2 |

| auto_increment_offset | 1 |

+--------------------------+-------+

?

(4)創(chuàng)建有復(fù)制權(quán)限的用戶,命令如下：

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)啟用中繼日志,二進(jìn)制日志

log-bin = /mydata/binlogs/master2-bin

relay-log = /mydata/relaylogs/relay-bin

確保中繼日志選項(xiàng)開啟

(3)添加下面兩項(xiàng),以避免在MySQL自動(dòng)為INSERT語句選擇不互相沖突的值

auto-increment-offset = 2 //起始值

auto-increment-increment = 2 //步長

確保自動(dòng)增長選項(xiàng)已開啟：

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'auto_inc%';

+--------------------------+-------+

| Variable_name | Value |

+--------------------------+-------+

| auto_increment_increment | 2 |

| auto_increment_offset | 2 |

+--------------------------+-------+

(4)創(chuàng)建有復(fù)制權(quán)限的用戶,命令如下：

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;

如果此時(shí)兩臺(tái)服務(wù)器均為新建立，且無其它寫入操作，各服務(wù)器只需記錄當(dāng)前自己二進(jìn)制日志文件及事件位置，以之作為另外的服務(wù)器復(fù)制起始位置即可

#Master1:

MariaDB [(none)]> SHOW MASTER STATUS;

+--------------------+----------+--------------+------------------+

+--------------------+----------+--------------+------------------+

| master1-bin.000001 | 969 | | |

+--------------------+----------+--------------+------------------+

#Master2:

MariaDB [(none)]> SHOW MASTER STATUS;

+--------------------+----------+--------------+------------------+

+--------------------+----------+--------------+------------------+

| master2-bin.000001 | 314 | | |

+--------------------+----------+--------------+------------------+

各服務(wù)器接下來指定對(duì)另一臺(tái)服務(wù)器為自己的主服務(wù)器

#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;

啟動(dòng)個(gè)服務(wù)器復(fù)制進(jìn)程

#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:

.......... ..........

雙主測(cè)試：

(1)在Master1上創(chuàng)建數(shù)據(jù)庫 testdb:

MariaDB [(none)]> CREATE DATABASE testdb;

MariaDB [(none)]> SHOW DATABASES;

+--------------------+

| Database |

+--------------------+

| information_schema |

| mysql |

| performance_schema |

| test |

| testdb |

+--------------------+

在Master2上查看結(jié)果與在Master1上所查得結(jié)果一樣！

(2)在Master1上創(chuàng)建數(shù)據(jù)庫 mydb:

MariaDB [(none)]> SHOW DATABASES;

+--------------------+

| Database |

+--------------------+

| information_schema |

| mydb |

| mysql |

| performance_schema |

| test |

| testdb |

+--------------------+

在Master1上查看結(jié)果與在Master2上所查得結(jié)果一樣！

(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;

+-------+----------+------+-----+---------+----------------+

+-------+----------+------+-----+---------+----------------+

| 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| //自動(dòng)增長的效果,在Master1上定義的起始值為1,步徑為2

| 3 | jim |

| 5 | jerry|

+----+-------+

在Master2上面插入字段(以上內(nèi)容已經(jīng)同步到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 |

+----+-----------+

//看來不是想要的結(jié)果,雖然說MySQL自動(dòng)為INSERT選擇的值不會(huì)再出現(xiàn)互相沖突的情況,但是貌似沒有按數(shù)字排序,找不到解決這個(gè)問題的辦法,除非不選擇用雙主模式！

4.3、主動(dòng)-被動(dòng)模式的Master-Master(Master-Master in Active-Passive Mode)

這是master-master結(jié)構(gòu)變化而來的，它避免了M-M的缺點(diǎn)，實(shí)際上，這是一種具有容錯(cuò)和高可用性的系統(tǒng)。它的不同點(diǎn)在于其中一個(gè)服務(wù)只能進(jìn)行只讀操作。如圖：

?

4.4 級(jí)聯(lián)復(fù)制架構(gòu) Master –Slaves - Slaves

在有些應(yīng)用場(chǎng)景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個(gè)Master可能需要上10臺(tái)甚至更多的Slave才能夠支撐注讀的壓力。這時(shí)候，Master就會(huì)比較吃力了，因?yàn)閮H僅連上來的SlaveIO線程就比較多了，這樣寫的壓力稍微大一點(diǎn)的時(shí)候，Master端因?yàn)閺?fù)制就會(huì)消耗較多的資源，很容易造成復(fù)制的延時(shí)。

遇到這種情況如何解決呢？這時(shí)候我們就可以利用MySQL可以在Slave端記錄復(fù)制所產(chǎn)生變更的BinaryLog信息的功能，也就是打開—log-slave-update選項(xiàng)。然后，通過二級(jí)（或者是更多級(jí)別）復(fù)制來減少M(fèi)aster端因?yàn)閺?fù)制所帶來的壓力。也就是說，我們首先通過少數(shù)幾臺(tái)MySQL從Master來進(jìn)行復(fù)制，這幾臺(tái)機(jī)器我們姑且稱之為第一級(jí)Slave集群，然后其他的Slave再從第一級(jí)Slave集群來進(jìn)行復(fù)制。從第一級(jí)Slave進(jìn)行復(fù)制的Slave，我稱之為第二級(jí)Slave集群。如果有需要，我們可以繼續(xù)往下增加更多層次的復(fù)制。這樣，我們很容易就控制了每一臺(tái)MySQL上面所附屬Slave的數(shù)量。這種架構(gòu)我稱之為Master-Slaves-Slaves架構(gòu)

這種多層級(jí)聯(lián)復(fù)制的架構(gòu)，很容易就解決了Master端因?yàn)楦綄賁lave太多而成為瓶頸的風(fēng)險(xiǎn)。下圖展示了多層級(jí)聯(lián)復(fù)制的Replication架構(gòu)。

當(dāng)然，如果條件允許，我更傾向于建議大家通過拆分成多個(gè)Replication集群來解決

上述瓶頸問題。畢竟Slave并沒有減少寫的量，所有Slave實(shí)際上仍然還是應(yīng)用了所有的數(shù)據(jù)變更操作，沒有減少任何寫IO。相反，Slave越多，整個(gè)集群的寫IO總量也就會(huì)越多，我們沒有非常明顯的感覺，僅僅只是因?yàn)榉稚⒌搅硕嗯_(tái)機(jī)器上面，所以不是很容易表現(xiàn)出來。

此外，增加復(fù)制的級(jí)聯(lián)層次，同一個(gè)變更傳到最底層的Slave所需要經(jīng)過的MySQL也會(huì)更多，同樣可能造成延時(shí)較長的風(fēng)險(xiǎn)。而如果我們通過分拆集群的方式來解決的話，可能就會(huì)要好很多了，當(dāng)然，分拆集群也需要更復(fù)雜的技術(shù)和更復(fù)雜的應(yīng)用系統(tǒng)架構(gòu)。

4.5、帶從服務(wù)器的Master-Master結(jié)構(gòu)(Master-Master with Slaves)這種結(jié)構(gòu)的優(yōu)點(diǎn)就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu)，它不存在單一節(jié)點(diǎn)故障問題，而且還可以將讀密集型的請(qǐng)求放到slave上。

級(jí)聯(lián)復(fù)制在一定程度上面確實(shí)解決了Master因?yàn)樗綄俚腟lave過多而成為瓶頸的問題，但是他并不能解決人工維護(hù)和出現(xiàn)異常需要切換后可能存在重新搭建Replication的問題。這樣就很自然的引申出了DualMaster與級(jí)聯(lián)復(fù)制結(jié)合的Replication架構(gòu)，我稱之為Master-Master-Slaves架構(gòu)

和Master-Slaves-Slaves架構(gòu)相比，區(qū)別僅僅只是將第一級(jí)Slave集群換成了一臺(tái)單獨(dú)的Master，作為備用Master，然后再從這個(gè)備用的Master進(jìn)行復(fù)制到一個(gè)Slave集群。

這種DualMaster與級(jí)聯(lián)復(fù)制結(jié)合的架構(gòu)，最大的好處就是既可以避免主Master的寫入操作不會(huì)受到Slave集群的復(fù)制所帶來的影響，同時(shí)主Master需要切換的時(shí)候也基本上不會(huì)出現(xiàn)重搭Replication的情況。但是，這個(gè)架構(gòu)也有一個(gè)弊端，那就是備用的Master有可能成為瓶頸，因?yàn)槿绻竺娴腟lave集群比較大的話，備用Master可能會(huì)因?yàn)檫^多的SlaveIO線程請(qǐng)求而成為瓶頸。當(dāng)然，該備用Master不提供任何的讀服務(wù)的時(shí)候，瓶頸出現(xiàn)的可能性并不是特別高，如果出現(xiàn)瓶頸，也可以在備用Master后面再次進(jìn)行級(jí)聯(lián)復(fù)制，架設(shè)多層Slave集群。當(dāng)然，級(jí)聯(lián)復(fù)制的級(jí)別越多，Slave集群可能出現(xiàn)的數(shù)據(jù)延時(shí)也會(huì)更為明顯，所以考慮使用多層級(jí)聯(lián)復(fù)制之前，也需要評(píng)估數(shù)據(jù)延時(shí)對(duì)應(yīng)用系統(tǒng)的影響。

延伸閱讀：

? MariaDB/Mysql之主從架構(gòu)的復(fù)制原理及主從/雙主配置詳解(一)

MariaDB/Mysql之主從架構(gòu)的復(fù)制原理及主從/雙主配置詳解(二)

更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主

微信掃碼或搜索：z360901061

微信掃一掃加我為好友

QQ號(hào)聯(lián)系： 360901061

您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。

【本文對(duì)您有幫助就好】元

2元

5元

10元

20元

自定義