【MySQL Shell】8.4 部署 InnoDB ClusterSet

按照以下步骤部署沙盒或生产 InnoDB ClusterSet 部署。沙盒部署是所有 MySQL 服务器实例和其他软件在一台机器上运行的地方。对于生产部署,服务器实例和其他软件位于不同的计算机上。

此过程假设您已经拥有 第 8.1 节 “InnoDB ClusterSet 的要求” 中列出的以下组件:

  • 满足 第 8.1 节“ InnoDB ClusterSet 的要求” 中所述要求的现有 InnoDB Cluster 。这是 InnoDB ClusterSet 部署支持的主要集群。
  • MySQL Shell 8.0.27 或更高版本,连接到现有的 InnoDB Cluster 。MySQL Shell 的 AdminAPI 命令用于部署过程。
  • MySQL Router 8.0.27 或更高版本,以针对 InnoDB ClusterSet 进行引导。您已经针对现有 InnoDB Cluster 引导的 MySQL Router 实例可以在 InnoDB ClusterSet 部署中重用,但您需要再次引导它们以实现 InnoDB ClusterSet 配置。
  • 许多独立的 MySQL Server 实例(不是 InnoDB Cluster 或 InnoDB ReplicaSet 的一部分)组成一个或多个副本集群。它们必须满足 第 8.1 节 “InnoDB ClusterSet 的要求” 中规定的要求。建议每个副本群集中至少有三个成员服务器,以允许出现故障。

在 InnoDB ClusterSet 部署过程中使用的用户帐户是来自主集群的 InnoDB Cluster 服务器配置帐户。这是使用 dba.configureInstance() 命令和 clusterAdmin 选项在主集群的成员服务器上创建的帐户。每个成员服务器只有一个服务器配置帐户。集群中的每个成员服务器都必须使用相同的用户名和密码,您需要在 InnoDB ClusterSet 部署中的所有服务器上创建它。可以将 root 帐户用作 InnoDB Cluster 服务器配置帐户,但不建议这样做,因为这意味着集群中每个成员服务器上的 root 帐户必须具有相同的密码。有关更多信息,请参阅 第 8.3 节“ InnoDB ClusterSet 的用户帐户”

