【MySQL】MGR入門指南

MySQL組複製是MySQL server的插件,組中的每個server都需要配置和安裝該插件。本節提供了一個詳細的教程,其中包含創建至少三臺server的複製組所需的步驟。

18.2.1在單主模式下部署組複製

組中的每個server實例可以在獨立的物理機器上運行,也可以在同一臺機器上運行。本節介紹如何在一臺物理機上創建具有三個MySQL Server實例的複製組。這意味着需要三個數據目錄,每個server實例一個,每個實例都需要單獨配置。

圖18.4組架構

圖18.4

本教程介紹如何使用組複製插件獲取和部署MySQL Server,如何在創建組之前配置每個server實例以及如何使用Performance Schema來驗證一切是否正常。

18.2.1.1 部署組複製實例

第一步是部署MySQL服務器的三個實例。組複製是MySQL Server 8.0提供的內置MySQL插件。有關MySQL插件的更多背景信息,請參見第5.6節“MySQL服務器插件”。下載MySQL服務器包後,需要解壓縮並安裝二進制文件。此過程假定MySQL服務器已下載並解壓縮到當前目錄,該目錄需要在mysql-8.0的目錄下。由於本教程使用一個物理機,每個MySQL實例都需要一個特定的數據目錄,用於存儲實例的數據。在名爲data 的目錄中創建數據目錄,並初始化每個目錄。

mkdir data
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s1
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s2
mysql-8.0/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-8.0 --datadir=$PWD/data/s3

裏面data/s1data/s2data/s3是一個初始化的數據目錄,包含了MySQL系統數據庫和相關表等。要了解有關初始化過程的更多信息,請參見 第2.10.1節“初始化數據目錄”。

Warning
不要在生產環境中使用–initialize-insecure,它只用於簡化教程。有關安全設置的更多信息,請參見第18.5節“組複製安全性”。

18.2.1.2 配置組複製實例

本節介紹要用於組複製的MySQL Server實例所需的配置設置。有關背景信息,請參見 第18.8.2節“組複製限制”。

組複製 Server設置

要安裝和使用組複製插件,必須正確配置MySQL server實例。建議將配置存儲在my.cnf文件中。有關詳細信息,請參見第4.2.7節“文件的使用”。如沒有特殊說明,以下是組中第一個實例的配置,在此節中稱爲s1。以下部分展示server的示例配置。

[mysqld]

# server configuration
datadir=<full_path_to_data>/data/s1
basedir=<full_path_to_bin>/mysql-8.0/

port=24801
socket=<full_path_to_sock_dir>/s1.sock

這些設置對MySQL server進行了配置,使其使用先前已創建的數據目錄,並配置server應打開哪個端口,並開始偵聽傳入連接。

Note
在此使用非默認端口24801,因爲在本教程中,三個服務器實例使用相同的主機名。在具有三個不同機器的環境中,這種設置不是必需的。

組複製需要成員之間網絡互通,這意味着每個成員必須能夠解析所有其他成員的網絡地址。例如,在本教程中,所有的三個實例都在一臺機器上運行,因此爲了確保成員可以相互聯繫,您還可以在配置文件中添加一行,例如 report_host=127.0.0.1

複製框架

以下設置根據MySQL組複製要求配置複製。

server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

這些設置將server配置爲使用唯一標識號1,以啓用全局事務標識符,以允許僅執行基於GTID安全記錄的語句並禁用二進制日誌事件校驗和。

如果您使用的是低於8.0.3的MySQL版本,其中默認值已針對複製進行了改進,則需要將這些行添加到成員的配置文件中。

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

這些設置指定server打開二進制日誌記錄,使用基於行的格式,將複製元數據存儲在系統表而不是文件中,並禁用二進制日誌事件校驗和。有關更多詳細信息,請參見 第18.8.1節“組複製要求”。

組複製設置

確保server中my.cnf文件此時已按要求配置,且server按配置實例化複製基礎結構。以下部分是server組複製的配置。

transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "127.0.0.1:24901"
group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
group_replication_bootstrap_group=off
  • 配置 transaction_write_set_extraction 指示服務器對於每個事務,它必須收集寫集並使用XXHASH64哈希算法將其編碼爲散列。從MySQL 8.0.2開始,此設置是默認設置,因此可以省略此行。
  • 配置 group_replication_group_name 告訴插件它正在加入或創建的組被命名爲“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”
    group_replication_group_name 必須是有效的UUID。在二進制日誌中爲組複製事件設置GTID時,將在內部使用此UUID。可使用SELECT UUID()生成一個UUID。
  • 配置 group_replication_start_on_boot 指示插件在server啓動時不自動啓動組複製。這在設置組複製時很重要,因爲它確保您可以在手動啓動插件之前配置server。配置成員後,您可以設置 group_replication_start_on_boot 爲on,以便在server重啓時自動啓動Group Replication。
  • 配置 group_replication_local_address 告訴插件使用IP地址127.0.0.1和端口24901與組中的其他成員進行內部通信。

Important
server在此端口上偵聽組成員之間的連接。此端口不能用於用戶應用程序,它必須保留,用於在運行組複製時組的不同成員之間的通信。

group_replication_local_address 配置的本地地址必須可供所有組成員訪問。例如,如果每個server實例位於不同的計算機上,則可以使用計算機的IP地址,例如10.0.0.1。如果使用主機名,則必須使用完全限定名稱,並確保它可以通過DNS解析,並且配置正確的 /etc/hosts文件或其他域名解析過程。從MySQL 8.0.14開始,可以使用IPv6地址(或可以解析到它的主機名)以及IPv4地址。一個組可以包含使用IPv6的成員和使用IPv4的成員的混合。有關IPv6網絡以及混合IPv4和IPv6組的組複製支持的更多信息,請參見 第18.4.5節“支持IPv6以及混合IPv6和IPv4組”。

建議的端口 group_replication_local_address 是33061.在本教程中,我們使用在一臺計算機上運行的三個server實例,因此使用端口24901到24903用於內部通信。 group_replication_local_address Group Replication使用它作爲複製組中組成員的唯一標識符。只要主機名或IP地址都不同,您就可以爲組複製的所有成員使用相同的端口,並且如本教程所示,只要具有相同的主機名或IP地址,就可以使用相同的主機名或IP地址。只是端口都不一樣。

  • 配置 group_replication_group_seeds 設置組成員的主機名和端口,新成員使用它們建立與組的連接。這些成員稱爲種子成員。建立連接後,組成員身份信息在 performance_schema.replication_group_members表中。通常, group_replication_group_seeds列表包含hostname:port每個組成員的列表 group_replication_local_address,但這不是強制性的,可以選擇組成員的子集作爲種子。

Important
hostname:port列在 group_replication_group_seeds 是種子成員的內部IP地址,基於配置group_replication_local_address ,而不是SQL hostname:port用於客戶端連接,並且顯示在performance_schema.replication_group_members 表中。

啓動組的server不使用此選項,因爲它是初始server,因此它負責引導組。第二個加入的server向組中的唯一成員申請加入,然後組得以擴容。第三個加入的server可以向這兩個server中的任意一個申請加入,然後組再次擴容。後續server在加入時重複此過程。

Warning
當多個server同時加入時,請確保它們已在組中的種子成員。不要使用同時正在申請加入組的種子成員,因爲他們可能在訪問時尚未加入羣組。
首先啓動引導成員並讓它創建組, 然後使其成爲正在加入的其餘成員的種子成員。這確保了當加入其餘成員時已有一個組。
不支持創建組並同時加入多個成員。在操作競爭時,這種情況可能會發生,但是加入組的行爲最終會出現錯誤或超時。

