MySQL 8.4 群組複製可以使用下列其中一種方法來保護成員之間的群組通訊連線
使用其自身的安全性協定實作,包括 TLS/SSL 以及使用允許清單來允許傳入的群組通訊系統 (GCS) 連線。
使用 MySQL 伺服器自身的連線安全性來取代群組複製的實作。使用 MySQL 通訊協定表示標準使用者驗證方法可用於授與 (或撤銷) 對群組的存取權,以取代允許清單,而且伺服器通訊協定的最新功能在發佈時始終可用。
此選擇是透過將系統變數 group_replication_communication_stack
設定為 XCOM
以使用群組複製自身的實作 (這是預設選擇),或設定為 MYSQL
以使用 MySQL 伺服器的連線安全性來完成。
若要讓複製群組使用 MySQL 通訊堆疊,則需要下列額外的設定。當您將群組從使用 XCom 通訊堆疊切換為使用 MySQL 通訊堆疊時,務必確保所有這些需求都已符合。
MySQL 通訊堆疊的群組複製需求
每個群組成員的
group_replication_local_address
系統變數所設定的網路位址必須設定為 MySQL 伺服器正在接聽的一個 IP 位址和連接埠,如伺服器的bind_address
系統變數所指定。每個成員的 IP 位址和連接埠組合在群組中必須是唯一的。建議將每個群組成員的group_replication_group_seeds
系統變數設定為包含所有群組成員的所有本機位址。MySQL 通訊堆疊支援網路命名空間,而 XCom 通訊堆疊則不支援。如果將網路命名空間與群組成員的群組複製本機位址 (
group_replication_local_address
) 搭配使用,則必須使用CHANGE REPLICATION SOURCE TO
陳述式為每個群組成員設定這些網路命名空間。此外,每個群組成員的report_host
伺服器系統變數必須設定為報告命名空間。所有群組成員都必須使用相同的命名空間,以避免分散式復原期間發生位址解析問題。group_replication_ssl_mode
系統變數必須設定為群組通訊所需的設定。此系統變數會控制是否針對群組通訊啟用或停用 TLS/SSL。當使用 MySQL 通訊堆疊時,TLS/SSL 設定會從群組複製的分散式復原設定取得。此設定在所有群組成員上應該相同,以避免發生潛在衝突。為了避免潛在的衝突,所有群組成員上的
require_secure_transport
伺服器系統變數值應保持一致。如果group_replication_ssl_mode
設定為REQUIRED
、VERIFY_CA
或VERIFY_IDENTITY
,請使用require_secure_transport=ON
。如果group_replication_ssl_mode
設定為DISABLED
,請使用require_secure_transport=OFF
。如果為群組通訊啟用 TLS/SSL,則必須設定群組複寫的安全性分散式復原設定(如果尚未設定),或驗證是否已設定。MySQL 通訊堆疊不僅將這些設定用於成員之間的分散式復原連線,還用於一般群組通訊中的 TLS/SSL 設定。
group_replication_recovery_use_ssl
和其他group_replication_recovery_*
系統變數的說明請見 第 20.6.3.2 節「用於分散式復原的安全通訊端層 (SSL) 連線」。當群組使用 MySQL 通訊堆疊時,不會使用群組複寫的允許清單,因此
group_replication_ip_allowlist
系統變數會被忽略,無需設定。群組複寫用於分散式復原的複寫使用者帳戶(使用
CHANGE REPLICATION SOURCE TO
陳述式設定)在設定群組複寫連線時,會由 MySQL 通訊堆疊用於驗證。所有群組成員上的這個使用者帳戶必須具有以下權限GROUP_REPLICATION_STREAM
。使用者帳戶必須具有此權限,才能使用 MySQL 通訊堆疊建立群組複寫的連線。CONNECTION_ADMIN
。必須具有此權限,才能確保當其中一個伺服器進入離線模式時,不會終止群組複寫連線。如果使用 MySQL 通訊堆疊但沒有此權限,則進入離線模式的成員會從群組中移除。
除了所有複寫使用者帳戶都必須具備的
REPLICATION SLAVE
和BACKUP_ADMIN
權限之外(請參閱第 20.2.1.3 節「用於分散式復原的使用者認證」)。當您新增新的權限時,請務必在每個群組成員上,於發出GRANT
陳述式之前先執行SET SQL_LOG_BIN=0
,並在之後執行SET SQL_LOG_BIN=1
,以略過二進位記錄,這樣本機交易就不會干擾群組複寫的重新啟動。
group_replication_communication_stack
實際上是一個群組範圍的設定,而且所有群組成員上的設定必須相同。但是,群組複寫本身不會檢查此設定是否為群組範圍設定。具有與群組其他成員不同值的成員根本無法與其他成員通訊,因為通訊協定不相容,因此無法交換關於其組態設定的資訊。
這表示雖然可以在群組複寫執行時變更系統變數的值,並在您重新啟動群組成員上的群組複寫之後生效,但該成員仍然無法重新加入群組,除非已在所有成員上變更設定。因此,您必須停止所有成員上的群組複寫,並在重新啟動群組之前,變更所有成員上的系統變數值。由於所有成員都已停止,因此必須完全重新啟動群組(由具有 group_replication_bootstrap_group=ON
的伺服器進行引導),才能使值變更生效。您可以在群組成員停止時對它們的設定進行其他必要的變更。
對於正在執行的群組,請按照以下步驟來變更 group_replication_communication_stack
的值和其他必要設定,以將群組從 XCom 通訊堆疊移轉到 MySQL 通訊堆疊,或從 MySQL 通訊堆疊移轉到 XCom 通訊堆疊
使用
STOP GROUP_REPLICATION
陳述式,停止每個群組成員上的群組複寫。最後停止主要成員,這樣您就不會觸發新的主要選舉,而必須等待其完成。在每個群組成員上,將系統變數
group_replication_communication_stack
設定為新的通訊堆疊,視情況設定為MYSQL
或XCOM
。您可以透過編輯 MySQL 伺服器設定檔(在 Linux 和 Unix 系統上通常名為my.cnf
,在 Windows 系統上通常名為my.ini
)來執行此操作,或者使用SET
陳述式。例如SET PERSIST group_replication_communication_stack="MYSQL";
如果您要將複寫群組從 XCom 通訊堆疊(預設值)移轉到 MySQL 通訊堆疊,請在每個群組成員上,將必要的系統變數配置或重新配置為適當的設定,如上述清單中所述。例如,
group_replication_local_address
系統變數必須設定為 MySQL 伺服器正在接聽的一個 IP 位址和埠。另外,請使用CHANGE REPLICATION SOURCE TO
陳述式來配置任何網路命名空間。如果您要將複寫群組從 XCom 通訊堆疊(預設值)移轉到 MySQL 通訊堆疊,請在每個群組成員上,發出
GRANT
陳述式,以授予複寫使用者帳戶GROUP_REPLICATION_STREAM
和CONNECTION_ADMIN
權限。您需要將群組成員從停止群組複寫時套用的唯讀狀態中取出。另外,請務必在每個群組成員上,於發出GRANT
陳述式之前先執行SET SQL_LOG_BIN=0
,並在之後執行SET SQL_LOG_BIN=1
,以略過二進位記錄,這樣本機交易就不會干擾群組複寫的重新啟動。例如SET GLOBAL SUPER_READ_ONLY=OFF; SET SQL_LOG_BIN=0; GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%'; GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%'; SET SQL_LOG_BIN=1;
如果您要將複寫群組從 MySQL 通訊堆疊移轉回 XCom 通訊堆疊,請在每個群組成員上,將上述需求清單中的系統變數重新配置為適合 XCom 通訊堆疊的設定。第 20.9 節「群組複寫變數」列出系統變數及其預設值和 XCom 通訊堆疊的需求。
注意XCom 通訊堆疊不支援網路命名空間,因此群組複寫本機位址(
group_replication_local_address
系統變數)無法使用這些。請發出CHANGE REPLICATION SOURCE TO
陳述式來取消設定。當您移回 XCom 通訊堆疊時,
group_replication_recovery_use_ssl
和其他group_replication_recovery_*
系統變數指定的設定,不會用於保護群組通訊的安全。而是使用群組複寫系統變數group_replication_ssl_mode
來啟用群組通訊連線對 SSL 的使用,並指定連線的安全性模式,其餘組態則取自伺服器的 SSL 組態。如需詳細資訊,請參閱 第 20.6.2 節「使用安全通訊端層 (SSL) 保護群組通訊連線」。
若要重新啟動群組,請按照 第 20.5.2 節「重新啟動群組」中的程序執行,其中說明如何安全地引導已執行和驗證交易的群組。若要變更通訊堆疊,必須由具有
group_replication_bootstrap_group=ON
的伺服器進行引導,因為所有成員都必須關閉。成員現在使用新的通訊堆疊互相連線。任何將
group_replication_communication_stack
設定(或預設,在 XCom 的情況下)為先前通訊堆疊的伺服器,都無法再加入群組。請務必注意,因為群組複寫甚至看不到加入嘗試,所以它不會檢查並拒絕加入的成員,並顯示錯誤訊息。相反地,當先前的通訊堆疊放棄嘗試連絡新的通訊堆疊時,加入嘗試會以無聲的方式失敗。