有人詢問MySQL InnoDB Cluster中,group_replication_local_address參數設置的端口跟MySQL監聽端口一致, 這樣會衝突嗎? 為什麼他將節點加入InnoDB Cluster報錯?

簡單展示如下:

mysql> show variables like 'port';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| port          | 3306  |
+---------------+-------+
1 row in set (0.01 sec)

mysql> 
mysql> show variables like 'group_replication_local_address';
+---------------------------------+---------------+
| Variable_name                   | Value         |
+---------------------------------+---------------+
| group_replication_local_address | mysqlu01:3306 |
+---------------------------------+---------------+
1 row in set (0.01 sec)

mysql> 

其實MySQL變量group_replication_local_address中的端口跟MySQL監聽端口3306一致,不一定會引起衝突. 因為MySQL組複製的通信棧協議有兩種,具體取決於你的MySQL版本與你使用的通信棧(Communication Stack).

通信棧類型

MySQL組複製支持以下通信堆棧：

MYSQL通信堆棧

MySQL通信棧是MySQL 8.0.27版本開始引入的,MySQL通過使用MySQL Server 的連接安全性代替Group Replication的實現。使用MySQL協議意味着可以使用標準的用户身份驗證方法來授予(或撤銷)對組的訪問權限，

• 通過使用 MySQL 服務器的連接安全性代替組複製實現來簡化MySQL InnoDB 集羣的創建。

• 消除了對內部組複製通信的額外網絡地址或端口的需要。

• 使用 MYSQL 協議意味着可以使用標準的用户身份驗證方法來授予或撤銷對組的訪問權限，而不是允許列表。

• 支持組複製的網絡命名空間。

Oracle 建議使用MySQL通信堆棧而不是XCOM.

XCOM通信堆棧

XCOM: (MySQL Server 8.0.26 或更早版本的默認值)。您可以將 XCOM 通信堆棧與 MySQL 8.0.27 或更高版本一起使用，但必須在創建或重啓命令中明確定義。

XCOM使用安全協議的組複製實現來保護成員之間的組通信連接和分佈式恢復連接，包括 TLS/SSL 和對傳入組通信系統 (GCS) 連接使用允許列表。

如果您正在使用 XCOM通信堆棧，除了默認port的 3306(用於通過經典 MySQL 協議進行客户端連接)和 mysqlx_port默認為 33060（用於 X 協議客户端連接）之外，
還有一個內部端口集羣中不用於客户端連接的實例之間的連接。該端口由localAddress選項配置，該選項配置 group_replication_local_address 系統變量，這個
端口必須打開，這樣集羣中的實例才能相互通信。例如，如果您的防火牆阻止了此端口，則實例無法相互通信，集羣也無法運行。同樣，如果您的實例正在使用SELinux，
您需要確保 InnoDB Cluster 使用的所有必需端口都已打開，以便實例可以相互通信。

查看使用的通信棧類型

如下所示,字段MEMBER_COMMUNICATION_STACK表示MGR使用的通信棧類型.

mysql> SELECT MEMBER_HOST
    ->       ,MEMBER_PORT
    ->       ,MEMBER_COMMUNICATION_STACK 
    -> FROM performance_schema.replication_group_members
    -> ORDER BY MEMBER_HOST;
+-------------+-------------+----------------------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_COMMUNICATION_STACK |
+-------------+-------------+----------------------------+
| mysqlu01    |        7306 | MySQL                      |
| mysqlu02    |        7306 | MySQL                      |
| mysqlu03    |        7306 | MySQL                      |
+-------------+-------------+----------------------------+
3 rows in set (0.00 sec)

MGR通信棧為Xcom場景

mysql> SELECT MEMBER_HOST
    ->       ,MEMBER_PORT
    ->       ,MEMBER_COMMUNICATION_STACK 
    -> FROM performance_schema.replication_group_members
    -> ORDER BY MEMBER_HOST;
+-------------+-------------+----------------------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_COMMUNICATION_STACK |
+-------------+-------------+----------------------------+
| mysqlu01    |        7306 | XCom                       |
| mysqlu02    |        7306 | XCom                       |
| mysqlu03    |        7306 | XCom                       |
+-------------+-------------+----------------------------+
3 rows in set (0.01 sec)

mysql> 

通信棧選擇

MySQL官方推薦使用MySQL通信棧而非XCOM通信棧.原文如下:

Oracle recommends using the MYSQL communication stack instead of XCOM.

當然也有人認為目前而言,MySQL通信棧Bug多一些,使用XCOM通信棧更穩定一些.

參考資料

1.https://dev.mysql.com/doc/mysql-shell/8.4/en/shell-admin-api-communication-stack.html
2.https://dev.mysqlserver.cn/doc/mysql-shell/8.4/en/shell-admin-api-communication-stack.html
3.How To Use group_replication_communication_stack in InnoDB Cluster FAQ4202