亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

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

系統(tǒng) 1854 0

?

  • 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)點就是實現(xiàn)簡單。此外,基于語句的復(fù)制的二進制日志可以很好的進行壓縮,而且日志的數(shù)據(jù)量也較小,占用帶寬少——例如,一個更新GB的數(shù)據(jù)的查詢僅需要幾十個字節(jié)的二進制日志。而mysqlbinlog對于基于語句的日志處理十分方便。 但是,基于語句的復(fù)制并不是像它看起來那么簡單,因為一些查詢語句依賴于master的特定條件,例如,master與slave可能有不同的時間。所以,MySQL的二進制日志的格式不僅僅是查詢語句,還包括一些元數(shù)據(jù)信息,例如,當前的時間戳。即使如此,還是有一些語句,比如,CURRENT USER函數(shù),不能正確的進行復(fù)制。此外,存儲過程和觸發(fā)器也是一個問題。 另外一個問題就是基于語句的復(fù)制必須是串行化的。這要求大量特殊的代碼,配置,例如InnoDB的next-key鎖等。并不是所有的存儲引擎都支持基于語句的復(fù)制。

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

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

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

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

    (3)master.info保存從服務(wù)器連接至主服務(wù)時所需要的信息,每行一個值保存master的相關(guān)信息。不要刪除它,否則,slave重啟后不能連接master。

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

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

    當設(shè)置log_slave_updates時,你可以讓slave扮演其它slave的master。此時,slave把SQL線程執(zhí)行的事件寫進行自己的二進制日志(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ù)器中的一部分數(shù)據(jù),有兩種復(fù)制過濾:在master上過濾二進制日志中的事件;在slave上過濾中繼日志中的事件。如下:

    wKioL1NOPYSwF1NvAAF4FoH_Luk325.jpg

    ?

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

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

    ?

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

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

    如下:

    wKiom1NOQB6wKpInAACPFzueKiI373.jpg

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

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

    ?

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

    wKioL1NOP_SAmSANAABJisdmItQ735.jpg

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

    實際上,MySQL并不支持其它一些DBMS支持的多主服務(wù)器復(fù)制(Multimaster Replication),這是MySQL的復(fù)制功能很大的一個限制(多主服務(wù)器的難點在于解決更新沖突),但是,如果你實在有這種需求,你可以采用MySQL Cluster,以及將Cluster和Replication結(jié)合起來,可以建立強大的高性能的數(shù)據(jù)庫平臺。但是,可以通過其它一些方式來模擬這種多主服務(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)啟用中繼日志,二進制日志

    主配置文件/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)創(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)啟用中繼日志,二進制日志

    ?

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

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

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

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

    各服務(wù)器接下來指定對另一臺服務(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;

    啟動個服務(wù)器復(fù)制進程

    #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上創(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;

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

    | 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上面插入字段(以上內(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自動為INSERT選擇的值不會再出現(xiàn)互相沖突的情況,但是貌似沒有按數(shù)字排序,找不到解決這個問題的辦法,除非不選擇用雙主模式!

    ?

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

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

    ?

    wKiom1NRQvyD4Q1dAABIsY-WKGc195.jpg

    ?

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

    在有些應(yīng)用場景中,可能讀寫壓力差別比較大,讀壓力特別的大,一個Master可能需要上10臺甚至更多的Slave才能夠支撐注讀的壓力。這時候,Master就會比較吃力了,因為僅僅連上來的SlaveIO線程就比較多了,這樣寫的壓力稍微大一點的時候,Master端因為復(fù)制就會消耗較多的資源,很容易造成復(fù)制的延時。

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

    這種多層級聯(lián)復(fù)制的架構(gòu),很容易就解決了Master端因為附屬Slave太多而成為瓶頸的風險。下圖展示了多層級聯(lián)復(fù)制的Replication架構(gòu)。

    wKiom1NRQv6RNnTtAAEAh7azRwo469.jpg

    當然,如果條件允許,我更傾向于建議大家通過拆分成多個Replication集群來解決

    上述瓶頸問題。畢竟Slave并沒有減少寫的量,所有Slave實際上仍然還是應(yīng)用了所有的數(shù)據(jù)變更操作,沒有減少任何寫IO。相反,Slave越多,整個集群的寫IO總量也就會越多,我們沒有非常明顯的感覺,僅僅只是因為分散到了多臺機器上面,所以不是很容易表現(xiàn)出來。

    此外,增加復(fù)制的級聯(lián)層次,同一個變更傳到最底層的Slave所需要經(jīng)過的MySQL也會更多,同樣可能造成延時較長的風險。而如果我們通過分拆集群的方式來解決的話,可能就會要好很多了,當然,分拆集群也需要更復(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)點就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu),它不存在單一節(jié)點故障問題,而且還可以將讀密集型的請求放到slave上。

    wKioL1NRQtPwj73_AACDaBTeaWw819.jpg

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

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

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

延伸閱讀:

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

?

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


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

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯(lián)系: 360901061

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

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦?。。?/p>

發(fā)表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 色综合亚洲七七久久桃花影院 | 日韩中文字幕免费观看 | 欧洲一级毛片免费 | 一区二区三区在线观看免费 | 91热国内精品永久免费观看 | 天天做天天添天天谢 | 九九九九热 | 一本大道香蕉中文在线高清 | 国产日产久久 | 91国内在线观看 | 手机看一级片 | 欧美综合国产 | 国产极品嫩模大尺度福利视频 | 国产亚洲欧美精品久久久 | 青青青爽在线视频观看 | 日本精品一区二区三本中文 | 成人特级毛片69免费观看 | 日韩欧美亚洲国产精品字幕久久久 | 成年黄网站免费大全毛片 | 中文字幕日韩哦哦哦 | 国产激情视频一区二区三区 | 欧美日韩亚洲精品一区二区三区 | 国产成人免费高清视频 | 不卡一区二区在线观看 | 国产精品美女 | 午夜伦情电午夜伦情影院 | 一级毛片毛片毛片毛毛片 | 久久婷婷人人澡人人爱91 | 欧美一级精品高清在线观看 | 日韩久久中文字幕 | 四虎影院视频 | 亚洲国产第一区二区三区 | 欧美一级高清免费a | 精品综合久久久久久97超人该 | 野花成人 | 亚洲一二区视频 | 91高清在线成人免费观看 | 九九热在线视频观看 | 久久精品99成人中文字幕880 | 91精品视频免费观看 | 夜夜操夜夜摸 |