-
使用 MySQL Shell 连接到现有 InnoDB Cluster 中的任何成员服务器,使用 InnoDB Cluster 服务器配置帐户进行连接。例如:
解释mysql-js> \connect icadmin@127.0.0.1:3310
Creating a session to 'icadmin@127.0.0.1:3310'
Please provide the password for 'icadmin@127.0.0.1:3310': **************
Save password for 'icadmin@127.0.0.1:3310'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Closing old connection...
Your MySQL connection id is 59
Server version: 8.0.27-commercial MySQL Enterprise Server - Commercial
No default schema selected; type \use to set one.在这个例子中:
-
*
icadmin*@*
127.0.0.1:3310*
是 InnoDB Cluster 中任何在线成员服务器实例的类似 URI 的连接字符串。类似 URI 的连接字符串由以下元素组成:
-
*
icadmin*
是 InnoDB Cluster 服务器配置帐户的用户名。 -
*
127.0.0.1:3310*
是成员服务器实例的主机和端口,如命令所示*
cluster*.status()
。
-
-
发出
dba.getCluster()
命令来获取Cluster
代表 InnoDB Cluster 的对象,并将其分配给一个变量,以便您可以使用它。例如:mysql-js> cluster1 = dba.getCluster()
在本例中,
clusterone
是现有 InnoDB Cluster 的名称,如 命令clusterName
返回的字段 所示*
cluster*.status()
,返回的Cluster
对象被分配给变量cluster1
。当您使用 InnoDB Cluster 服务器配置帐户连接到服务器实例时,执行此操作非常重要。返回的对象默认使用获取它的帐户来执行需要权限的操作。 InnoDB ClusterSet部署过程中的一些操作需要权限,为此使用对象中存储的默认用户帐户,因此该过程不需要存储任何其他用户帐户。
-
*
cluster*.createClusterSet()
使用该对象 发出 命令Cluster
来创建 InnoDB ClusterSet,并将现有 InnoDB Cluster 作为主集群。例如:解释mysql-js> myclusterset = cluster1.createClusterSet('testclusterset')
A new ClusterSet will be created based on the Cluster 'clusterone'.
* Validating Cluster 'clusterone' for ClusterSet compliance.
* Creating InnoDB ClusterSet 'testclusterset' on 'clusterone'...
* Updating metadata...
ClusterSet successfully created. Use ClusterSet.createReplicaCluster() to add Replica Clusters to it.
在此示例中,
clusterone
是现有 InnoDB Cluster 的名称,是返回 对象分配到cluster1
的变量,是您正在创建的 InnoDB ClusterSet 的名称, 是返回对象分配到 的变量。Cluster``testclusterset``myclusterset``ClusterSet
-
该*
domainName
*参数是必需的,指定您正在创建的 InnoDB ClusterSet 部署的名称(testclusterset
在示例中)。只能使用字母数字字符、连字符 (-)、下划线 (_) 和句点 (.),并且名称不得以数字开头。最大长度为 63 个字符。 -
dryRun
如果您想执行验证并记录更改而不实际执行它们, 请使用该选项。例如:解释mysql-js> myclusterset = cluster1.createClusterSet('testclusterset', {dryRun: true})
* Validating Cluster 'clusterone' for ClusterSet compliance.NOTE: dryRun option was specified. Validations will be executed, but no changes will be applied.
* Creating InnoDB ClusterSet 'clusterset' on 'clusterone'...* Updating metadata...
dryRun finished.
-
clusterSetReplicationSslMode
如果您想要在 InnoDB ClusterSet 部署中要求或禁用复制通道的加密 (TLS/SSL), 请使用该选项。默认设置 ,AUTO
如果服务器实例支持加密,则启用加密;如果服务器实例不支持,则禁用加密。REQUIRED
启用所有复制通道的加密,并DISABLED
禁用所有复制通道的加密。例如:mysql-js> myclusterset = cluster1.createClusterSet("testclusterset", {clusterSetReplicationSslMode: 'REQUIRED'})
从 MySQL Shell 8.0.33 开始,
clusterSetReplicationSslMode
支持VERIFY_CA
和VERIFY_IDENTITY
.例如:mysql-js> myclusterset = cluster.createClusterSet("testclusterset", {"clusterSetReplicationSslMode":"VERIFY_IDENTITY"});
当您发出该
*
cluster*.createClusterSet()
命令时,MySQL Shell 会检查目标 InnoDB Cluster 是否符合成为 InnoDB ClusterSet 部署中主集群的要求,如果不符合则返回错误。如果目标InnoDB Cluster满足要求,MySQL Shell将执行以下设置任务:- 更新元数据架构以包含 InnoDB ClusterSet 元数据。
skip_replica_start
在所有成员服务器上将系统变量 设置为ON
,以便复制线程不会自动启动。- 将目标InnoDB Cluster添加到元数据中的InnoDB ClusterSet中,并将其标记为主集群。
- 返回
ClusterSet
表示 InnoDB ClusterSet 的对象。
-
-
*
clusterSet*.status()
通过使用返回的对象 发出命令来验证您创建的 InnoDB ClusterSet 部署是否正常ClusterSet
。例如:解释mysql-js> myclusterset.status()
{
"clusters": {
"clusterone": {
"clusterRole": "PRIMARY",
"globalStatus": "OK",
"primary": "127.0.0.1:3310"
}
},
"domainName": "testclusterset",
"globalPrimaryInstance": "127.0.0.1:3310",
"primaryCluster": "clusterone",
"status": "HEALTHY",
"statusText": "All Clusters available."
}
您还可以使用
*
cluster*.status()
命令来查看集群本身。或者,您可以选择扩展输出来*
clusterSet*.status()
查看 InnoDB ClusterSet 拓扑中集群的详细状态。例如:解释mysql-js> myclusterset.status({extended: 1})
{
"clusters": {
"clusterone": {
"clusterRole": "PRIMARY",
"globalStatus": "OK",
"primary": "127.0.0.1:3310",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"127.0.0.1:3310": {
"address": "127.0.0.1:3310",
"memberRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3330": {
"address": "127.0.0.1:3330",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
}
},
"transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-86,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
}
},
"domainName": "testclusterset",
"globalPrimaryInstance": "127.0.0.1:3310",
"metadataServer": "127.0.0.1:3310",
"primaryCluster": "clusterone",
"status": "HEALTHY",
"statusText": "All Clusters available."
}
有关命令输出的更多信息和描述, 请参阅第 8.6 节“InnoDB ClusterSet 状态和拓扑”
*
clusterSet*.status()
。如果您想
ClusterSet
随时获取表示连接的服务器实例的 InnoDB ClusterSet 的对象,例如在重新启动 MySQL Shell 后,请使用dba.getClusterSet()
或*
cluster*.getClusterSet()
命令。例如:mysql-js> myclusterset = dba.getClusterSet()
将返回的
Cluster
或ClusterSet
对象分配给变量使您能够使用该对象的方法对集群或 ClusterSet 执行进一步的操作。返回的对象使用一个新的会话,独立于 MySQL Shell 的全局会话。这确保了如果您更改 MySQL Shell 全局会话,Cluster
或ClusterSet
对象仍会维持其与服务器实例的会话。请注意,当您使用该对象时,从中获取该对象的服务器实例必须在 InnoDB ClusterSet 中仍然在线。如果该服务器实例脱机,该对象将不再工作,您将需要从仍然在线的服务器再次获取它。 -
dba.configureInstance()
通过发出带有该选项的命令 ,在将成为副本集群一部分的每个独立服务器实例上创建 InnoDB 集群服务器配置帐户clusterAdmin
。要创建的帐户是主群集中用于创建 ClusterSet 的 InnoDB Cluster 服务器配置帐户。不要指定任何 InnoDB Cluster 管理员帐户(使用 创建*
cluster*.setupAdminAccount()
)。这些将在配置过程中自动从主集群传输到副本集群。您不需要事先连接到独立服务器实例,因为连接字符串包含在命令中。在连接字符串中,使用具有完整 MySQL 管理员权限的帐户,包括创建帐户的权限 (
WITH GRANT OPTION
)。在此示例中,root
使用的帐户:解释mysql-js> dba.configureInstance('root@127.0.0.1:4410', {clusterAdmin: 'icadmin'})
Please provide the password for 'root@127.0.0.1:4410': ***************
Save password for 'root@127.0.0.1:4410'? [Y]es/[N]o/Ne[v]er (default No):
Configuring local MySQL instance listening at port 4410 for use in an InnoDB cluster...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.This instance reports its own address as 127.0.0.1:4410
Password for new account: **************
Confirm password: **************applierWorkerThreads will be set to the default value of 4.
The instance '127.0.0.1:4410' is valid to be used in an InnoDB cluster.
Cluster admin user 'icadmin' created.
The instance '127.0.0.1:4410' is already ready to be used in an InnoDB cluster.Successfully enabled parallel appliers.
在此示例中, 是独立服务器的类似 URI 的连接字符串,是将在实例上创建的 InnoDB 集群服务器配置帐户的用户名。为了提高安全性,请在交互式提示符处指定 InnoDB Cluster 服务器配置帐户的密码(如示例所示),或者也可以使用 选项提供密码 。该 命令会自动向该帐户授予所需的权限,但您也可以根据需要手动设置该帐户,并为其授予 手动配置 InnoDB 群集管理员帐户中列出的权限。有关该 命令及其选项 的更多详细信息,请参阅第 7.4.2 节 “配置生产实例以供 InnoDB 集群使用”。
*
root*@*
127.0.0.1:4410*``*
icadmin*``clusterAdminPassword``dba.configureInstance()``dba.configureInstance()
当您发出 时
dba.configureInstance()
,MySQL Shell 会验证服务器实例是否满足与 InnoDB Cluster 一起使用的要求。当您发出创建副本集群并向其添加实例的命令时,将检查 InnoDB ClusterSet 的要求。 -
使用 InnoDB Cluster 服务器配置帐户连接到 InnoDB ClusterSet 部署中已存在的主集群中的任何活动实例。确保您仍然拥有
ClusterSet
创建 InnoDB ClusterSet 时返回的对象,或者使用dba.getClusterSet()
或 再次获取它*
cluster*.getClusterSet()
。同样,当您使用 InnoDB Cluster 服务器配置帐户连接到服务器实例时,执行此操作很重要。无论您在连接上指定的帐户是什么,对象中存储的默认用户帐户都会用于 InnoDB ClusterSet 部署过程中的某些操作。 -
*
clusterSet*.createReplicaCluster()
使用该对象 发出 命令ClusterSet
来创建副本集群,并命名其中一个独立服务器实例。该服务器实例将是副本集群的主服务器实例。该命令返回Cluster
副本集群的一个对象,如果需要,您可以将其分配给变量。例如:解释mysql-js> cluster2 = myclusterset.createReplicaCluster("127.0.0.1:4410", "clustertwo", {recoveryProgress: 1, timeout: 10})
Setting up replica 'clustertwo' of cluster 'clusterone' at instance '127.0.0.1:4410'.A new InnoDB cluster will be created on instance '127.0.0.1:4410'.
Validating instance configuration at 127.0.0.1:4410...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.This instance reports its own address as 127.0.0.1:4410
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44101'. Use the
localAddress option to override.* Checking transaction state of the instance...
NOTE: The target instance '127.0.0.1:4410' has not been pre-provisioned (GTID set is empty). The
Shell is unable to decide whether replication can completely recover its state.
The safest and most convenient way to provision a new instance is through automatic clone
provisioning, which will completely overwrite the state of '127.0.0.1:4410' with a physical
snapshot from an existing clusterset member. To use this method by default, set the
'recoveryMethod' option to 'clone'.WARNING: It should be safe to rely on replication to incrementally recover the state of the new
Replica Cluster if you are sure all updates ever executed in the ClusterSet were done with GTIDs
enabled, there are no purged transactions and the instance used to create the new Replica Cluster
contains the same GTID set as the ClusterSet or a subset of it. To use this method by default,
set the 'recoveryMethod' option to 'incremental'.Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
Waiting for clone process of the new member to complete. Press ^C to abort the operation.
* Waiting for clone to finish...
NOTE: 127.0.0.1:4410 is being cloned from 127.0.0.1:3310
** Stage DROP DATA: CompletedNOTE: 127.0.0.1:4410 is shutting down...
* Waiting for server restart... ready
* 127.0.0.1:4410 has restarted, waiting for clone to finish...
** Stage FILE COPY: Completed
** Stage PAGE COPY: Completed
** Stage REDO COPY: Completed
** Stage FILE SYNC: Completed
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)Creating InnoDB cluster 'clustertwo' on '127.0.0.1:4410'...
Adding Seed Instance...
Cluster successfully created. Use Cluster.addInstance() to add MySQL instances.
At least 3 instances are needed for the cluster to be able to withstand up to
one server failure.* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4410 to 127.0.0.1:3310* Waiting for instance to synchronize with PRIMARY Cluster...
** Transactions replicated ############################################################ 100%
* Updating topologyReplica Cluster 'clustertwo' successfully created on ClusterSet 'testclusterset'.
对于
*
clusterSet*.createReplicaCluster()
命令:-
该*
instance
*参数是必需的,指定独立服务器的 MySQL Server 实例的主机和端口号。这是将成为副本集群的主服务器实例。在上面的示例命令中,这是*
127.0.0.1:4410*
. -
该*
clusterName
*参数是必需的,指定副本集群的标识符。在上面的示例命令中,*
clustertwo*
使用了。该名称在InnoDB ClusterSet中必须是唯一的,并且必须遵循InnoDB Cluster命名要求。只能使用字母数字字符、连字符 (-)、下划线 (_) 和句点 (.),并且名称不得以数字开头。最大长度为 63 个字符。集群名称区分大小写。 -
dryRun
如果您想执行验证并记录更改而不实际执行它们, 请使用该选项。 -
使用该
interactive
选项启用或禁用配置方法的确认提示。默认值是 MySQL ShelluseWizards
选项的值。 -
recoveryMethod
如果您想选择配置方法, 请使用该选项。如果您不指定此选项,AUTO
则使用默认设置。在这种情况下,该函数会将服务器实例上设置的 GTID 与主集群上设置的 GTID 进行比较,并尝试确定最合适的配置方法。如果无法确定,该功能会提示您选择配置方法,或者如果您未处于交互模式,则会取消操作。配置过程(称为分布式恢复)可以使用克隆,其中服务器实例的状态被从集群中现有成员服务器获取的物理快照完全覆盖。要提前选择此项,请指定
CLONE
设置。另一种方法是从现有成员服务器的二进制日志(在本例中是主集群的成员)进行增量状态传输。在这里,服务器实例从主集群接收并应用它尚未拥有的事务。要提前选择此项,请指定INCREMENTAL
设置。 -
cloneDonor
如果要选择特定服务器来提供覆盖当前服务器的快照(如果通过克隆执行分布式恢复), 请使用该选项。该操作默认选择主集群的辅助成员,如果没有可用的辅助成员,则选择主成员。所选服务器实例必须是 InnoDB ClusterSet 中主集群的成员。指定主机和端口号。此选项不支持 IPv6 地址。 -
使用该
recoveryProgress
选项指定分布式恢复过程的详细级别(0、1 或 2)。设置 0 显示无进度信息,1 显示详细的静态进度信息,2 使用进度条显示详细的动态进度信息。如果标准输出是终端,则默认值为 2,否则默认值为 1。 -
timeout
如果要设置超时以等待服务器实例在配置主集群并建立 ClusterSet 复制通道后与主集群同步, 请使用该选项。默认情况下没有超时。 -
使用该
manualStartOnBoot
选项指定组复制是在 MySQL 服务器启动时自动启动并重新加入集群,还是必须手动启动。默认值false
表示组复制自动启动。 -
使用该选项可以定义成员如何使用或协议
communicationStack
相互通信 。请参见 第 7.5.9 节 “配置组复制通信堆栈”。XCOM``MYSQL
如果您使用 MySQL 8.0.27 或更高版本,则默认且推荐的协议为
MYSQL
。 -
如果要为副本 InnoDB 集群配置组复制设置,则可以使用
memberSslMode
、ipAllowlist
、localAddress
、exitStateAction
、memberWeight
、consistency
、expelTimeout
和 选项。autoRejoinTries
这些选项的工作方式与针对不属于 ClusterSet 的 InnoDB Cluster 的工作方式相同。有关选项的详细信息,请参见 第 7.5 节 “配置 InnoDB Cluster”。 (****注意****:ipAllowlist
和localAddress
仅适用于XCOM
通信堆栈。) -
可以使用这些选项
localAddress
并groupName
设置组复制本地地址和组标识符。但是,不建议这样做,因为不正确的值可能会导致组复制出错。仅当 InnoDB ClusterSet 设置过程为这些项目选择的值出现问题时才使用这些选项。 -
使用MySQL Shell 8.0.28及更高版本创建InnoDB ClusterSet时,如果您有安全需求,即所有由AdminAPI自动创建的帐户都有严格的身份验证要求,您可以为
replicationAllowedHost
ClusterSet的配置选项设置一个值。 MySQLreplicationAllowedHost
Shell 选项允许您将 ClusterSet 的内部管理复制帐户设置为严格的基于子网的过滤器,而不是默认的通配符值%
。 该replicationAllowedHost
选项采用字符串值。例如,要创建一个名为 的集群集my_clusterset_domain
并将replicationAllowedHost
选项设置为192.0.2.0/24
,请发出:mysql-js> .createClusterSet('my_clusterset_domain', {replicationAllowedHost:'192.0.2.0/24'})
如果您
replicationAllowedHost
在 ClusterSet 上进行更改,则用于集群之间复制通道的帐户将更改为仅允许来自您指定的值的连接replicationAllowedHost
。该主机必须在主集群和副本集群中均可访问。如果不是,集群之间就没有复制。创建 ClusterSet 后可以通过发出以下命令来修改 ClusterSet 以设置 a
replicationAllowedHost
:mysql-js> .setOption('replicationAllowedHost','192.0.2.0/24')
当您发出该
*
clusterSet*.createReplicaCluster()
命令时,MySQL Shell 会检查目标服务器实例是否符合成为 InnoDB ClusterSet 部署中副本 InnoDB Cluster 中主服务器的要求,如果不符合则返回错误。如果实例满足要求,MySQL Shell 会执行以下设置任务:- 创建 ClusterSet 复制通道
clusterset_replication
,并创建具有随机密码的复制用户。这是目标实例和主集群的主服务器之间的异步复制通道,由 InnoDB ClusterSet 管理。根据clusterSetReplicationSslMode
InnoDB ClusterSet 的选项为通道配置加密。 MySQL Shell 验证复制设置是否正常工作,如果不正常则返回错误。 - 使用选定的恢复方法为 MySQL Server 实例配置来自主 InnoDB Cluster 的数据集并同步 GTID 集。请注意,如果 ClusterSet 的成员服务器中存在大量数据,则分布式恢复可能需要几个小时。
- 在服务器实例上添加 InnoDB Cluster 管理员帐户和 MySQL Router 管理员帐户。如果实例是通过二进制日志的状态传输来配置的,则配置过程包括创建帐户的事务,否则帐户将在克隆期间传输。无论哪种方式,这些帐户都可以在服务器实例上使用。有关更多信息,请参见 第 8.3 节“InnoDB ClusterSet 的用户帐户”。
- 配置并启动副本集群的组复制。 InnoDB ClusterSet 副本集群创建过程会覆盖您在
*
clusterSet*.createReplicaCluster()
命令中指定新设置的任何现有持久组复制配置选项。即使您没有在命令中指定以下配置选项,它也始终会覆盖它们:group_replication_group_name
、group_replication_group_seeds
、group_replication_local_address
、group_replication_view_change_uuid
和group_replication_enforce_update_everywhere_checks
。但是,在副本集群中使用服务器实例之前您在服务器实例上更改的任何其他组复制配置选项将保持原样。请参阅第 8.1 节“InnoDB ClusterSet 要求”中有关此的重要说明 。 skip_replica_start
将系统变量 设置 为ON
,以便复制线程不会在服务器上自动启动,并设置super_read_only
系统变量,以便客户端无法将事务写入服务器。- 禁用组复制成员操作
mysql_disable_super_read_only_if_primary
,以便super_read_only
在视图更改后在集群的主节点上保持设置。 - 启用组复制成员操作
mysql_start_failover_channels_if_primary
,以便为 ClusterSet 复制通道启用副本的异步连接故障转移。启用此功能后,如果正在复制的主节点脱机或进入错误状态,新的主节点当选后会在同一通道上开始复制。 - 将 ClusterSet 元数据传输到服务器实例,在 InnoDB ClusterSet 中创建副本集群,并将目标服务器实例添加到其中作为主服务器。
- 返回
Cluster
副本集群的对象。
-
-
使用
Cluster
为副本集群返回的对象*
clusterSet*.createReplicaCluster()
,发出*
cluster*.addInstance
命名另一个独立服务器实例的命令。该服务器实例将是副本集群中的辅助服务器实例。例如:解释mysql-js> cluster2.addInstance('icadmin@127.0.0.1:4420')
NOTE: The target instance '127.0.0.1:4420' has not been pre-provisioned (GTID set is empty). The
Shell is unable to decide whether clone based recovery is safe to use.
The safest and most convenient way to provision a new instance is through automatic clone
provisioning, which will completely overwrite the state of '127.0.0.1:4420' with a physical
snapshot from an existing cluster member. To use this method by default, set the
'recoveryMethod' option to 'clone'.Please select a recovery method [C]lone/[A]bort (default Clone): c
Validating instance configuration at localhost:4420...
NOTE: Instance detected as a sandbox.
Please note that sandbox instances are only suitable for deploying test clusters for use within
the same host.This instance reports its own address as 127.0.0.1:4420
Instance configuration is suitable.
NOTE: Group Replication will communicate with other members using '127.0.0.1:44201'. Use the
localAddress option to override.A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.Adding instance to the cluster...
* Waiting for the Cluster to synchronize with the PRIMARY Cluster...
** Transactions replicated ############################################################ 100%
* Configuring ClusterSet managed replication channel...
** Changing replication source of 127.0.0.1:4420 to 127.0.0.1:3310Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and
let it continue in background.
Clone based state recovery is now in progress.NOTE: A server restart is expected to happen as part of the clone process. If the
server does not support the RESTART command or does not come back after a
while, you may need to manually start it back.* Waiting for clone to finish...
NOTE: 127.0.0.1:4420 is being cloned from 127.0.0.1:4410
** Stage DROP DATA: Completed
** Clone Transfer
FILE COPY ############################################################ 100% Completed
PAGE COPY ############################################################ 100% Completed
REDO COPY ############################################################ 100% CompletedNOTE: 127.0.0.1:4420 is shutting down...
* Waiting for server restart... ready
* 127.0.0.1:4420 has restarted, waiting for clone to finish...
** Stage RESTART: Completed
* Clone process has finished: 72.61 MB transferred in about 1 second (~72.61 MB/s)State recovery already finished for '127.0.0.1:4420'
The instance '127.0.0.1:4420' was successfully added to the cluster.
有关该命令的更多详细信息
*
cluster*.addInstance
,请参见第 7.4.4 节 “将实例添加到 InnoDB 集群”。如果您需要再次获取
Cluster
副本集群的对象,请使用 InnoDB 集群服务器配置帐户连接到副本集群中的任何活动实例并发出dba.getCluster()
.该帐户用于设置过程中的一些操作。如果设置过程发现独立服务器实例上不存在该帐户,则会返回错误,并且您需要发出命令dba.configureInstance()
来创建该帐户。该命令成功后,服务器实例将添加到副本集群中,并为 InnoDB ClusterSet 提供数据。克隆操作的捐赠者将来自副本集群,而不是主集群。
-
重复该
*
cluster*.addInstance
操作将所有独立服务器实例添加到副本集群中。为了容忍故障,建议至少使用三个实例。副本集群中最多可以有九个成员服务器,这是底层组复制技术内置的限制。 -
验证已完成的副本集群和 InnoDB ClusterSet 部署是否正常。您可以使用
*
cluster*.status()
查看副本集群的命令和*
clusterSet*.status()
查看 InnoDB ClusterSet 部署的命令来执行此操作。或者,您可以选择扩展输出来*
clusterSet*.status()
查看所有集群的详细状态。例如:解释mysql-js> myclusterset.status({extended: 1})
{
"clusters": {
"clusterone": {
"clusterRole": "PRIMARY",
"globalStatus": "OK",
"primary": "127.0.0.1:3310",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"127.0.0.1:3310": {
"address": "127.0.0.1:3310",
"memberRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3330": {
"address": "127.0.0.1:3330",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
}
},
"transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
},
"clustertwo": {
"clusterRole": "REPLICA",
"clusterSetReplication": {
"applierStatus": "APPLIED_ALL",
"applierThreadState": "Waiting for an event from Coordinator",
"applierWorkerThreads": 4,
"receiver": "127.0.0.1:4410",
"receiverStatus": "ON",
"receiverThreadState": "Waiting for source to send event",
"source": "127.0.0.1:3310"
},
"clusterSetReplicationStatus": "OK",
"globalStatus": "OK",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"127.0.0.1:4410": {
"address": "127.0.0.1:4410",
"memberRole": "PRIMARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:4420": {
"address": "127.0.0.1:4420",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:4430": {
"address": "127.0.0.1:4430",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
}
},
"transactionSet": "0f6ff279-2764-11ec-ba06-00059a3c7a00:1-5,953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8",
"transactionSetConsistencyStatus": "OK",
"transactionSetErrantGtidSet": "",
"transactionSetMissingGtidSet": ""
}
},
"domainName": "testclusterset",
"globalPrimaryInstance": "127.0.0.1:3310",
"metadataServer": "127.0.0.1:3310",
"primaryCluster": "clusterone",
"status": "HEALTHY",
"statusText": "All Clusters available."
}
有关命令输出的更多信息 , 请参阅第 8.6 节“InnoDB ClusterSet 状态和拓扑”
*
clusterSet*.status()
。 -
通过对一组不同的独立实例重复上述步骤,根据需要添加更多副本集群。 InnoDB ClusterSet 部署中可以拥有的副本集群数量没有定义的限制。每种情况的过程都是相同的,总结如下:
dba.configureInstance()
通过发出带有该选项的命令 ,在每个独立服务器实例上创建 InnoDB Cluster 服务器配置帐户clusterAdmin
。- 当您使用 InnoDB Cluster 服务器配置帐户连接到 InnoDB ClusterSet 的成员时,使用或 获取
ClusterSet
对象 。您可以从主集群或已创建的副本集群之一中的任何成员服务器获取该对象。dba.getClusterSet()``*
cluster*.getClusterSet()
*
clusterSet*.createReplicaCluster()
使用该对象 发出 命令ClusterSet
来创建副本集群,并命名其中一个独立服务器实例。- 使用
Cluster
为副本集群返回的对象*
clusterSet*.createReplicaCluster()
,发出*
cluster*.addInstance
命名另一个独立服务器实例的命令。 - 重复该
*
cluster*.addInstance
操作将所有独立服务器实例添加到副本集群中。 - 验证已完成的副本集群和 InnoDB ClusterSet 部署是否正常,例如通过使用
*
clusterSet*.status()
具有扩展输出的命令。
-
针对 InnoDB ClusterSet 引导 MySQL Router 实例来管理应用程序流量,并根据需要进行配置。默认情况下,MySQL Router 将所有读取和写入请求定向到 InnoDB ClusterSet 部署中当前主集群的集群,但您可以将 MySQL Router 实例配置为仅将流量路由到特定集群。有关说明,请参阅 第 8.5 节,“将 MySQL Router 与 InnoDB ClusterSet 集成”。粗体