要加入的成員必須使用種子成員在group_replication_group_seeds 選項中通告的相同協議(IPv4或IPv6)與種子成員通信 。出於組複製的IP地址白名單的目的,種子成員上的白名單必須包含種子成員提供的協議的加入成員的IP地址,或者解析爲該協議的地址的主機名。除了加入成員之外,還必須設置此地址或主機名並列入白名單 group_replication_local_address 如果該地址的協議與種子成員的通告協議不匹配。如果加入成員沒有適當協議的白名單地址,則拒絕其連接嘗試。有關更多信息,請參見 第18.5.1節“IP地址白名單”。

  • 配置 group_replication_bootstrap_group 指示插件是否是引導組。

Important
此選項在任何時候只能在一個server實例上使用,通常是首次引導組時(或在整個組被崩潰然後恢復的情況下)。如果您多次引導組,例如,當多個server實例設置了此選項,則它們可能會人爲地造成腦裂的情況,其中存在兩個具有相同名稱的不同組。在第一個server實例加入組後禁用此選項。

組中的所有server成員的配置都非常相似。您需要更改每個server的詳細信息(例如server_iddatadirgroup_replication_local_address)。這將在本教程的後面進行介紹。

18.2.1.3 用戶憑據

組複製使用異步複製協議來實現分佈式恢復,在將組成員加入組之前將其同步。分佈式恢復過程依賴於group_replication_recovery複製通道,該複製通道用於在組成員之間傳輸事務。因此,您需要設置具有正確權限的複製用戶,以便組複製可以直接建立成員到成員的恢復複製通道。

使用配置文件啓動服務器:

mysql-8.0/bin/mysqld --defaults-file=data/s1/s1.cnf

創建具有REPLICATION-SLAVE權限的MySQL用戶。此操作不應記錄到二進制日誌中,以避免將更改傳遞到其他server實例。連接到server s1並執行以下語句:

mysql> SET SQL_LOG_BIN=0;

以下示例演示了創建用戶rpl_user的過程,密碼爲rpl_pass。配置服務器時需要使用正確的用戶名和密碼。

mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;

如果禁用了二進制日誌記錄,則在創建用戶後再次啓用它。

mysql> SET SQL_LOG_BIN=1;

用戶進行上述配置後,需要使用CHANGE MASTER TO語句將server配置爲,在下次需要從其他成員恢復其狀態時,使用group_replication_recovery複製通道的給定憑據。執行以下命令,將rpl_user和rpl_pass替換爲創建用戶時使用的值。

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
		      FOR CHANNEL 'group_replication_recovery';

分佈式恢復是加入組的server執行的第一步。如果未正確設置這些憑據,server將無法執行恢復過程並獲得與其他組成員同步,因此最終將無法加入組。

類似地,如果成員無法通過server的主機名正確識別其他成員,則恢復過程可能會失敗。建議運行MySQL的操作系統都正確地配置唯一主機名,使用DNS或本地設置。可以在performance_schema.replication_group_members表的Member_host列中驗證此主機名。如果多個組成員使用操作系統設置的默認主機名,則會出現有成員無法解析到正確的成員地址且無法加入組的情況。在這種情況下,可以使用report_host來配置每個server唯一主機名。

使用組複製和Caching SHA-2用戶憑據插件

默認情況下,在MySQL 8中創建的用戶使用 第6.5.1.3節“緩存SHA-2插件身份驗證”。如果您配置的用於分佈式恢復的用戶_rpl_user_使用緩存SHA-2認證插件並沒有使用 第18.5.2,“安全套接字層支持(SSL)” 的group_replication_recovery 複製通道,RSA密鑰用於密碼交換,看第6.4.3節“創建SSL和RSA證書和密鑰”。您可以將rpl_user應該從組中恢復其狀態的成員的公鑰複製到該組,也可以將捐贈者配置爲在請求時提供公鑰。

更安全的方法是將公鑰複製 rpl_user到應該從捐贈者恢復組狀態的成員。然後,您需要group_replication_recovery_public_key_path 在加入組的成員上配置 系統變量,併爲其提供公鑰的路徑rpl_user

