Once you have configured your instances, create an InnoDB ReplicaSet by completing the following steps:
-
Connect to an instance and use
dba.createReplicaSet()
to create a managed ReplicaSet that uses MySQL asynchronous replication, rather than MySQL Group Replication used by InnoDB Cluster. The MySQL instance, which MySQL Shell is connected to, is used as the initial primary of the ReplicaSet.The
dba.createReplicaSet()
operation performs several checks to ensure that the instance state and configuration are compatible with a managed ReplicaSet, and if so, a metadata schema is initialized on the instance.If the ReplicaSet is created successfully, a
ReplicaSet
object is returned. Therefore, it is best practice to assign the returnedReplicaSet
to a variable. This enables you to work with the ReplicaSet, for example by calling the<ReplicaSet>status()
operation. To create a ReplicaSet namedexample
on instancers-1
and assign it to thers
variable, issue:mysql-js> \connect root@rs-1:3306 ... mysql-js> var rs = dba.createReplicaSet("example") A new replicaset with instance 'rs-1:3306' will be created. * Checking MySQL instance at rs-1:3306 This instance reports its own address as rs-1:3306 rs-1:3306: Instance configuration is suitable. * Updating metadata... ReplicaSet object successfully created for rs-1:3306. Use rs.addInstance() to add more asynchronously replicated instances to this replicaset and rs.status() to check its status.
-
Use the returned
ReplicaSet
object to verify that the operation was successful. For example, this provides the
operation, which displays information about the ReplicaSet. The returnedReplicaSet
.status()ReplicaSet
is already assigned to the variablers
, so issue:mysql-js> rs.status() { "replicaSet": { "name": "example", "primary": "rs-1:3306", "status": "AVAILABLE", "statusText": "All instances available.", "topology": { "rs-1:3306": { "address": "rs-1:3306", "instanceRole": "PRIMARY", "mode": "R/W", "status": "ONLINE" } }, "type": "ASYNC" } }
This output shows that the ReplicaSet named
example
has been created, and that the primary isrs-1
. Currently, there is only one instance, and the next task is to add more instances to the ReplicaSet.
Replicas can verify the identity of the source and use client
SSL certificates for authentication. The following options were
added to dba.createReplicaSet
:
-
memberAuthType
: defines the authentication type used for the internal replication accounts. This option takes one of the following values:PASSWORD
: Account authenticates with password only.CERT_ISSUER
: Account authenticates with a client certificate, which must match the expected issuer. This value is equivalent toVERIFY_CA
.CERT_SUBJECT
: Account authenticates with a client certificate, which must match the expected issuer and subject. This value is equivalent toVERIFY_IDENTITY
.CERT_ISSUER_PASSWORD
: Account authenticates with a combination ofPASSWORD
andCERT_ISSUER
values.CERT_SUBJECT_PASSWORD
: Account authenticates with a combination ofPASSWORD
andCERT_SUBJECT
values.
certIssuer
: Defines the certificate issuer required for authentication ifmemberAuthType
containsCERT_ISSUER
orCERT_SUBJECT
.certSubject
: Defines the certificate subject of the instance. Required ifmemberAuthType
containsCERT_SUBJECT
.-
replicationSslMode
: Defines the authentication type of the replication channels in the replicaSet. This option takes one of the following values:DISABLED
: TLS encryption is disabled for the replication channel.REQUIRED
: TLS encryption is enabled for the replication channel.VERIFY_CA
: The same as REQUIRED, but additionally verifies the peer server TLS certificate against the configured Certificate Authority (CA) certificates.VERIFY_IDENTITY
: The same as VERIFY_CA, but additionally verifies that the peer server certificate matches the host to which the connection is attempted.AUTO
: TLS encryption is enabled if supported by the instance. Disabled if the instance does not support TLS.
For example:
mysql-js> myreplicaset = dba.createReplicaSet("replicaSet1",
{ "replicationSslMode": "VERIFY_IDENTITY", "memberAuthType":"CERT_SUBJECT",
"certIssuer":"/CN=MyCertAuthority", "certSubject": "/CN=mysql-5.local"});
As of MySQL Shell 8.0.32, all new replication channels are created with SSL enabled. This is not true for replication groups adopted with MySQL Shell 8.0.32. Their replication channels remain unencrypted.
When creating an InnoDB ReplicaSet using MySQL Shell 8.0.28 and
later, if you have security requirements that want all accounts
created automatically by AdminAPI to have strict authentication
requirements, you can set a value for the
replicationAllowedHost
configuration option
of the ReplicaSet. The replicationAllowedHost
MySQL Shell option allows you to set internally managed
replication accounts for a ReplicaSet to a strict subnet based
filter instead of the default wildcard value of
%
.The
replicationAllowedHost
option can take a
string value. For example, to set the
replicationAllowedHost
to
192.0.2.0/24
, issue:
mysql-js> var rs = dba.createReplicaSet('example', {replicationAllowedHost:'192.0.2.0/24'})
A new replicaset with instance 'rs-1:3306' will be created.
* Checking MySQL instance at rs-1:3306
This instance reports its own address as rs-1:3306
rs-1:3306: Instance configuration is suitable.
* Updating metadata...
ReplicaSet object successfully created for rs-1:3306.
Use rs.addInstance() to add more asynchronously replicated instances to this replicaset
and rs.status() to check its status.
An InnoDB ReplicaSet can be modified after creation to set the
variable replicationAllowedHost
through the
setOption
configuration option, by issuing:
mysql-js> rs.setOption('replicationAllowedHost', '192.0.2.0/24')