要搭建 InnoDB ClusterSet 部署,请执行以下步骤:

  1. 使用 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 <schema> to set one.
    <ClassicSession:icadmin@127.0.0.1:3310>
    

    在此示例中:
    icadmin@127.0.0.1:3310 是 InnoDB Cluster 中在线的任何成员服务器实例的类似 URI 的连接字符串。
    类似URI的连接字符串由以下元素组成:

    • icadmin 是 InnoDB Cluster 服务器配置帐户的用户名。
    • 127.0.0.1:3310 是成员服务器实例的主机和端口,如 cluster.status() 命令所示。
  2. 发出 dba.getCluster() 命令以获取表示 InnoDB Cluster 的 Cluster 对象,将其分配给一个变量,以便您可以使用它。例如:

    mysql-js> cluster1 = dba.getCluster()
    <Cluster:clusterone>
    

    在本例中,clusterone 是现有 InnoDB Cluster 的名称,如 cluster.status() 命令返回的 clusterName 字段所示,返回的 Cluster 对象被分配给变量 cluster1

    当您使用 InnoDB Cluster 服务器配置帐户连接到服务器实例时,按上面这样做很重要。返回的对象默认使用获取的帐户进行需要权限的操作。InnoDB ClusterSet 部署过程中的某些操作需要权限,存储在对象中的默认用户帐户用于此操作,因此该过程不需要存储任何其他用户帐户。

  3. 使用 Cluster 对象执行 cluster.createClusterSet() 命令,来创建一个使用现有 InnoDB Cluster 作为其主集群的 InnoDB ClusterSet ,例如:

    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>
    
    • 在 InnoDB ClusterSet 部署中使用 clusterSetReplicationSslMode 选项如果你想要要求或禁用复制通道的加密(TLS/SSL)。默认设置 AUTO ,如果服务器实例支持则启用加密,否则禁用。REQUIRED 启用所有复制通道的加密,DISABLED 禁用所有复制通道的加密。例如:
      mysql-js> myclusterset = cluster1.createClusterSet('testclusterset', {dryRun: true, clusterSetReplicationSslMode: 'REQUIRED'})
      

    当执行 cluster.createClusterSet() 命令时,MySQL Shell 会检查目标 InnoDB Cluster 是否符合成为 InnoDB ClusterSet 部署中主集群的要求,如果不符合,则返回错误。如果目标 InnoDB Cluster 满足要求,MySQL Shell 将执行以下设置任务:

    • 更新元数据模式(metadata schema)以包括 InnoDB ClusterSet 元数据。
    • 在所有成员服务器上将 skip_replica_start 系统变量设置为 ON ,以便复制线程不会自动启动。
    • 将目标 InnoDB Cluster 添加到元数据中的 InnoDB ClusterSet ,并将其标记为主集群。
    • 返回表示 InnoDB ClusterSet 的 ClusterSet 对象。
  4. 使用返回的 ClusterSet 对象发出 clusterSet.status() 命令,验证您创建的 InnoDB 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."
    }
    

    有关 clusterSet.status() 命令输出的更多信息和说明,请参阅 第 8.6 节 “InnoDB ClusterSet 的状态和拓扑”

    如果您想在任何时候(例如在重新启动 MySQL Shell 之后)获取表示已连接服务器实例的 InnoDB ClusterSet 的 ClusterSet 对象,请使用 dba.getClusterSet()cluster.getClusterSet() 命令。例如:

    mysql-js> myclusterset = dba.getClusterSet()
    <ClusterSet:testclusterset>
    

    将返回的 ClusterClusterSet 对象分配给变量,可以使用对象的方法对 Cluster 或 ClusterSet 执行进一步的操作。返回的对象使用独立于 MySQL Shell 全局会话的新会话。这确保了如果您更改 MySQLShell 全局会话,ClusterClusterSet 对象将保持其与服务器实例的会话。请注意,当您使用该对象时,从中获取该对象的服务器实例必须在 InnoDB ClusterSet 中仍然在线。如果该服务器实例脱机,该对象将不再工作,您需要从仍然联机的服务器重新获取该对象。

  5. 通过使用 clusterAdmin 选项发出 dba.configureInstance() 命令,在将成为副本集群一部分的每个独立服务器实例上创建 InnoDB Cluster 服务器配置帐户。要创建的帐户是主集群的 InnoDB Cluster 服务器配置帐户,用于创建 ClusterSet 。 不要指定任何 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.
    

    在该示例中,root@127.0.0.1:4410 是独立服务器的类似 URI 的连接字符串,icadmin 是将在实例上创建的 InnoDB Cluster 服务器配置帐户的用户名。为了更好的安全性,请在交互提示中为 InnoDB Cluster 服务器配置帐户指定密码,如示例所示,也可以使用 clusterAdminPassword 选项提供密码。dba.configureInstance() 命令自动授予帐户所需的权限,但如果您愿意,也可以手动设置帐户,授予其手动配置 InnoDB Cluster 管理员帐户中列出的权限。有关 dba.configureInstance() 命令及其选项的更多详细信息,请参阅 第 7.4.2 节 “配置用于 InnoDB Cluster 的生产实例”

    当您执行 dba.configureInstance() 时,MySQLShell 会验证服务器实例是否满足与 InnoDB Cluster 一起使用的要求。当您发出创建副本集群并向其添加实例的命令时,将检查 InnoDB ClusterSet 的要求。

  6. 使用 InnoDB Cluster 服务器配置帐户连接到已在 InnoDB ClusterSet 部署中的主集群中的任何活动实例。确保您仍然拥有创建 InnoDB ClusterSet 时返回的 ClusterSet 对象,或者使用 dba.getClusterSet()cluster.getClusterSet() 再次获取该对象。同样,当您使用 InnoDB Cluster 服务器配置帐户连接到服务器实例时,执行此操作非常重要。存储在对象中的默认用户帐户用于 InnoDB ClusterSet 部署过程中的某些操作,而不考虑您在连接上指定的帐户。

  7. 使用 *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。名称在 InnoDB ClusterSet 中必须是唯一的,并且必须符合 InnoDB Cluster 的命名要求。只能使用 字母数字字符连字符(-)下划线(_)句点(.)并且名称不能以数字开头 。最大长度为 63 个字符。集群名称区分大小写。
    • 如果要执行检查并记录更改而不实际执行,请使用 dryRun 选项。
    • 使用 interactive 选项启用或禁用配置方法的确认提示。默认值是 MySQLShell 的 useWizards选项的值。
    • 如果要选择资源调配方法,请使用 recoveryMethod 选项。如果未将其指定为选项,则使用默认设置 AUTO 。在这种情况下,该函数将服务器实例上的 GTID 集与主集群上的 GTID 集进行比较,并尝试确定最合适的配置方法。如果无法确定这一点,则功能会提示您选择一种配置方法,如果您不处于交互模式,则会取消该操作。

    配置过程(称为 分布式恢复)可以使用克隆,其中服务器实例的状态被从集群中现有成员服务器获取的物理快照完全覆盖。要提前选择此选项,请指定 CLONE 设置。另一种方法是从现有成员服务器的二进制日志(在本例中是主集群的成员)进行增量状态传输。这里,服务器实例从主集群接收并应用它尚未拥有的事务。要提前选择此选项,请指定 INCREMENTAL 设置。

    • 如果要选择特定服务器以提供覆盖当前服务器的快照(如果通过克隆执行分布式恢复),请使用 cloneDonor 选项。默认情况下,该操作选择主集群的辅助成员,如果没有辅助成员,则选择主成员。所选服务器实例必须是 InnoDB ClusterSet 中主集群的成员。指定主机和端口号。此选项不支持 IPv6 地址。
    • 使用 recoveryProgress 选项为分布式恢复进程指定详细级别( 012 )。 设置 0 不显示进度信息,1 显示详细的静态进度信息,2 使用进度条显示详细的动态进度信息。如果标准输出是终端,则默认值为 2, 否则默认值为 1
    • 如果要设置超时,以等待服务器实例在配置并建立 ClusterSet 复制通道后与主集群同步,请使用 timeout 选项。默认情况下没有超时。
    • 使用 manualStartOnBoot 选项指定组复制是自动启动并在 MySQL 服务器启动时重新加入集群,还是必须手动启动。默认值 false 表示组复制自动启动。
    • 使用 communicationStack 选项定义成员之间如何使用 XCOMMYSQL 协议进行通信。请参阅 第 7.5.9 节 “配置组复制通信堆栈”

    如果您使用的是 MySQL 8.0.27 或更高版本,则默认和推荐的协议是 MySQL

    • 如果要为副本 InnoDB Cluster 配置组复制设置,可以使用 memberSslModeipAllowlistlocalAddressexitStateActionmemberWeightconsistencyexpelTimeoutautoRejoinTries 选项。这些选项的工作方式与不属于 ClusterSet 的 InnoDB Cluster 的工作方式相同。有关选项的详细信息,请参阅 第 7.5 节 “配置 InnoDB Cluster” 。(注意ipAllowlistlocalAddress 仅适用于 XCOM 通信堆栈。)
    • 可以使用选项 localAddressgroupName 设置组复制的本地地址和组标识符。但是,不建议这样做,因为不正确的值可能会导致组复制中的错误。只有在 InnoDB ClusterSet 设置过程为这些选项选择的值出现问题时,才使用这些选项。
    • 使用 MySQL Shell 8.0.28 及更高版本创建 InnoDB ClusterSet 时,如果您有安全要求,即 AdminAPI 自动创建的所有帐户都有严格的身份验证要求,则可以为 ClusterSet 的 replicationAllowedHost 配置选项设置一个值。MySQL Shell 的 replicationAllowedHost 选项允许您将 ClusterSet 的内部管理复制帐户设置为严格的基于子网的筛选器,而不是默认的通配符值 %replicationAllowed Host 选项采用字符串值。例如,要创建名为 my_clusterset_domain 的集群并将 replicationAllowedHost 选项设置为 192.0.2.0/24, 请执行:
    mysql-js> <Cluster>.createClusterSet('my_clusterset_domain', {replicationAllowedHost:'192.0.2.0/24'})
    

    当您发出 clusterSet.createReplicaCluster() 命令时,MySQL Shell 会检查目标服务器实例是否符合成为 InnoDB ClusterSet 部署中副本 InnoDB Cluster 中主服务器的要求,如果不符合,则返回错误。如果实例满足要求,MySQL Shell 将执行以下设置任务:

    • 创建 ClusterSet 复制通道 clusterset_replication ,并使用随机密码创建复制用户。这是目标实例和主集群的主服务器之间的异步复制通道,由 InnoDB ClusterSet 管理。根据 InnoDB ClusterSet 的 clusterSetReplicationSslMode 选项为通道配置加密。MySQL Shell 验证复制设置是否正常,如果不正常,则返回错误。
    • 使用主 InnoDB Cluster 的数据集设置 MySQL Server 实例,并使用选定的恢复方法同步 GTID 集。请注意,如果 ClusterSet 的成员服务器中有大量数据,分布式恢复可能需要几个小时。
    • 在服务器实例上添加 InnoDB Cluster 管理员帐户和 MySQL Router 管理员帐户。如果通过二进制日志中的状态传输来配置实例,则配置过程包括创建帐户的事务,或者在克隆期间传输帐户。无论哪种方式,这些帐户都可以在服务器实例上使用。有关更多信息,请参阅 第 8.3 节 “InnoDB ClusterSet 的用户帐户”
    • 为副本集群配置并启动组复制。InnoDB ClusterSet 副本群集创建过程将覆盖您在 clusterSet.createReplicaCluster() 命令中为其指定新设置的任何现有持久化的组复制配置选项。它还始终覆盖以下配置选项,即使您没有在命令中指定它们: group_replication_group_namegroup_replication_group_seedsgroup_replication_local_addressgroup_replication_view_change_uuidgroup_repliction_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 对象。
  8. 使用 clusterSet.createReplicaCluster() 为副本集群返回的 Cluster 对象,执行 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: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 命令的更多详细信息,请参阅 第 7.4.4 节 “向 InnoDB Cluster 添加实例”

    如果需要再次获取副本集群的 Cluster 对象,请使用 InnoDB Cluster 服务器配置帐户连接到副本集群中的任何活动实例,并发出 dba.getCluster() 。 该帐户用于搭建过程中的某些操作。如果安装过程发现独立服务器实例上不存在该帐户,则返回一个错误,您需要发出 dba.configureInstance() 来创建该帐户。

    命令成功后,服务器实例将添加到副本集群,并为 InnoDB ClusterSet 提供数据。克隆操作的供体将来自副本集群,而不是主集群。

  9. 重复 cluster.addInstance 操作,将所有独立服务器实例添加到副本集群。为了容错,建议至少三个实例。副本集群中最多可以有九个成员服务器,这是基础的组复制技术中的一个限制。

  10. 验证完成的副本集群和 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."
    }
    

    有关 clusterSet.status() 命令输出的更多信息,请参阅 第 8.6 节 “InnoDB ClusterSet 的状态和拓扑”

  11. 根据需要,通过对另一组独立实例重复上述步骤,添加更多副本集群。InnoDB ClusterSet 部署中可以拥有的副本集群数量没有定义的限制。每种情况下的流程都是相同的,总结如下:

    • 通过使用 clusterAdmin 选项执行 dba.configureInstance() 命令,在每个独立服务器实例上创建 InnoDB Cluster 服务器配置帐户。
    • 当您使用 InnoDB Cluster 服务器配置帐户连接到 InnoDB ClusterSet 的成员时,使用 dba.getClusterSet() cluster.getClusterSet() 获取 ClusterSet 对象。您可以从主集群或已创建的副本集群中的任何成员服务器获取该对象。
    • 使用 ClusterSet 对象执行 clusterSet.createReplicaCluster() 命令以创建副本集群,指定一个独立服务器实例。
    • 使用 clusterSet.createReplicaCluster() 为副本集群返回的 Cluster 对象,执行 cluster.addInstance 命令,指定另一个独立服务器实例。
    • 重复 cluster.addInstance 操作,将所有独立服务器实例添加到副本集群。
    • 验证完成的副本集群和 InnoDB ClusterSet 部署是否正常。例如,通过使用带有扩展输出的 cluster.addInstance 命令。
  12. 对 InnoDB ClusterSet 引导(bootstrap) MySQL Router 实例,以管理应用程序流量,并根据需要进行配置。默认情况下,MySQL Router 将所有读写请求定向到 InnoDB ClusterSet 部署中当前的主集群,但您可以将 MySQL Router 实例配置为仅将流量路由到特定集群。有关说明,请参阅 8.5 将 MySQL Router 与 InnoDB ClusterSet 集成

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

独上西楼影三人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值