Documentation Home
MySQL Shell 8.4
Download this Manual
PDF (US Ltr) - 2.2Mb
PDF (A4) - 2.3Mb

MySQL Shell 8.4  /  ...  /  Configuring the Group Replication Communication Stack

7.5.9 Configuring the Group Replication Communication Stack

InnoDB Cluster and ClusterSet support the MySQL communication stack introduced for Group Replication in MySQL 8.0.27.

The new option, communicationStack: XCOM|MYSQL sets the value of the Group Replication system variable group_replication_communication_stack.


It is not possible to use the communicationStack option with adoptfromGR.

Communication Stack Types

The following communication stacks are supported:

  • MYSQL: (default for MySQL Server 8.0.27 or newer)

    • Simplifies the creation of InnoDB Clusters by using MySQL Server's connection security in place of the Group Replication implementation.

    • Removes the need for an extra network address, or port, for internal Group Replication communications.

    • 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 allow list.

    • Supports network namespaces for Group Replication.

    Oracle recommends using the MYSQL communication stack instead of XCOM.

  • XCOM: (default for MySQL Server 8.0.26 or older). You can use the XCOM communication stack with MySQL 8.0.27, or higher, but it must be explicitly defined in the creation or reboot commands.

    XCOM secures group communication connections and distributed recovery connections between members using the Group Replication implementation of the security protocols, including TLS/SSL and the use of an allowlist for incoming Group Communication System (GCS) connections.

Selecting Communication Stack

The communication stack selection is set by the communicationStack option in the dba.createCluster() and <clusterSet>.createReplicaCluster() commands.

For example:

js> dba.createCluster("testCluster", {communicationStack: "mysql"})

js> clusterset.createReplicaCluster("hostname:3306", "replica", {communicationStack: "mysql"})

Each command checks the MySQL server to ensure it can use the MYSQL protocol. If it does not support MYSQL, an error is displayed and the command fails.

The addInstance, rejoinInstance, and rescan commands also check the target instance for communication stack support and set the required configuration options accordingly.

  • ipAllowList.

    • XCOM: Set automatically, by default.

    • MYSQL: unset. ipAllowList is not permitted with the MYSQL communication stack.

  • localAddress

    • XCOM: (advanced option, not recommended) Automatically generated. Requires additional network address, or port.

    • MYSQL: Automatically updated to use the value reported by the MySQL server.

      localAddress can be defined manually, but the port must be one MySQL is listening on, as defined by bind_address.

  • Updates the SSL settings. The same SSL settings are used by both communication protocols.

Switching Communication Stack

It is possible to switch communication stack during a reboot from complete outage operation.

For example:

js> dba.rebootClusterFromCompleteOutage("testcluster", {switchCommunicationStack: "mysql"})

Switching from the MYSQL protocol to XCOM requires an additional network address for the localAddress and may also require ipAllowList values.

If switching from the XCOM to the MYSQL stack, the following changes are made:

  • ipAllowList is unset.

  • localAddress is updated to use the value reported by the MySQL server.

  • Updates the SSL settings. The settings are copied from the MySQL server if memberSslMode is set to VERIFY_CA or VERIFY_IDENTITY. No changes are made if memberSslMode is set to REQUIRED.


    group_replication_recovery_use_ssl is always enabled if memberSslMode is set to any value other than DISABLED.