可選地,不太安全的方法是設置 group_replication_recovery_get_public_key=ON 捐贈者,以便他們rpl_user在加入組時提供成員的公鑰 。無法驗證服務器的身份,因此只有group_replication_recovery_get_public_key=ON 在您確定沒有服務器身份被泄露的風險時纔會設置 ,例如通過中間人攻擊。

18.2.1.4 啓動組複製

配置並啓動server s1後,安裝組複製插件。然後連接到server並執行以下命令:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Important
在加載組複製之前 ,mysql.session用戶必須存在。 mysql.session用戶在MySQL 8.0.2版中添加了。如果使用早期版本需要初始化數據字典,則必須執行MySQL升級過程(請參見第2.11節“升級MySQL”)。如果未運行升級,則組複製啓動時會報錯如下:There was an error when trying to access the server with user: mysql.session@localhost. Make sure the user is present in the server and that mysql_upgrade was ran after a server update…

要檢查插件是否已成功安裝,請執行SHOW PLUGINS並檢查輸出。它應該顯示如下:

mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+-------------+
| Name                       | Status   | Type               | Library              | License     |
+----------------------------+----------+--------------------+----------------------+-------------+
| binlog                     | ACTIVE   | STORAGE ENGINE     | NULL                 | PROPRIETARY |
(...)
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | PROPRIETARY |
+----------------------------+----------+--------------------+----------------------+-------------+

要啓動組,請指示server s1引導組,然後啓動組複製程序。此引導應僅由單個sever獨立完成,該server啓動組並且只啓動一次。這就是爲什麼引導配置選項的值不保存在配置文件中的原因。如果將其保存在配置文件中,則在重新啓動時,server會自動引導具有相同名稱的第二個組。這將導致兩個不同的組具有相同的名稱。同樣的道理適用於停止和重新啓動插件,並且此選項設置爲ON。

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

START GROUP_REPLICATION語句返回後,組就已啓動了。您可以檢查該組現在是否已創建並且其中已經有一個成員:

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | ce9be252-2b71-11e6-b8f4-00212844f856 | myhost      |       24801 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

此表中的信息確認了組中有一個成員並且具有唯一的標識符ce9be252-2b71-11e6-b8f4-00212844f856,它是在線的並且在myhost偵聽端口24801上的客戶端連接。

爲了演示server確實在一個組中,並且能夠處理加載,創建一個表並向其中添加一些內容。

mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
mysql> INSERT INTO t1 VALUES (1, 'Luis');

檢查表t1和二進制日誌的內容。

mysql> SELECT * FROM t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |   4 | Format_desc    |         1 |         123 | Server ver: 8.0.2-gr080-log, Binlog ver: 4                        |
| binlog.000001 | 123 | Previous_gtids |         1 |         150 |                                                                    |
| binlog.000001 | 150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 | 211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 | 270 | View_change    |         1 |         369 | view_id=14724817264259180:1                                        |
| binlog.000001 | 369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 | 434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 | 495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 | 585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 | 646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 | 831 | Query          |         1 |         899 | BEGIN                                                              |
| binlog.000001 | 899 | Table_map      |         1 |         942 | table_id: 108 (test.t1)                                            |
| binlog.000001 | 942 | Write_rows     |         1 |         984 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 | 984 | Xid            |         1 |        1011 | COMMIT /* xid=38 */                                                |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+

如上所示,創建了數據庫和表對象,並且將其對應的DDL語句寫入二進制日誌。此外,數據被插入到表中並被寫入二進制日誌。當組成員增長並且由於新成員嘗試加入並變爲在線而執行分佈式恢復時,二進制日誌條目的重要性將在以下部分中說明。

18.2.1.5 向組中添加實例

此時,組中有一個成員,已經有一些數據存在的server s1。此時就可以通過添加先前配置的其他兩個server來擴展組了。

18.2.1.5.1 添加第二個實例

爲了添加第二個實例server s2,首先爲它創建配置文件。該配置類似於用於server s1的配置,除了諸如數據目錄的位置,s2將要監聽的端口或其server_id之類的事情之外。這些不同的行已在下面的列表中突出顯示。

