### 18.6.1 Methods for Connection Security Management

 Since MySQL 8.,0.27, Group Replication can secure group communication connections between members by one of the following methods:

* Using its own implementation of the security protocols, including TLS/SSL and the use of an allowlist for incoming Group Communication System (GCS) connections. This is the only option for MySQL 8.0.26 and earlier.

* Using MySQL Server’s own connection security in place of Group Replication’s implementation. Using the MySQL protocol means that standard methods of user authentication can be used for granting (or revoking) access to the group in place of the allowlist, and the latest functionality of the server’s protocol is always available on release. This is option is available since MySQL 8.0.27.

 The choice is made by setting the system variable [`group_replication_communication_stack`](group-replication-options.html#sysvar_group_replication_communication_stack) to `XCOM` to use Group Replication's own implementation (this is the default choice), or to `MYSQL` to use MySQL Server's connection security. If you are choosing the latter, pay attention to the extra requirements explained below.

#### Configuring a group to use the MySQL Communication Stack

 The following additional configuration is required for a group to use MySQL’s communication stack. It is especially important to make sure these requirements are all fulfilled when you switch from using the XCom communication stack to the MySQL communication stack for your group.

* The network address configured by the [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) system variable for each group member must be set to one of the IP addresses and ports where MySQL Server is listening on, as specified by the [`bind_address`](server-system-variables.html#sysvar_bind_address) system variable for the server. The combination of IP address and port for each member must be unique in the group.

* If network namespaces are used in the Group Replication local addresses, these must be configured for each group member using the [`CHANGE REPLICATION SOURCE TO`](change-replication-source-to.html) statement. The [`report_host`](replication-options-replica.html#sysvar_report_host) server system variable for each group member must be set to report the namespace. All group members must use the same namespace to avoid possible issues with address resolution during distributed recovery.

* The replication user account that Group Replication uses for distributed recovery, as configured using the [`CHANGE REPLICATION SOURCE TO`](change-replication-source-to.html) statement, must be given the new [`GROUP_REPLICATION_STREAM`](privileges-provided.html#priv_group-replication-stream) privilege. This user account must be the same on all the group members. The MySQL communication stack uses it for authentication when setting up connections.

* The [`group_replication_ssl_mode`](group-replication-options.html#sysvar_group_replication_ssl_mode) system variable must be set to the required setting for group communications. This system variable controls whether TLS/SSL is enabled or disabled for group communications. For MySQL 8.0.26 and earlier, the TLS/SSL configuration is always taken from the server’s SSL settings; for MySQL 8.0.27 and later, when the MySQL communication stack is used, the TLS/SSL configuration is taken from Group Replication’s distributed recovery settings. This setting should be the same on all the group members, to avoid potential conflicts.

* If TLS/SSL is enabled for group communications, Group Replication’s settings for securing distributed recovery must be configured if they are not already in place, or validated if they already are. The MySQL communication stack uses these settings not just for member-to-member distributed recovery connections, but also for TLS/SSL configuration in general group communications.

* The settings for the [`--ssl`](server-options.html#option_mysqld_ssl) or [`--skip-ssl`](server-options.html#option_mysqld_ssl) server option and for the [`require_secure_transport`](server-system-variables.html#sysvar_require_secure_transport) server system variable should be the same on all the group members, to avoid potential conflicts. If [`group_replication_ssl_mode`](group-replication-options.html#sysvar_group_replication_ssl_mode) is set to `REQUIRED`, `VERIFY_CA`, or `VERIFY_IDENTITY`, use [`--ssl`](server-options.html#option_mysqld_ssl) and [`require_secure_transport=ON`](server-system-variables.html#sysvar_require_secure_transport). If [`group_replication_ssl_mode`](group-replication-options.html#sysvar_group_replication_ssl_mode) is set to` DISABLED`, use[` require_secure_transport=OFF`](server-system-variables.html#sysvar_require_secure_transport).

Notes

* Changing the system variables mentioned above in runtime will not affect already established connections nor incoming connections. To change to the MySQL connection protocol, you need to restart Group Replication after the reconfiguration.

* The Group Replication allowlist is not used when the group is using the MySQL communication stack, so the [`group_replication_ip_allowlist`](group-replication-options.html#sysvar_group_replication_ip_allowlist) and[` group_replication_ip_whitelist`](group-replication-options.html#sysvar_group_replication_ip_whitelist) system variables are ignored and need not be configured.

* It is recommended that the [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds) system variable for each group member be configured to contain all the local addresses for all the group members.

#### Migration a group from using the XCom communication stack to the MySQL
communication stack

 Here are the steps to follow:

1. Stop Group Replication in all members

2. Change the value of [`group_replication_communication_stack`](group-replication-options.html#sysvar_group_replication_communication_stack) to `MYSQL`, and reconfigure system variables like [` group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address), [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds), and so on for all group members, as described in [Configuring a group to use the MySQL Communication Stack](group-replication-connection-security.html#group-replication-configure-mysql-stack).

3. Start Group Replication in all members

4. Members now connect to each other using the MySQL communication stack. Any server that has [`group_replication_communication_stack=XCOM`](group-replication-options.html#sysvar_group_replication_communication_stack) will no longer be able to join the group

#### Migration a group from using the MySQL communication stack to the XCom
communication stack

 Here are the steps to follow:

1. Stop group replication in all members

2. Change the value of [`group_replication_communication_stack`](group-replication-options.html#sysvar_group_replication_communication_stack) to `XCOM`, and adjust [` group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address), [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds), and other network configuration for all members as needed, as the settings for distributed recovery will no longer be used for ordinary group communications

3. Remove namespace references in any group member's local address, as the use of namespaces is not supported by the XCom communication stack. Adjust the servers' addresses accordingly

4. Start Group Replication in all members

5. Members now connect with the XCom communication stack. Any server that has [`group_replication_communication_stack=MYSQL`](group-replication-options.html#sysvar_group_replication_communication_stack) will no longer be able to join the group