mysql半同步複製&組複製&全同步機制
阿新 • • 發佈：2019-02-16
先配置好主從
配置主從詳見上一篇部落格，這裡只是簡單過一邊
mysql> grant replication slave on *.* to 'haha'@'172.25.53.%' identified by '[email protected]';
Query OK, 0 rows affected, 1 warning (0.00 sec)
Server2連結server1
mysql> change master to master_host='172.25.53.1',master_user='haha',master_password='[email protected] 然後更改server2配置檔案並重啟mysql
server-id=2
log-bin=mysql-bin
log-slave-updates
gtid_mode=ON
enforce_gtid_consistency=ON
“`
然後更改server2配置檔案並重啟mysql
server-id=2
log-bin=mysql-bin
log-slave-updates
gtid_mode=ON
enforce_gtid_consistency=ON
Server2釋出
mysql> grant replication slave on *.* to 'haha'@'172.25.53.%' identified by 
Server3連結server2
mysql> change master to master_host='172.25.53.2',master_user='haha',master_password='[email protected]', MASTER_AUTO_POSITION=1;
測試
在server1中新建一個庫
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.06 sec)
mysql> create database test;
Query OK, 1 row affected (0.08 sec)
mysql> use test;
Database changed
mysql> create table userlist(
-> username varchar(15) not null,
-> password varchar(25) not null);
Query OK, 0 rows affected (0.42 sec)
mysql> desc userlist;
+----------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| username | varchar(15) | NO | | NULL | |
| password | varchar(25) | NO | | NULL | |
+----------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
mysql> insert into userlist values ('user1','111');
Query OK, 1 row affected (0.65 sec)
mysql> insert into userlist values ('user2','222');
Query OK, 1 row affected (0.08 sec)
mysql> insert into userlist values ('user3','333');
Query OK, 1 row affected (0.17 sec)
Server2可以顯示
Server3也可以顯示
[root@server2 ~]# vim /etc/my.cnf
root@server2 ~]# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
準備工作做好，接下來就是半同步了
從MySQL5.5開始，MySQL以外掛的形式支援半同步複製。如何理解半同步呢？首先我們來看看非同步，全同步的概念
非同步複製（Asynchronous replication）
MySQL預設的複製即是非同步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的資料不完整。
全同步複製（Fully synchronous replication）
指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步複製的效能必然會收到嚴重的影響。
半同步複製（Semisynchronous replication）
介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於非同步複製，半同步複製提高了資料的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步複製最好在低延時的網路中使用。
半同步複製原理圖
半同步複製的潛在問題
客戶端事務在儲存引擎層提交後，在得到從庫確認的過程中，主庫宕機了，此時，可能的情況有兩種
事務還沒傳送到從庫上
此時，客戶端會收到事務提交失敗的資訊，客戶端會重新提交該事務到新的主上，當宕機的主庫重新啟動後，以從庫的身份重新加入到該主從結構中，會發現，該事務在從庫中被提交了兩次，一次是之前作為主的時候，一次是被新主同步過來的。
事務已經發送到從庫上
此時，從庫已經收到並應用了該事務，但是客戶端仍然會收到事務提交失敗的資訊，重新提交該事務到新的主上。
無資料丟失的半同步複製
針對上述潛在問題，MySQL 5.7引入了一種新的半同步方案：Loss-Less半同步複製。
針對上面這個圖，“Waiting Slave dump”被調整到“Storage Commit”之前。
當然，之前的半同步方案同樣支援，MySQL 5.7.2引入了一個新的引數進行控制-rpl_semi_sync_master_wait_point
rpl_semi_sync_master_wait_point有兩種取值
AFTER_SYNC
這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。
AFTER_COMMIT
老的半同步方案，如圖所示。半同步複製的安裝部署
要想使用半同步複製，必須滿足以下幾個條件：
MySQL 5.5及以上版本
變數have_dynamic_loading為YES
非同步複製已經存在
Server1 master
Server2 master slave
Server3 slave
首先安裝所需模組，並允許自啟
啟動半同步複製
在安裝完外掛後，半同步複製預設是關閉的，這時需設定引數來開啟半同步
主：
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
從：
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
以上的啟動方式是在命令列操作，也可寫在配置檔案中。
Server1 安裝master模組
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.10 sec)
mysql> set global rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
Server2安裝master模組和slave模組
mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.11 sec)
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.06 sec)
mysql> set global rpl_semi_sync_slave_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
mysql> set global rpl_semi_sync_master_enabled = 1;
Query OK, 0 rows affected (0.00 sec)
Server3 安裝slave模組
mysql> select plugin_name, plugin_status
-> from information_schema.plugins
-> where plugin_name like '%semi%';
重啟io介面使生效
mysql> stop slave io_thread;
Query OK, 0 rows affected (0.08 sec)
mysql> start slave io_thread;
Query OK, 0 rows affected (0.00 sec)
Server1顯示如下
mysql> show variables like 'rpl_semi_sync%';
Server2顯示如下
mysql> show variables like ‘rpl_semi_sync%’;
mysql> show status like ‘Rpl_semi_sync%’;
Server3顯示如下
插入
mysql> use test
Database changed
mysql> insert into userlist values ('user4','444');
Query OK, 1 row affected (0.08 sec)
mysql> insert into userlist values ('user5','555');
Query OK, 1 row affected (0.12 sec)
有幾個狀態改變了
Server3可顯示同步的資料
事實上，半同步複製並不是嚴格意義上的半同步複製
當半同步複製發生超時時（由rpl_semi_sync_master_timeout引數控制，單位是毫秒，預設為10000，即10s），會暫時關閉半同步複製，轉而使用非同步複製。當master dump執行緒傳送完一個事務的所有事件之後，如果在rpl_semi_sync_master_timeout內，收到了從庫的響應，則主從又重新恢復為半同步複製。
關掉server2的io介面，server1建立會有十秒的延遲（預設10s）
沒有io介面，資料庫肯定不會同步
打開了就同步了
總結
在一主多從的架構中，如果要開啟半同步複製，並不要求所有的從都是半同步複製。
MySQL 5.7極大的提升了半同步複製的效能。
5.6版本的半同步複製，dump thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave反饋資訊，而且這兩個任務是序列的，dump thread 必須等待 slave 返回之後才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高效能的瓶頸。在高併發業務場景下，這樣的機制會影響資料庫整體的TPS 。
5.7版本的半同步複製中，獨立出一個 ack collector thread ，專門用於接收slave 的反饋資訊。這樣master 上有兩個執行緒獨立工作，可以同時傳送binlog 到slave ，和接收slave的反饋。
Group Replication Background（組複製技術原理）
建立容錯系統的最常見方法是使元件冗餘，換句話說，部分元件可以刪除，系統應該繼續按預期執行。這產生了一系列挑戰，將這種系統的複雜性提高到一個完全不同的水平。具體來說，複製的資料庫必須處理這樣的情況，即它們需要維護和管理幾個伺服器而不是一個。此外，由於多個伺服器組成了一個“組”的概念來相互協同工作，必須處理幾個其他經典分散式系統問題，諸如網路劃分或裂腦情況。
因此，最終的挑戰是將資料庫的邏輯和多個例項之間的資料複製，以一致和簡單的方式融合好。換句話說，使多個伺服器同意系統的狀態和系統經歷的每個改變的資料。這可以被概括為使所有伺服器在每個資料庫例項狀態轉換上達成一致，使得它們都作為一個單個數據庫能否正常執行或者它們最終收斂到相同狀態。意味著整個叢集下的每個節點需要作為一個（分散式）狀態機操作。
MySQL組複製提供分散式狀態機複製，在伺服器之間具有強協調。當資料庫伺服器是屬於同一組時，組複製機制可以自動協調它們。該組可以在具有自動選擇新主庫功能的單主模式下操作，這種情況下一個組只有主節點才可以做寫操作。或者，對於更高階的使用者，該組可以以多主模式部署，即多個節點都可以做寫操作，即使它們是同時發過來的寫請求。不過這種情況下，應用層會有部分額外的限制。
有一個內建的組成員服務稱為group membership service，用以確保在任何給定的時間點該組的可用性和一致性的檢視。各個節點可以脫離和加入該組，並相應地更新該檢視。有時，組成員可能會意外脫離組，在這種情況下，故障檢測機制會檢測到此情況，並通知組檢視已更改。以上這些都是自動的。
一個事務要提交時，必須通過檢視它在全域性事務序列中的順序，並在得到大多陣列成員同意的情況下按照該順序提交。決定提交或廢棄一個已經執行過的事務是由每個成員單獨完成的，但所有成員必須做出相同的決定。假設這種情況，存在一個存在網路分割槽，導致成員無法達成協議的分割，則系統將不會進行，直到此問題解決。因此，還有一個內建的，自動的，裂腦保護機制。
所有上述功能都由組通訊協議實現。它提供了故障檢測機制failure detection mechanism，組成員服務group membership service以及安全和完全有序的訊息傳遞。所有這些屬性是保證創建出來的系統在多個節點之間進行復制時的資料一致性的關鍵。該技術的核心是Paxos演算法的實現，它充當群組通訊系統引擎。
ReplicationTechnologies（複製技術對比）
Primary-Secondary Replication（傳統主從複製）
傳統的MySQL複製提供了一種簡單的主 – 從複製架構。它有一個primary節點（master節點）和一個或多個secondary節點（slave節點）。主節點執行寫操作，然後將該寫操作稍後（因此非同步地）傳送到從節點，從節點重新執行該SQL（在基於語句的複製中）或應用該操作影響的結果行（在基於行的複製中）。它是一個shared-nothing系統，預設情況下所有節點都有一個完整的資料副本。
還有一個半同步複製，它向非同步複製協議新增一個同步步驟。這意味著主節點在提交時等待從節點ACK確認它已經接收到事務。只有這樣，主節點才恢復提交操作。
在上面的兩個圖片中，您可以看到經典非同步MySQL複製協議（以及它的半同步變體）的圖。藍色箭頭表示在資料節點之間交換的訊息或者在伺服器和客戶端應用之間交換的訊息。
Group Replication（組複製）
組複製是一種可用於實現容錯系統的技術。複製組是一個通過訊息傳遞相互互動的伺服器組。通訊層提供了很多保證，例如原子訊息和總訊息序號的傳遞。通過這些強大的特性，我們可以構建更高階的資料庫複製解決方案。
MySQL組複製構建在這些屬性和抽象之上，並實現多主複製協議的更新。實質上，複製組由多個數據庫例項組成，並且組中的每個例項都可以獨立地執行事務。但是所有讀寫（RW）事務只有在被組批准後才會提交。只讀（RO）事務不需要在組內協調，因此立即提交。換句話說，對於任何RW事務，組需要決定是否提交，因此提交操作不是來自始發伺服器的單向決定。準確地說，當事務準備好在始發伺服器上提交時，該始發伺服器原子地廣播寫入值（已改變的行）和對應的寫入集（已更新的行的唯一識別符號）。然後為該事務建立一個全域性總序號。最終，這意味著所有伺服器以相同的順序接收同一組事務。因此，所有伺服器以相同的順序應用相同的一組更改，因此它們在組內保持一致。
但是，在不同伺服器上併發執行的事務之間可能存在衝突。通過檢查兩個不同的併發事務的寫集合來檢測這樣的衝突，這個檢查過程稱為認證（certification）。如果在不同的伺服器上執行的兩個併發事務更新同一行，則會出現衝突。解析過程會這麼做，首先發起的事務在所有伺服器上提交，而後發起的事務將在源伺服器上回滾，並由組中的其他伺服器刪除。這實際上是一個分散式環境下“優先提交者贏”的規則。
最後，組複製是一種無共享複製方案（shared_nothing），即每個伺服器都有自己的整個資料副本。 上圖描述了MySQL組複製協議，並通過將其與MySQL複製（或甚至MySQL半同步複製）進行比較，您可以看到一些差異。注意，為了清楚起見，這個圖片中缺少一些基本的共識和Paxos相關資訊。
Group ReplicationUse Cases（組複製應用場景）
組複製使您能夠通過在一組伺服器中複製系統狀態來建立具有冗餘的容錯系統。因此，即使一些伺服器發生故障，只要它不是全部或大多數，雖然可能降低系統性能或可擴充套件性，但系統仍然可用。單一伺服器故障是隔離和獨立的。它們由group membership service跟蹤，它依賴於分散式故障檢測器，分散式故障檢測器能夠在任何節點成員自願地或由於意外停止而離開群組時發出訊號。分散式恢復過程能夠確保當有新節點加入組時，該節點會自動更新到最新。Multi-master特性確保即使在單個伺服器故障的情況下也不會阻止更新。因此，MySQL組複製保證資料庫服務持續可用。
不過需要重點理解，儘管組複製存在高可用，但連線到它的客戶端必須被重定向或故障轉移到不同的伺服器。這不是組複製嘗試解決的問題，而是聯結器，負載均衡器，路由器或一些其他中介軟體更適合處理這個問題。
總而言之，MySQL組複製提供了高可用性，高彈性，可靠的MySQL服務。
Examples of Use Case Scenarios（應用案例）
·彈性複製 - 需要非常流暢的複製基礎架構的環境，其中伺服器的數量必須動態增長或收縮，儘可能減少副作用。例如，雲的資料庫服務。
·高可用分片 - 分片是實現寫擴充套件的常用方法。使用MySQL組複製實現高可用性分片，其中每個分片對映到複製組。
·替代主從複製 - 在某些情況下，使用單一主節點可能使其成為單點爭用。在某些情況下，寫入整個組可能更具可擴充套件性。
·自動化系統 - 可以將MySQL組複製當做一個純粹的自動化複製系統
Group ReplicationDetails（組複製詳解）
Failure Detection（失敗檢測）
組複製提供了一種故障檢測機制，其能夠找到和報告哪些伺服器是沒有響應的，並假定其是死的。更深入地說，故障檢測器是提供關於哪些伺服器可能已死的資訊的分散式服務。後續如果組同意懷疑可能是真的，則由組來決定該伺服器確實已經失敗。這意味著組中的其餘成員進行協調決定排除給定成員。
伺服器無響應時觸發懷疑機制。當伺服器A在給定時間段內沒有從伺服器B接收訊息時，發生超時就會引起懷疑。
如果伺服器與組的其餘部分隔離，則它懷疑所有其他伺服器都失敗。由於無法與組達成協議（因為它無法獲得大多數成員認可），因此其懷疑沒有後果。當伺服器以此方式與組隔離時，它無法執行任何本地事務。
Group Membership(組成員服務)
MySQL組複製依賴於組成員服務group membership service。這是內建的外掛。它定義哪些伺服器是線上的並參與在複製組中。線上伺服器列表通常稱為檢視view。因此，組中的每個伺服器具有一致的檢視，其是在給定時刻積極參與到組中的成員。
複製組的成員們不僅需要同意事務是否提交，而且也需要決定當前檢視。因此，如果伺服器同意新的伺服器成為組的一部分，則該組本身被重新配置以將該伺服器整合在其中，從而觸發檢視改變。相反的情況也發生，如果伺服器自願地離開組，則該組動態地重新佈置其配置，並且觸發檢視改變。
請注意，當成員自願離開時，它首先啟動動態組重新配置。這觸發一個過程，所有成員必須同意新的檢視（也就是新檢視中沒有該離開成員）。然而，如果成員不由自主地離開（例如它已意外停止或網路連線斷開），則故障檢測機制實現這一事實，並且提出該組的重新配置（新檢視沒有該離開成員）。如上所述，這需要來自組中大多數成員的同意。如果組不能夠達成一致（例如，以不存在大多數伺服器線上的方式進行分割槽），則系統不能動態地改變配置，從而阻止腦裂情況引起的多寫。最終，這意味著管理員需要介入並解決這個問題。
Fault-tolerance（容錯機制）
MySQL組複製構建在Paxos分散式演算法的實現上，以提供伺服器之間的分散式協調。因此，它需要大多數伺服器處於活動狀態以達到選舉條件，從而做出決定。這對系統可以容忍的故障數量有直接影響，一個組複製中成員數量設定（n）為n = 2×f + 1。
在實踐中，這意味著為了容忍一個故障，組必須有三個伺服器。因此，如果一個伺服器故障，仍然有兩個伺服器形成大多數（三分之二）並且允許系統自動地繼續執行。但是，如果第二個伺服器也異常失敗，則該組（剩下一個伺服器）阻塞，因為沒有多數可以做出決定。https://www.actionsky.com/mysql-57-semi-sync-intro/
組複製 全同步機制
[root@server1 ~]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[root@server1 ~]# cd /var/lib/mysql
[root@server1 mysql]# pwd
/var/lib/mysql
[root@server1 mysql]# ls
auto.cnf mysql
ib_buffer_pool mysql-bin.000001
ibdata1 mysql-bin.index
ib_logfile0 performance_schema
ib_logfile1 sys
install-validate-password-plugin.x6qV01.sql test
[root@server1 mysql]# rm -rf *
[root@server1 mysql]# ls
[root@server1 mysql]# vim /etc/my.cnf
[root@server1 mysql]# /etc/init.d/mysqld start
Initializing MySQL database: [ OK ]
Starting mysqld: [ OK ]
[root@server1 mysql]# vim /etc/my.cnf
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="f4cfe0a0-9c7b-11e8-a10c-52540057d97e"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "172.25.53.1:24901"
loose-group_replication_group_seeds= "172.25.53.1:24901,172.25.53.2:24901,172.25.53.3:24901"
loose-group_replication_bootstrap_group=off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=on
loose-group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8"
[root@server1 mysql]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[root@server1 mysql]# /etc/init.d/mysqld start
Starting mysqld: [ OK ]
[root@server1 mysql]# grep password /var/log/mysqld.log
若是密碼登不上去，清除日誌後重覆上述動作
> /var/log/mysqld.log
最好按照官方文件做
https://dev.mysql.com/doc/refman/5.7/en/group-replication-launching.html
首先進入更改密碼
mysql> alter user root@localhost identified by '[email protected]'
-> ;
Query OK, 0 rows affected (0.06 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)
mysql> reset master;
Query OK, 0 rows affected (0.28 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='[email protected]' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.68 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.30 sec)
mysql> SHOW PLUGINS;
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
mysql> quit
Bye
檢視日誌
2018-08-10T09:44:51.280790Z 0 [Warning] Plugin group_replication reported: '[GCS] Connection attempt from IP address 172.25.53.1 refused. Address is not in the IP whitelist.'
經檢查是由於粗心將配置檔案白名單ip打錯
更改後由於配置檔案本次已經讀取，我們在mysql裡面也作更改
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> stop GROUP_REPLICATION;
Query OK, 0 rows affected (0.00 sec)
mysql> set global group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8";
Query OK, 0 rows affected (0.00 sec)
mysql> start GROUP_REPLICATION;
Query OK, 0 rows affected (1.44 sec)
可以正常啟動了
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.00 sec)
mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.09 sec)
mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
Query OK, 0 rows affected (0.62 sec)
mysql> INSERT INTO t1 VALUES (1, 'Luis');
Query OK, 1 row affected (0.12 sec)
mysql> SELECT * FROM t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)
Server2
[[email protected] mysql]# /etc/init.d/mysqld stop
Stopping mysqld: [ OK ]
[[email protected] mysql]# > /var/log/mysqld.log
[[email protected] mysql]# rm -rf *
[[email protected] mysql]# /etc/init.d/mysqld start
Initializing MySQL database: [ OK ]
Installing validate password plugin: [ OK ]
Starting mysqld: [ OK ]
[[email protected] mysql]# grep password /var/log/mysqld.log
[[email protected] ~]# vim /etc/my.cnf
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="f4cfe0a0-9c7b-11e8-a10c-52540057d97e"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "172.25.53.2:24901"
loose-group_replication_group_seeds= "172.25.53.1:24901,172.25.53.2:24901,172.25.53.3:24901"
loose-group_replication_bootstrap_group=off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=on
loose-group_replication_ip_whitelist="172.25.53.0/24,127.0.0.1/8"
mysql> show databases;
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
mysql> alter user [email protected] identified by '[email protected]';
Query OK, 0 rows affected (0.05 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> reset master;
Query OK, 0 rows affected (0.31 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='[email protected]' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.59 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.28 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (6.37 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
| group_replication_applier | 37569825-9c85-11e8-ab5e-525400178366 | server2 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1 |
+----------------+
1 row in set (0.00 sec)
mysql> select * from t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)
Server3與server2相同，不同之處是配置檔案
mysql> alter user [email protected] identified by '[email protected]';
Query OK, 0 rows affected (0.07 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> reset master;
Query OK, 0 rows affected (0.23 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='[email protected]' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.80 sec)
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.14 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.13 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 2f6d5f65-9c7f-11e8-8921-5254003240c0 | server1 | 3306 | ONLINE |
| group_replication_applier | 37569825-9c85-11e8-ab5e-525400178366 | server2 | 3306 | ONLINE |
| group_replication_applier | a810ff44-9c86-11e8-acaf-52540057d97e | server3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from t1;
+----+------+
| c1 | c2 |
+----+------+
| 1 | Luis |
+----+------+
1 row in set (0.00 sec)