MySQL 8.4 Reference Manual Including MySQL NDB Cluster 8.4

20.6.1 Communication Stack for Connection Security Management

MySQL 8.4 Group Replication can secure group communication connections between members by one of the following methods:

The choice is made by setting the system variable 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.

The following additional configuration is required for a replication group to use the MySQL 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.

Group Replication Requirements For The MySQL Communication Stack

group_replication_communication_stack is effectively a group-wide configuration setting, and the setting must be the same on all group members. However, this is not policed by Group Replication’s own checks for group-wide configuration settings. A member with a different value from the rest of the group cannot communicate with the other members at all, because the communication protocols are incompatible, so it cannot exchange information about its configuration settings.

This means that although the value of the system variable can be changed while Group Replication is running, and takes effect after you restart Group Replication on the group member, the member still cannot rejoin the group until the setting has been changed on all the members. You must therefore stop Group Replication on all of the members and change the value of the system variable on them all before you can restart the group. Because all of the members are stopped, a full reboot of the group (a bootstrap by a server with group_replication_bootstrap_group=ON) is required in order for the value change to take effect. You can make the other required changes to settings on the group members while they are stopped.

For a running group, follow this procedure to change the value of group_replication_communication_stack and the other required settings to migrate a group from the XCom communication stack to the MySQL communication stack, or from the MySQL communication stack to the XCom communication stack:

  1. Stop Group Replication on each of the group members, using a STOP GROUP_REPLICATION statement. Stop the primary member last, so that you do not trigger a new primary election and have to wait for that to complete.

  2. On each of the group members, set the system variable group_replication_communication_stack to the new communication stack, MYSQL or XCOM as appropriate. You can do this by editing the MySQL Server configuration file (typically named my.cnf on Linux and Unix systems, or my.ini on Windows systems), or by using a SET statement. For example: 

    SET PERSIST group_replication_communication_stack="MYSQL";

  3. If you are migrating the replication group from the XCom communication stack (the default) to the MySQL communication stack, on each of the group members, configure or reconfigure the required system variables to appropriate settings, as described in the listing above. For example, the group_replication_local_address system variable must be set to one of the IP addresses and ports that MySQL Server is listening on. Also configure any network namespaces using a CHANGE REPLICATION SOURCE TO statement.

  4. If you are migrating the replication group from the XCom communication stack (the default) to the MySQL communication stack, on each of the group members, issue GRANT statements to give the replication user account the GROUP_REPLICATION_STREAM and CONNECTION_ADMIN privileges. You will need to take the group members out of the read-only state that is applied when Group Replication is stopped. Also ensure that you skip binary logging on each group member by issuing SET SQL_LOG_BIN=0 before you issue the GRANT statements, and SET SQL_LOG_BIN=1 after them, so that the local transaction does not interfere with restarting Group Replication. For example: 

    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;

  5. If you are migrating the replication group from the MySQL communication stack back to the XCom communication stack, on each of the group members, reconfigure the system variables in the requirements listing above to settings suitable for the XCom communication stack. Section 20.9, “Group Replication Variables” lists the system variables with their defaults and requirements for the XCom communication stack.

    Note

  6. To restart the group, follow the process in Section 20.5.2, “Restarting a Group”, which explains how to safely bootstrap a group where transactions have been executed and certified. A bootstrap by a server with group_replication_bootstrap_group=ON is necessary to change the communication stack, because all of the members must be shut down.

  7. Members now connect to each other using the new communication stack. Any server that has group_replication_communication_stack set (or defaulted, in the case of XCom) to the previous communication stack is no longer able to join the group. It is important to note that because Group Replication cannot even see the joining attempt, it does not check and reject the joining member with an error message. Instead, the attempted join fails silently when the previous communication stack gives up trying to contact the new one.

MySQL Documentation Library