[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s2
basedir=<full_path_to_bin>/mysql-8.0/
port=24802
socket=<full_path_to_sock_dir>/s2.sock
#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "127.0.0.1:24902"
group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
group_replication_bootstrap_group= off

server s1的過程類似,在配置文件就位的情況下啓動server。

mysql-8.0/bin/mysqld --defaults-file=data/s2/s2.cnf

然後按如下所示配置恢復憑據。由於用戶在組中共享,該命令與設置server s1時使用的命令相同。在s2上執行以下語句。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
	FOR CHANNEL 'group_replication_recovery';

Tip
如果您使用的是緩存SHA-2身份驗證插件(MySQL 8中的默認設置),請參閱 使用組複製和緩存SHA-2用戶憑據插件。

安裝組複製插件,並啓動將server加入組的程序。以下示例使用與部署server s1時相同的方式安裝插件。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

將server s2添加到組。

mysql> START GROUP_REPLICATION;

與之前的步驟不同,這裏與s1上執行的那些步驟有一個區別,就是不執行SET GLOBAL group_replication_bootstrap_group = ON的操作; 在啓動組複製之前,因爲該組已由server s1創建和引導。此時,server s2只需要添加到已經存在的組中。

Tip
當組複製成功啓動並且服務器加入組時,它會檢查 super_read_only變量。通過super_read_only 在成員的配置文件中設置爲ON,可以確保因任何原因啓動組複製時出現故障的服務器不接受事務。如果服務器應將該組作爲讀寫實例加入,例如作爲單主組中的主要組或多主組的成員,則當該 super_read_only變量設置爲ON時,則在加入時會將其設置爲OFF。

再次檢查performance_schema.replication_group_members表,可以看出組中現在有兩個ONLINE的server。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost      |       24801 | ONLINE        |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost      |       24802 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

由於server s2也被標記爲ONLINE,它必須已經與server s1同步。按照如下方式驗證它確實與server s1同步。

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         2 |         123 | Server ver: 8.0.3-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         2 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=30 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

如上所示,第二個server已添加到組中,並且已自動從server s1複製了更改。按照分佈式恢復過程,這意味着加入組之後並且在即將被聲明在線之前,server s2自動地連接到server s1並且從其獲取丟失的數據。換句話說,它從s1的二進制日誌中複製了它在加入組的時間節點之前缺少的事務。

18.2.1.5.2 添加其他實例

向組添加其他實例與添加第二個server基本上是相同的步驟,除了配置必須更改爲對應的server。總結所需的命令如下:

1.創建配置文件

[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-8.0/
port=24803
socket=<full_path_to_sock_dir>/s3.sock
#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
#
# Group Replication configuration
#
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "127.0.0.1:24903"
group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
group_replication_bootstrap_group= off

2.啓動server

mysql-8.0/bin/mysqld --defaults-file=data/s3/s3.cnf

3.配置group_replication_recovery通道的恢復憑據。

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'  \\
FOR CHANNEL 'group_replication_recovery';

4.安裝Group Replication插件並啓動它。

INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;

此時,server s3被引導並且正在運行,並且已經加入組且已與組中的其他server成員同步。訪問performance_schema.replication_group_members表再次確認真實情況確實如此。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 | myhost      |       24801 | ONLINE        |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | myhost      |       24803 | ONLINE        |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | myhost      |       24802 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

在server s2或server s1上發出此相同的查詢會產生相同的結果。此外,您可以驗證server s3已經同步:

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+
mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 8.0.3-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=29 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
| binlog.000001 | 1326 | Gtid           |         1 |        1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6'  |
| binlog.000001 | 1387 | Query          |         1 |        1446 | BEGIN                                                              |
| binlog.000001 | 1446 | View_change    |         1 |        1585 | view_id=14724832985483517:3                                        |
| binlog.000001 | 1585 | Query          |         1 |        1650 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

公衆號.jpg

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章