As of MySQL Shell 8.0.30, 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
.
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 ofXCOM
. -
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.
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 theMYSQL
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 bybind_address
.
-
groupSeeds
XCOM
: automatically generated. Requires additional network address, or port.MYSQL
: is automatically updated to use thebind_address
value used by each MySQL instance.
-
Updates the SSL settings. The same SSL settings are used by both communication protocols. The settings are copied from the MySQL server if
memberSslMode
is set to VERIFY_CA or VERIFY_IDENTITY. No changes are made ifmemberSslMode
is set to REQUIRED.Notegroup_replication_recovery_use_ssl
is always enabled ifmemberSslMode
is set to any value other than DISABLED.
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.groupSeeds
is updated to use thebind_address
value used by each MySQL instance.-
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 ifmemberSslMode
is set to REQUIRED.Notegroup_replication_recovery_use_ssl
is always enabled ifmemberSslMode
is set to any value other than DISABLED.