緊接上篇博文《MariaDB/Mysql之主從架構的複製原理及主從/雙主配置詳解(一)》
3.深入瞭解複製
3.1、基於語句的複製(Statement-Based Replication)
這種方式的優點就是實現簡單。此外，基於語句的複製的二進制日誌可以很好的進行壓縮，而且日誌的數據量也較小，佔用帶寬少——例如，一個更新GB的數據的查詢僅需要幾十個字節的二進制日誌。而mysqlbinlog對於基於語句的日誌處理十分方便。
但是，基於語句的複製並不是像它看起來那麼簡單，因爲一些查詢語句依賴於master的特定條件，例如，master與slave可能有不同的時間。所以，MySQL的二進制日誌的格式不僅僅是查詢語句，還包括一些元數據信息，例如，當前的時間戳。即使如此，還是有一些語句，比如，CURRENT USER函數，不能正確的進行復制。此外，存儲過程和觸發器也是一個問題。
另外一個問題就是基於語句的複製必須是串行化的。這要求大量特殊的代碼，配置，例如InnoDB的next-key鎖等。並不是所有的存儲引擎都支持基於語句的複製。
3.2、基於記錄的複製(Row-Based Replication)
對於一些語句，基於記錄的複製能夠更有效的工作，如：
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
(2)mysql-relay-bin.index
(3)master.info
(4)relay-log.info
3.4、發送複製事件到其它slave
當設置log_slave_updates時，你可以讓slave扮演其它slave的master。此時，slave把SQL線程執行的事件寫進行自己的二進制日誌(binary log)，然後，它的slave可以獲取這些事件並執行它。如下：
3.5、複製過濾(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.1、單一master和多slave
在實際應用場景中，MySQL複製90%以上都是一個Master複製到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因爲只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步複製的延時一般都很少很少。尤其是自從Slave端的複製方式改成兩個線程處理之後，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別Critical的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多臺Slave的機器上面，即可通過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
如下：
這種結構雖然簡單，但是，它卻非常靈活，足夠滿足大多數應用需求。一些建議：
(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)
在第一個服務器上執行：
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的配置：
| server-id = 1 |
主配置文件/etc/my.cnf [mysqld]段中,修改如下行：
log-bin = /mydata/binlogs/master1-bin relay-log = /mydata/relaylogs/relay-bin 確保中繼日誌選項開啓 MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'relay_log'; |
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#
| server-id = 2 |
log-bin = /mydata/binlogs/master2-bin relay-log = /mydata/relaylogs/relay-bin 確保中繼日誌選項開啓 MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'relay_log'; |
(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的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在於其中一個服務只能進行只讀操作。如圖：
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.5、帶從服務器的Master-Master結構(Master-Master with Slaves)
級聯複製在一定程度上面確實解決了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集羣可能出現的數據延時也會更爲明顯，所以考慮使用多層級聯複製之前，也需要評估數據延時對應用系統的影響。