PDF（美国标准信封） - 2.3Mb
PDF（A4） - 2.3Mb
按照以下步骤部署沙盒或生产环境 InnoDB ClusterSet 部署。沙盒部署是指所有 MySQL 服务器实例和其他软件都在一台机器上运行。对于生产环境部署，服务器实例和其他软件位于不同的机器上。
此过程假定您已经具备以下组件，如 第 8.1 节“InnoDB ClusterSet 需求” 中所列。
一个现有的 InnoDB 集群，符合 第 8.1 节“InnoDB ClusterSet 需求” 中规定的需求。这是 InnoDB ClusterSet 部署支持的主集群。
连接到现有 InnoDB 集群的 MySQL Shell。MySQL Shell 的 AdminAPI 命令在部署过程中使用。
MySQL Router，用于引导 InnoDB ClusterSet。您之前已经针对现有 InnoDB 集群引导的 MySQL Router 实例可以在 InnoDB ClusterSet 部署中重用，但您需要重新引导它们以实现 InnoDB ClusterSet 配置。
一些独立的 MySQL 服务器实例（不是 InnoDB 集群或 InnoDB ReplicaSet 的一部分），用于创建一个或多个副本集群。它们必须满足 第 8.1 节“InnoDB ClusterSet 需求” 中规定的需求。建议每个副本集群中至少有三个成员服务器，以容忍故障。
您在 InnoDB ClusterSet 部署过程中使用的用户帐户是主集群的 InnoDB 集群服务器配置帐户。这是使用 dba.configureInstance() 命令（使用 clusterAdmin 选项）在主集群的成员服务器上创建的帐户。每个成员服务器只有一个服务器配置帐户。在集群中的每个成员服务器上必须使用相同的用户名和密码，并且您需要在 InnoDB ClusterSet 部署中的所有服务器上创建它。可以使用 root 帐户作为 InnoDB 集群服务器配置帐户，但不建议这样做，因为这意味着集群中每个成员服务器上的 root 帐户必须具有相同的密码。有关更多信息，请参阅 第 8.3 节“InnoDB ClusterSet 用户帐户”。
要设置 InnoDB ClusterSet 部署，请按照以下步骤操作
-
使用 InnoDB 集群服务器配置帐户，使用 MySQL Shell 连接到现有 InnoDB 集群中的任何成员服务器。例如
mysql-js> \connect [email protected]:3310 Creating a session to '[email protected]:3310' Please provide the password for '[email protected]:3310': ************** Save password for '[email protected]: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 <schema> to set one. <ClassicSession:[email protected]:3310>在此示例中
-
icadmin@127.0.0.1:3310URI 类连接字符串包含以下元素
icadmin127.0.0.1:3310cluster.status()
-
-
发出
dba.getCluster()命令获取代表 InnoDB 集群的Cluster对象，将其分配给一个变量，以便您可以使用它。例如mysql-js> cluster1 = dba.getCluster() <Cluster:clusterone>在此示例中，
clusterone是现有 InnoDB 集群的名称，如cluster.status()clusterName字段所示，返回的Cluster对象分配给变量cluster1。使用 InnoDB 集群服务器配置帐户连接到服务器实例时执行此操作非常重要。返回的对象默认情况下使用它获取的帐户，用于需要权限的操作。InnoDB ClusterSet 部署过程中的某些操作需要权限，并且使用对象中存储的默认用户帐户来执行此操作，因此该过程无需存储任何其他用户帐户。
-
发出
cluster.createClusterSet()Cluster对象创建 InnoDB ClusterSet，将现有 InnoDB 集群作为主集群。例如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. <ClusterSet:testclusterset>在此示例中，
clusterone是现有 InnoDB 集群的名称，cluster1是分配返回的Cluster对象的变量，testclusterset是您要创建的 InnoDB ClusterSet 的名称，myclusterset是分配返回的ClusterSet对象的变量。-
domainName参数是必需的，它指定您要创建的 InnoDB ClusterSet 部署的名称（示例中为testclusterset）。domainName必须非空，且长度不超过 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. -
如果您想在 InnoDB ClusterSet 部署中要求或禁用复制通道的加密（TLS/SSL），请使用
clusterSetReplicationSslMode选项。默认设置AUTO，如果服务器实例支持加密，则启用加密；如果服务器实例不支持加密，则禁用加密。REQUIRED为所有复制通道启用加密，DISABLED为所有复制通道禁用加密。例如mysql-js> myclusterset = cluster1.createClusterSet("testclusterset", {clusterSetReplicationSslMode: 'REQUIRED'})
clusterSetReplicationSslMode支持VERIFY_CA和VERIFY_IDENTITY。例如mysql-js> myclusterset = cluster.createClusterSet("testclusterset", {"clusterSetReplicationSslMode":"VERIFY_IDENTITY"});当您发出
cluster.createClusterSet()更新元数据架构以包含 InnoDB ClusterSet 元数据。
在所有成员服务器上将
skip_replica_start系统变量设置为ON，以便不会自动启动复制线程。在元数据中将目标 InnoDB 集群添加到 InnoDB ClusterSet，并将其标记为主集群。
返回代表 InnoDB ClusterSet 的
ClusterSet对象。
-
-
使用返回的
ClusterSet对象，发出clusterSet.status()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()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." }有关
clusterSet.status()如果您想随时获取代表连接服务器实例的 InnoDB ClusterSet 的
ClusterSet对象，例如在重新启动 MySQL Shell 之后，请使用dba.getClusterSet()或cluster.getClusterSet()mysql-js> myclusterset = dba.getClusterSet() <ClusterSet:testclusterset>将返回的
Cluster或ClusterSet对象分配给一个变量，可以使您使用对象的 method 对集群或 ClusterSet 执行进一步的操作。返回的对象使用新的会话，独立于 MySQL Shell 的全局会话。这确保了如果您更改 MySQL Shell 全局会话，Cluster或ClusterSet对象会保持其与服务器实例的会话。请注意，当您使用对象时，您从中获取它的服务器实例必须仍在 InnoDB ClusterSet 中在线。如果该服务器实例脱机，该对象将不再起作用，您需要从仍然在线的服务器中重新获取它。 -
通过使用
clusterAdmin选项发出dba.configureInstance()命令，在每个将成为副本集群一部分的独立服务器实例上创建 InnoDB 集群服务器配置帐户。要创建的帐户是主集群的 InnoDB 集群服务器配置帐户，您之前使用它创建了 ClusterSet。不要指定任何 InnoDB 集群管理员帐户（使用cluster.setupAdminAccount()您无需事先连接到独立的服务器实例，因为连接字符串包含在命令中。在连接字符串中，使用具有完整 MySQL 管理员权限的帐户，包括创建帐户的权限（
WITH GRANT OPTION）。在此示例中，使用root帐户mysql-js> dba.configureInstance('[email protected]:4410', {clusterAdmin: 'icadmin'}) Please provide the password for '[email protected]:4410': *************** Save password for '[email protected]: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.在本例中，
root@127.0.0.1:4410icadminclusterAdminPassword选项提供密码。dba.configureInstance()命令会自动授予帐户所需的权限，尽管您可以根据需要手动设置帐户，并授予其在 手动配置 InnoDB Cluster 管理员帐户 中列出的权限。有关dba.configureInstance()命令及其选项的更多详细信息，请参见 第 7.4.2 节，“为 InnoDB Cluster 使用配置生产实例”。当您发出
dba.configureInstance()命令时，MySQL Shell 会验证服务器实例是否满足与 InnoDB Cluster 一起使用的要求。当您发出创建副本集群并将实例添加到副本集群的命令时，将检查 InnoDB ClusterSet 的要求。 使用 InnoDB Cluster 服务器配置帐户连接到主集群中任何已在 InnoDB ClusterSet 部署中的活动实例。确保您仍然拥有在创建 InnoDB ClusterSet 时返回的
ClusterSet对象，或者使用dba.getClusterSet()或cluster.getClusterSet()-
使用
ClusterSet对象发出clusterSet.createReplicaCluster()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: Completed NOTE: 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 topology Replica Cluster 'clustertwo' successfully created on ClusterSet 'testclusterset'. <Cluster:clustertwo>对于
clusterSet.createReplicaCluster()参数
instance是必需的，它指定独立服务器的 MySQL Server 实例的主机和端口号。此服务器实例将是副本集群的主服务器。在上面的示例命令中，它是127.0.0.1:4410参数
clusterName是必需的，它指定副本集群的标识符。在上面的示例命令中，使用了clustertwo如果要执行验证并记录更改而不实际执行它们，请使用
dryRun选项。-
如果要选择预配方法，请使用
recoveryMethod选项。如果您没有将其指定为选项，则将使用默认设置AUTO。在这种情况下，该函数会将服务器实例上的 GTID 集与主集群上的 GTID 集进行比较，并尝试确定最合适的预配方法。如果无法确定，则该函数会提示您选择预配方法，或者如果您不在交互模式下，则取消操作。预配过程称为分布式恢复，可以使用克隆，其中服务器实例的状态将完全覆盖由集群中现有成员服务器的物理快照。要提前选择此方法，请指定
CLONE设置。另一种方法是从现有成员服务器的二进制日志（在本例中为主集群的成员）进行增量状态传输。在这里，服务器实例会接收并应用主集群中它尚未拥有的事务。要提前选择此方法，请指定INCREMENTAL设置。 如果要选择特定的服务器以提供覆盖当前服务器的快照（如果分布式恢复通过克隆进行），请使用
cloneDonor选项。默认情况下，该操作会选择主集群的辅助成员，或者在没有辅助成员的情况下选择主服务器。所选服务器实例必须是 InnoDB ClusterSet 中主集群的成员。指定主机和端口号。此选项不支持 IPv6 地址。使用
recoveryProgress选项指定分布式恢复过程的详细程度级别（0、1 或 2）。设置 0 不显示进度信息，1 显示详细的静态进度信息，2 显示使用进度条的详细动态进度信息。如果标准输出是终端，则默认值为 2，否则默认值为 1。如果要设置超时时间以等待服务器实例在预配后与主集群同步，并且已建立 ClusterSet 复制通道，请使用
timeout选项。默认情况下没有超时时间。使用
manualStartOnBoot选项指定 Group Replication 是在 MySQL 服务器启动时自动启动并重新加入集群，还是必须手动启动。默认值false表示 Group Replication 自动启动。-
使用
communicationStack选项定义成员如何相互通信，使用XCOM或MYSQL协议。参见 第 7.5.9 节，“配置 Group Replication 通信堆栈”。如果您使用的是 MySQL 8.0.27 或更高版本，则默认协议（也是推荐协议）是
MYSQL。 如果要配置副本 InnoDB Cluster 的 Group Replication 设置，则可以使用选项
memberSslMode、ipAllowlist、localAddress、exitStateAction、memberWeight、consistency、expelTimeout和autoRejoinTries。这些选项的工作方式与它们在不属于 ClusterSet 的 InnoDB Cluster 中的工作方式相同。有关这些选项的详细信息，请参见 第 7.5 节，“配置 InnoDB Cluster”。（注意：ipAllowlist和localAddress仅适用于XCOM通信堆栈。）可以使用选项
localAddress和groupName设置 Group Replication 本地地址和组标识符。但是，不建议这样做，因为不正确的值会导致 Group Replication 出现错误。只有在您已经遇到了使用 InnoDB ClusterSet 设置过程为这些项目选择的值导致的问题时，才使用这些选项。-
在创建 InnoDB ClusterSet 时，如果您有安全要求，即 AdminAPI 自动创建的所有帐户都具有严格的身份验证要求，则可以为 ClusterSet 的
replicationAllowedHost配置选项设置值。replicationAllowedHostMySQL Shell 选项允许您将 ClusterSet 的内部管理复制帐户设置为基于严格子网的过滤器，而不是默认的通配符值%。replicationAllowedHost选项接受字符串值。例如，要创建名为my_clusterset_domain的集群集并将replicationAllowedHost选项设置为192.0.2.0/24，请发出mysql-js> <Cluster>.createClusterSet('my_clusterset_domain', {replicationAllowedHost:'192.0.2.0/24'})如果更改 ClusterSet 上的
replicationAllowedHost，则用于集群之间复制通道的帐户将更改为仅允许来自您为replicationAllowedHost指定的值的连接。主机必须在主集群和副本集群中都是可访问的。如果不是，则集群之间没有复制。可以通过发出以下命令来修改创建后的 ClusterSet 以设置
replicationAllowedHostmysql-js> <Clusterset>.setOption('replicationAllowedHost','192.0.2.0/24')
当您发出
clusterSet.createReplicaCluster()创建 ClusterSet 复制通道
clusterset_replication，并创建具有随机密码的复制用户。这是目标实例与主集群的主服务器之间由 InnoDB ClusterSet 管理的异步复制通道。通道的加密根据 InnoDB ClusterSet 的clusterSetReplicationSslMode选项进行配置。MySQL Shell 会验证复制设置是否正常工作，如果它不正常工作，则会返回错误。使用所选的恢复方法，使用来自主 InnoDB Cluster 的数据集为 MySQL Server 实例预配，并同步 GTID 集。请注意，如果 ClusterSet 成员服务器中存在大量数据，则分布式恢复可能需要几个小时。
在服务器实例上添加 InnoDB Cluster 管理员帐户和 MySQL Router 管理员帐户。如果实例是通过从二进制日志传输状态进行预配的，则预配过程将包括创建帐户的事务，否则这些帐户将在克隆期间传输。无论哪种方式，这些帐户都将在服务器实例上可用。有关更多信息，请参见 第 8.3 节，“InnoDB ClusterSet 的用户帐户”。
为副本集群配置和启动 Group Replication。InnoDB ClusterSet 副本集群创建过程将覆盖您在
clusterSet.createReplicaCluster()group_replication_group_name、group_replication_group_seeds、group_replication_local_address、group_replication_view_change_uuid（版本 8.0.27 到 8.2.0，仅限于此）、group_replication_enforce_update_everywhere_checks。但是，您在使用服务器实例进行副本集群之前在其上更改的任何其他 Group Replication 配置选项都将保留原样。有关此方面的注意事项，请参见 第 8.1 节，“InnoDB ClusterSet 要求”。将系统变量
skip_replica_start设置为ON，以便复制线程不会在服务器上自动启动，并将系统变量super_read_only设置为ON，以便客户端无法将事务写入服务器。禁用 Group Replication 成员操作
mysql_disable_super_read_only_if_primary，以便在发生视图更改后，super_read_only保持在集群的主服务器上设置。启用组复制成员操作
mysql_start_failover_channels_if_primary将 ClusterSet 元数据传输到服务器实例，在 InnoDB ClusterSet 中创建副本集群，并将目标服务器实例添加为主服务器。
返回副本集群的
Cluster对象。
-
使用
clusterSet.createReplicaCluster()Cluster对象，发出一个命名另一个独立服务器实例的cluster.addInstancemysql-js> cluster2.addInstance('[email protected]: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:3310 Monitoring 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% Completed NOTE: 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如果需要再次获取副本集群的
Cluster对象，请使用 InnoDB 集群服务器配置帐户连接到副本集群中的任何活动实例，并发出dba.getCluster()。此帐户用于设置过程中的某些操作。如果设置过程发现该帐户在独立服务器实例上不存在，则会返回错误，您需要发出dba.configureInstance()来创建该帐户。当命令成功时，服务器实例将被添加到副本集群，并使用 InnoDB ClusterSet 的数据进行配置。克隆操作的捐赠者将来自副本集群，而不是主集群。
重复
cluster.addInstance-
验证已完成的副本集群和 InnoDB ClusterSet 部署是否正常。可以使用
cluster.status()clusterSet.status()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." }有关
clusterSet.status() -
根据需要添加更多副本集群，方法是使用一组不同的独立实例重复上述步骤。对于 InnoDB ClusterSet 部署中可以拥有的副本集群数量没有定义的限制。每个步骤的过程都相同，总结如下
使用带有
clusterAdmin选项的dba.configureInstance()命令，在每个独立服务器实例上创建 InnoDB 集群服务器配置帐户。使用
dba.getClusterSet()或cluster.getClusterSet()ClusterSet对象，当您使用 InnoDB 集群服务器配置帐户连接到 InnoDB ClusterSet 的成员时。您可以从主集群中的任何成员服务器或您已经创建的副本集群中的任何成员服务器获取该对象。使用
ClusterSet对象发出一个clusterSet.createReplicaCluster()使用
clusterSet.createReplicaCluster()Cluster对象，发出一个命名另一个独立服务器实例的cluster.addInstance重复
cluster.addInstance验证已完成的副本集群和 InnoDB ClusterSet 部署是否正常，例如使用带有扩展输出的
clusterSet.status()
针对 InnoDB ClusterSet 引导 MySQL 路由器实例以管理应用程序流量，并根据需要对其进行配置。默认情况下，MySQL 路由器会将所有读写请求定向到当前是 InnoDB ClusterSet 部署中的主集群的任何集群，但您可以配置一个 MySQL 路由器实例以仅将流量路由到特定集群。有关说明，请参阅 第 8.5 节，“将 MySQL 路由器与 InnoDB ClusterSet 集成”。