?

• 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上過濾中繼日志中的事件。如下：

  

  ?

  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ù)庫瓶頸。

  如下：

  

  如果寫操作較少，而讀操作很時，可以采取這種結(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ù)制的情形了。如圖：

  

  主動的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ù)只能進行只讀操作。如圖：

  ?

  

  ?

  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)。

  

  當然，如果條件允許，我更傾向于建議大家通過拆分成多個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上。

  

  級聯(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ù)制原理及主從/雙主配置詳解(一)

?