MySQL Shell包含AdminAPI，可通过 dba 全局变量及其相关方法访问。 该 dba 变量的方法使您能够部署，配置和管理InnoDB的集群。 例如，使用该 dba.createCluster() 方法创建InnoDB集群。

MySQL Shell为AdminAPI提供在线帮助。 要列出所有可用 dba 命令，请使用该 dba.help() 方法。 有关特定方法的联机帮助，请使用常规格式 object.help('methodname') 。 例如：

MySQL的-JS> dba.help('getCluster')

从元数据存储中检索群集。

句法

  dba.getCluster（[name] [，options]）

哪里

  name：参数，用于指定要返回的集群的名称。
  选项：包含其他选项的词典。

退货

  由给定名称或默认群集标识的群集对象。

描述

如果未指定name或为null，则将返回默认群集。

如果指定了name，并且找不到具有指定名称的集群，则会出现错误
将被提出。

options字典接受connectToPrimary选项，默认为
true表示shell自动连接到主要成员
集群。

例外

  以下场景中的MetadataError：

   - 如果元数据无法访问。
   - 如果元数据更新操作失败。

  以下场景中的ArgumentError：

   - 如果群集名称为空。
   - 如果群集名称无效。
   - 如果群集不存在。

  以下场景中的RuntimeError：

   - 如果当前连接不能用于组复制。

要测试高可用性是否有效，请通过终止实例来模拟意外停止。 群集检测到实例离开群集并重新配置自身的事实。 群集重新配置的确切方式取决于您使用的是单主群集还是多主群集，以及实例在群集中所服务的角色。

在单主模式下：

有关更多信息，请参见 第18.4.1.1节“单主模式” 。

在多主模式下：

有关更多信息，请参见 第18.4.1.2节“多主模式” 。

有多种方法可以模拟离开集群的实例，例如，您可以强制停止实例上的MySQL服务器，或者在 dba.killSandboxInstance() 测试沙箱部署时 使用AdminAPI 。 在此示例中，假设存在具有三个服务器实例的单主要沙箱集群部署，并且在端口3310处侦听的实例是当前主要部署。 模拟意外离开集群的实例：

MySQL的-JS> dba.killSandboxInstance(3310)

群集会检测到更改并自动选择新的主数据库。 假设您的会话连接到端口6446（默认的读写经典MySQL协议端口），MySQL路由器应检测到群集拓扑的更改并将会话重定向到新选择的主节点。 要验证这一点，请使用该 \sql 命令 在MySQL Shell中切换到SQL模式， 然后选择实例的 port 变量以检查会话被重定向到的实例。 注意第一个 SELECT 语句失败，因为与原始主节点的连接丢失。 这意味着当前会话已关闭，MySQL Shell会自动为您重新连接，当您再次发出命令时，将确认新端口。

MySQL的-JS> \sql
切换到SQL模式...命令以;结尾;
MySQL的-SQL> SELECT @@port;
错误：2013（HY000）：查询期间与MySQL服务器的连接丢失
全局会话断开了。
试图重新连接到'root @ localhost：6446'...
全球会议已成功重新连接。
MySQL的-SQL> SELECT @@port;
+ -------- +
| @@ port |
+ -------- +
| 3330 |
+ -------- +
1排（0.00秒）

在此示例中，端口3330处的实例已被选为新主节点。 这表明InnoDB集群为我们提供了自动故障转移，MySQL路由器自动将我们重新连接到新的主要实例，并且我们具有高可用性。

当MySQL路由器针对群集进行引导时，它会在其配置文件中记录服务器实例的地址。 如果在引导MySQL路由器之后将任何其他实例添加到群集，则不会自动检测它们，因此 不会 将它们用于连接路由。

要确保新添加的实例正确路由，您必须针对群集引导MySQL路由器以读取更新的元数据。 这意味着您必须重新启动MySQL路由器并包含该 --bootstrap 选项。

在从服务器实例创建生产部署之前，您需要检查每个实例上的MySQL是否已正确配置。 除了 dba.configureInstance() 在配置实例时检查配置，您还可以使用该 dba.checkInstanceConfiguration() 功能。 这可确保实例满足 第21.2.2节“InnoDB群集要求”， 而无需更改实例上的任何配置。 这不会 检查实例 上的任何数据，请参阅 检查实例状态 以获取更多信息。 以下演示了在运行的MySQL Shell中发布它：

MySQL的-JS> dba.checkInstanceConfiguration('ic@ic-1:3306')
请提供“ic @ ic-1：3306”的密码：***
验证ic-1：3306上的MySQL实例，以便在InnoDB集群中使用...

此实例将其自己的地址报告为ic-1
默认情况下，客户端和其他集群成员将通过此地址与其进行通信。
如果这不正确，则应更改report_host MySQL系统变量。

检查现有表是否符合组复制要求...
未检测到不兼容的表

检查实例配置...

需要修复一些配置选项：
+ -------------------------- + -------- + ------ ---------- + --------------------------------------- ----------- +
| 变量| 当前价值| 必需值| 注意|
+ -------------------------- + -------- + ------ ---------- + --------------------------------------- ----------- +
| binlog_checksum | CRC32 | 没有| 更新服务器变量|
| enforce_gtid_consistency | 关闭| ON | 更新只读变量并重新启动服务器
| gtid_mode | 关闭| ON | 更新只读变量并重新启动服务器
| server_id | 1 | | 更新只读变量并重新启动服务器
+ -------------------------- + -------- + ------ ---------- + --------------------------------------- ----------- +

请使用dba.configureInstance（）命令来修复这些问题。

{
    “config_errors”：[
        {
            “action”：“server_update”，
            “当前”：“CRC32”，
            “option”：“binlog_checksum”，
            “必需”：“无”
        }，
        {
            “行动”：“重启”，
            “当前”：“关闭”，
            “选项”：“enforce_gtid_consistency”，
            “必需”：“开”
        }，
        {
            “行动”：“重启”，
            “当前”：“关闭”，
            “选项”：“gtid_mode”，
            “必需”：“开”
        }，
        {
            “行动”：“重启”，
            “当前”：“1”，
            “option”：“server_id”，
            “必需”：“”
        }
    ]
    “状态”：“错误”
}

对计划用作群集一部分的每个服务器实例重复此过程。 运行后生成的报告 dba.checkInstanceConfiguration() 提供有关所需的任何配置更改的信息，然后才能继续。 该 action 领域 config_error 的报告的部分告诉你的MySQL的实例是否需要重新启动才能检测对配置文件进行任何改变。

不支持持久配置更改的实例（请参阅 持久设置 ）要求您连接到服务器，运行MySQL Shell，在本地连接到实例并发出问题 dba.configureLocalInstance() 。 这使MySQL Shell能够在针对远程实例运行以下命令后修改实例的选项文件：

建议的方法是登录远程计算机，例如使用SSH，以root用户身份运行MySQL Shell，然后连接到本地MySQL服务器。 例如，使用 --uri 选项连接到本地 instance ：

外壳> sudo -i mysqlsh --uri=instance

或者，使用该 \connect 命令登录本地实例。 然后发出 ， 本地实例的连接信息 在哪里 ，以保持对本地实例的选项文件所做的任何更改。 dba.configureInstance(instance) instance

mysql-js> dba.configureLocalInstance（'ic @ ic-2：3306'）
	

对群集中的每个实例重复此过程，该实例不支持自动进行持久配置更改。 例如，如果向群集添加2个不自动支持持久性配置更改的实例，则必须连接到每个服务器并在实例重新启动之前保留InnoDB群集所需的配置更改。 同样，如果您修改群集结构（例如更改实例数），则需要为每个服务器实例重复此过程，以便相应地为群集中的每个实例更新InnoDB群集元数据。

使用时创建集群时 dba.createCluster() ，该操作将返回可以分配给变量的Cluster对象。 您可以使用此对象来处理群集，例如添加实例或检查群集的状态。 如果要在以后再次检索群集，例如在重新启动MySQL Shell之后，请使用该 功能。 例如： dba.getCluster([name],[options])

MySQL的-JS> var cluster1 = dba.getCluster()

如果未指定 name 群集，则返回默认群集。 默认情况下，MySQL Shell会在您使用时尝试连接到群集的主实例 dba.getCluster() 。 设置 connectToPrimary 选项以配置此行为。 如果 connectToPrimary 是 true 并且活动的全局MySQL Shell会话不是主实例，则查询群集以查找主要成员，并且群集对象连接到该主要成员。 如果群集中没有仲裁，则操作将失败。 如果 connectToPrimary 是 false ，则群集对象使用活动会话，换句话说，就是与MySQL Shell当前全局会话相同的实例。 如果 connectToPrimary 未指定，MySQL外壳中把 connectToPrimary 作为 true ，并回落到 connectToPrimary 是 false 。

要在获取群集时强制连接到辅助节点，请建立与群集的辅助成员的连接，并 connectToPrimary 通过发出以下命令来 使用该 选项：

mysql-js> shell.connect(secondary_member)
mysql-js>var cluster1 = dba.getCluster(testCluster, {connectToPrimary:false})

群集对象提供了 status() 一种方法，使您可以检查群集的运行方式。 在检查InnoDB集群的状态之前，您需要通过连接到其任何实例来获取对InnoDB集群对象的引用。 但是，如果要更改群集的配置，则必须连接到“R / W”实例。 发出 status() 将根据您所连接的服务器实例知道的集群视图检索集群的状态并输出状态报告。

有关InnoDB集群如何运行的信息，请使用集群的 status() 方法：

mysql-js> var cluster = dba.getCluster()
mysql-js>cluster.status()
{
    “clusterName”：“testcluster”， 
    “defaultReplicaSet”：{
        “名称”：“默认”， 
        “primary”：“ic-1：3306”， 
        “ssl”：“必需的”， 
        “状态”：“好”， 
        “statusText”：“群集在线并且最多可以容忍一次失败。”， 
        “拓扑”：{
            “ic-1：3306”：{
                “地址”：“ic-1：3306”， 
                “模式”：“R / W”， 
                “readReplicas”：{}， 
                “角色”：“HA”， 
                “状态”：“在线”
            }， 
            “ic-2：3306”：{
                “地址”：“ic-2：3306”， 
                “模式”：“R / O”， 
                “readReplicas”：{}， 
                “角色”：“HA”， 
                “状态”：“在线”
            }， 
            “ic-3：3306”：{
                “地址”：“ic-3：3306”， 
                “模式”：“R / O”， 
                “readReplicas”：{}， 
                “角色”：“HA”， 
                “状态”：“在线”
            }
        }
    }， 
    “groupInformationSourceMember”：“mysql：// ic @ ic-1：3306”
}

输出 Cluster.status() 提供以下信息：

Cluster.status() 可以扩展操作 的输出， 以使您能够显示有关群集使用的基础组复制组的信息。 要查看有关信息 groupName ， memberId ， GRProtocolVersion -由组，以及有关交易检查，提出的一些一般性的统计数据使用的通信协议，并通过实例拒绝，问题：

Cluster.STATUS（{扩展：真}）

要查看有关恢复和常规事务I / O，应用程序工作线程统计信息和任何滞后的信息; 应用程序协调器统计信息，如果启用了并行应用; 错误，以及来自I / O和应用程序线程问题的其他信息

Cluster.STATUS（{queryMembers：真}）

如果 queryMembers 设置为 true ，则会打开与群集中每个实例的连接，以便可以查询其他特定于实例的统计信息。 输出中包含的确切统计信息取决于实例的状态和配置以及服务器版本。 此信息与 replication_group_member_stats 表 中显示的信息相匹配 ，请参阅匹配列的说明。 ONLINE 具有 transactions 包含在输出中 的 对象的 实例 。 RECOVERING 具有 recovery 包含在输出中 的 对象的 实例 。 在任何一种情况下，对象都可以包含以下内容：

该 connection 部分显示了该 replication_connection_status 表 中的信息 。

该 currentlyQueueing 部分包含有关当前排队的交易的信息：

该 lastQueued 部分包含有关最近排队的事务的信息：

使用多线程从属的实例有一个 workers 部分，其中包含有关工作线程的信息，并匹配 replication_applier_status_by_worker 表中 显示的信息 。

该 lastApplied 部分显示有关工作人员应用的上一个事务的以下信息：

该 currentlyApplying 部分显示有关工作程序当前正在应用的事务的以下信息：

该 lastProcessed 部分包含有关工作人员处理的最后一个事务的以下信息：

如果启用了并行应用程序工作程序，则会包含workers数组中的对象数 transactions 或 recovery 匹配已配置工作程序数以及其他协调程序对象。 显示的信息与 replication_applier_status_by_coordinator 表 中的信息相匹配 。 该对象可以包含：

该 currentlyProcessing 部分包含有关工作人员正在处理的事务的以下信息：

worker 如果在 replication_applier_status_by_worker 表 中检测到错误，则对象具有以下信息 ：

connection 如果在 replication_connection_status 表 中检测到错误，则对象具有以下信息 ：

coordinator 如果在 replication_applier_status_by_coordinator 表 中检测到错误，则对象具有以下信息 ：

从MySQL 8.0.16开始，Group Replication具有该组通信协议的概念，请参见 第18.4.2.4节“设置组的通信协议版本” 用于背景信息。 组复制通信协议版本通常必须显式管理，并设置为容纳您希望该组支持的最旧的MySQL服务器版本。 但是，只要使用AdminAPI操作更改集群拓扑，InnoDB集群就会自动且透明地管理其成员的通信协议版本。 群集始终使用当前属于群集或加入群集的所有实例都支持的最新通信协议版本。

要查看群集中使用的通信协议版本，请使用 启用 Cluster.status() 该 extended 选项的功能。 如果 GRProtocolVersion 群集具有仲裁且没有群集成员无法访问， 则会在 字段中 返回通信协议版本 。

要获取有关InnoDB集群本身结构的信息，请使用以下 Cluster.describe() 函数：

MySQL的-JS> cluster.describe();
{
    “clusterName”：“testCluster”，
    “defaultReplicaSet”：{
        “名称”：“默认”，
        “拓扑”：[
            {
                “地址”：“ic-1：3306”，
                “label”：“ic-1：3306”，
                “角色”：“HA”
            }，
            {
                “地址”：“ic-2：3306”，
                “label”：“ic-1：2306”，
                “角色”：“HA”
            }，
            {
                “地址”：“ic-3：3306”，
                “label”：“ic-3：3306”，
                “角色”：“HA”
            }
        ]
    }
}

此函数的输出显示InnoDB集群的结构，包括其所有配置信息，等等。 地址，标签和角色值与“ 检查群集的状态”中 Cluster.status() 描述的值相匹配 。

以下操作可以报告有关在实例上运行的MySQL Server版本的信息：

行为因 Cluster 对象会话 的MySQL Server版本而异 。

每当组复制停止时，该 super_read_only 变量将设置 ON 为确保不对该实例进行写入。 当您尝试将此类实例与以下AdminAPI命令一起使用时，您可以选择 super_read_only=OFF 在实例上 进行设置 ：

当AdminAPI遇到具有 super_read_only=ON 交互模式 的实例时， 您可以选择进行设置 super_read_only=OFF 。 例如：

MySQL的-JS> var myCluster = dba.createCluster('testCluster')
将在实例'ic @ ic-1：3306'上创建一个新的InnoDB集群。

'ic @ ic-1：3306'的MySQL实例目前有super_read_only 
系统变量设置为保护它免受应用程序的无意更新。 
您必须先取消设置才能对此实例执行任何更改。 
有关详细信息，请参阅：https：//dev.mysql.com/doc/refman/en/server-system-variables.html#sysvar_super_read_only。

注意：有'ic @ ic-1：3306'的开放会话。
您可能希望终止这些会话以防止它们执行意外更新： 

1个开放会话'ic @ ic-1：3306'。 


你想禁用super_read_only并继续吗？[Y | N]：

	

显示实例的当前活动会话数。 您必须确保没有应用程序可能无意中写入该实例。 通过回答 y 您确认AdminAPI可以写入实例。 如果列出的实例有多个打开的会话，请在允许AdminAPI设置之前谨慎操作 super_read_only=OFF 。

要强制 super_read_only=OFF 在脚本中 设置函数，请将 clearReadOnly 选项设置为 true 。 例如 dba.configureInstance(instance, {clearReadOnly: true}).

运行MySQL 8.0.16及更高版本的实例支持组复制自动重新加入功能，这使您可以将实例配置为在被驱逐后自动重新加入群集。 有关 背景信息 ， 请参见 第18.6.6节“对故障检测和网络分区的响应” 。 AdminAPI提供了一个 autoRejoinTries 选项，用于配置在驱逐后重新加入群集的尝试实例数。 默认情况下，实例不会自动重新加入群集。 您可以 autoRejoinTries 使用以下命令在集群级别或单个实例上 配置该 选项：

该 autoRejoinTries 选项接受介于0和2016之间的正整数值，默认值为0，这意味着实例不会尝试自动重新加入。 当您使用自动重新加入功能时，您的群集更容忍故障，尤其是诸如不可靠网络之类的临时故障。 但是，如果丢失了仲裁，则不应期望成员自动重新加入群集，因为大多数都需要重新加入实例。

运行MySQL 8.0.12及更高版本的实例具有 group_replication_exit_state_action 变量，您可以使用AdminAPI exitStateAction 选项 配置 该 变量 。 这可以控制在意外离开集群时实例执行的操作。 默认情况下，该 exitStateAction 选项 READ_ONLY, 意味着离开群集的实例意外地变为只读。 如果 exiStateAction 是 ABORT_SERVER 在意外离开集群的情况下，该实例将关闭MySQL，并且必须在它重新加入集群之前再次启动它。 请注意，当您使用自动重新加入功能时，由...配置的操作 exitStateAction 选项仅在所有重新加入群集的尝试失败时发生。

您可能有可能连接到实例并尝试使用AdminAPI进行配置，但此时实例可能正在重新加入群集。 只要您使用以下任何操作，就会发生这种情况：

当实例自动重新加入群集时，这些操作可能会提供额外信息。 此外，在使用时 Cluster.removeInstance() ，如果目标实例自动重新加入群集，则操作将中止，除非您传入 force:true 。

沙箱实例运行后，可以使用以下方法随时更改其状态：

如果您愿意，可以随时从群集中删除实例。 这可以使用该 方法 完成， 如下例所示： Cluster.removeInstance(instance)

MySQL的-JS> cluster.removeInstance('root@localhost:3310')

该实例将从InnoDB集群中删除。取决于实例
无论是否为Seed，元数据会话可能会变为无效。如果是的话，请
启动到Metadata Storage R / W实例的新会话。

试图离开组复制组...

已成功从群集中删除实例“localhost：3310”。

您可以选择传递 interactive 选项以控制是否提示您确认从群集中删除实例。 在交互模式下，系统会提示您继续删除实例（如果无法访问）。 该 cluster.removeInstance() 操作确保从所有集群成员 ONLINE 和实例本身 的元数据中删除 实例。

当被删除的实例具有仍然需要应用的事务时，AdminAPI会等待MySQL Shell dba.gtidWaitTimeout 选项为要应用的事务（GTID） 配置的秒数 。 MySQL Shell dba.gtidWaitTimeout 选项的默认值为60秒， 有关更改默认值的信息 ，请参阅 配置MySQL Shell选项 。 如果 dba.gtidWaitTimeout 在等待应用事务并且 force 选项 false （或未定义） 时达到 定义的超时值， 则会 发出错误并中止删除操作。 如果定义的超时值 dba.gtidWaitTimeout 在等待应用事务并且将该 force 选项设置为 true 然后操作继续而没有错误时到达，并从集群中删除该实例。

创建集群并向其添加实例时，AdminAPI会自动配置组名，本地地址和种子实例等值。 建议大多数部署使用这些默认值，但高级用户可以通过将以下选项传递给 dba.createCluster() 和 来覆盖默认值 Cluster.addInstance() 。

要自定义InnoDB集群创建的复制组的名称，请将该 groupName 选项 传递 给该 dba.createCluster() 命令。 这将设置 group_replication_group_name 系统变量。 该名称必须是有效的UUID。

要自定义实例为来自其他实例的连接提供的地址，请将 localAddress 选项 传递 给 dba.createCluster() 和 cluster.addInstance() 命令。 以格式指定地址 。 这将 在实例上 设置 系统变量。 该地址必须可供集群中的所有实例访问，并且必须仅为内部集群通信保留。 换句话说，不要使用此地址与实例进行通信。 host:port group_replication_local_address

要在实例加入群集时自定义用作种子的实例，请将 groupSeeds 选项 传递 给 dba.createCluster() 和 cluster.addInstance() 命令。 当新实例加入群集并用于向新实例提供数据时，将联系种子实例。 地址被指定为以逗号分隔的列表，例如 host1:port1 ， host2:port2 。 这会配置 group_replication_group_seeds 系统变量。

有关更多信息，请参阅这些AdminAPI选项配置的系统变量的文档。

如果实例离开集群，例如因为它丢失了连接，并且由于某种原因它无法自动重新加入集群，则可能需要在稍后阶段将其重新加入集群。 将实例重新加入群集问题 。 Cluster.rejoinInstance(instance)

如果实例尚未保持配置（请参阅 “保持设置” ），则重新启动后实例不会自动重新加入群集。 解决方案是发出 cluster.rejoinInstance() 以便将实例再次添加到集群并确保更改持久化。 将InnoDB集群配置持久保存到实例的选项文件后，它会自动重新加入集群。

如果要重新加入以某种方式更改的实例，则可能必须修改实例以使重新加入过程正常工作。 例如，在还原MySQL Enterprise Backup备份时，会进行 server_uuid 更改。 尝试重新加入此类实例失败，因为InnoDB集群实例由 server_uuid 变量 标识 。 在这种情况下， server_uuid 必须从InnoDB集群元数据中删除 有关实例旧的信息 ，然后 Cluster.rescan() 必须执行必须使用它的新实例将实例添加到元数据中 server_uuid 。 例如：

cluster.removeInstance（“root @ instanceWithOldUUID：3306”，{force：true}）

cluster.rescan（）

在这种情况下，您必须将 force 选项 传递 给 Cluster.removeInstance() 方法，因为从集群的角度来看实例是无法访问的，我们希望无论如何都要从InnoDB集群元数据中删除它。

如果一个或多个实例失败，则群集可能会失去其仲裁，即能够在新主节点中投票。 如果存在足够实例的故障，组成群集的大多数实例不再对组复制操作进行投票，则会发生这种情况。 当群集丢失仲裁时，您无法再处理与群集的写入事务，也无法更改群集的拓扑，例如通过添加，重新加入或删除实例。 但是，如果您有一个包含InnoDB集群元数据的在线实例，则可以使用仲裁还原集群。 这假设您可以连接到包含InnoDB集群元数据的实例，

连接到包含群集元数据的实例，然后使用该 操作，该操作将根据元数据恢复群集 ，然后 将从给定实例定义的角度来看的所有实例添加到已还原的群集。 Cluster.forceQuorumUsingPartitionOf(instance) instance ONLINE

MySQL的-JS> cluster.forceQuorumUsingPartitionOf("ic@ic-1:3306")

  通过使用由[ic @ ic-1：3306]组成的分区，从仲裁丢失中恢复复制集“默认”

  请提供“ic @ ic-1：3306”的密码：******
  恢复InnoDB集群......

  使用实例'ic @ ic-1：3306'中的分区成功恢复了InnoDB集群。

  警告：为避免裂脑情况，请确保复制的所有其他成员
  被删除或连接回已恢复的组。

如果实例未自动添加到群集，例如，如果其设置未保留，请使用 Cluster.rejoinInstance() 手动将实例添加回群集。

还原的群集可能不会也不必包含构成群集的所有原始实例。 例如，如果原始群集由以下五个实例组成：

和群集经历脑分裂情况下，与 ic-1 ， ic-2 ，和 ic-3 形成而一个分区 ic-4 和 ic-5 形成另一分区。 如果连接到 ic-1 并 Cluster.forceQuorumUsingPartitionOf('ic@ic-1:3306') 恢复群集，则生成的群集将包含以下三个实例：

因为 ic-1 看到 ic-2 和 ic-3 作为 ONLINE ，不看 ic-4 和 ic-5 。

如果您的群集遭受完全中断，您可以确保使用正确的重新配置 dba.rebootClusterFromCompleteOutage() 。 此操作采用MySQL Shell当前连接的实例并使用其元数据来恢复群集。 如果群集的实例已完全停止，则必须启动实例，然后才能启动群集。 例如，如果已重新启动运行沙箱群集的计算机，并且实例位于端口3310,3320和3330，则发出：

mysql-js> dba.startSandboxInstance(3310)
mysql-js> dba.startSandboxInstance(3320)
mysql-js>dba.startSandboxInstance(3330)
    

这可确保沙盒实例正在运行。 在生产部署的情况下，您必须在MySQL Shell之外启动实例。 实例启动后，您需要连接到具有GTID超集的实例，这意味着在中断之前应用了最多事务的实例。 如果您不确定哪个实例包含GTID超集，请连接到任何实例并按照其中的交互消息进行操作 dba.rebootClusterFromCompleteOutage() ，该 消息 检测您连接的实例是否包含GTID超集。 通过发出以下命令重启群集：

MySQL的-JS> var cluster = dba.rebootClusterFromCompleteOutage();

然后， dba.rebootClusterFromCompleteOutage() 操作遵循以下步骤以确保正确地重新配置群集：

如果您未使用MySQL Shell的交互模式，则可以使用 rejoinInstances 和 removeInstances 选项手动配置在重新引导群集期间应加入或删除的实例。

如果遇到错误，例如 活动会话实例与群集元数据的ONLINE实例相比不是最新的。 那么您连接的实例没有集群应用的事务的GTID超集。 在这种情况下，将MySQL Shell连接到错误消息中建议的实例并 dba.rebootClusterFromCompleteOutage() 从该实例 发出 。

MySQL的-SQL> SHOW VARIABLES LIKE 'gtid_executed';

如果此过程失败，并且群集元数据已严重损坏，则可能需要删除元数据并从头开始再次创建群集。 您可以使用删除群集元数据 dba.dropMetadataSchema() 。

如果对AdminAPI命令之外的集群进行配置更改（例如，通过手动更改实例的配置以解决配置问题或在实例丢失后），则需要更新InnoDB集群元数据，以使其与当前的配置相匹配实例。 在这些情况下，请使用该 Cluster.rescan() 操作，该操作使您可以手动或使用交互式向导更新InnoDB群集元数据。 该 Cluster.rescan() 操作可以检测未在元数据中注册的新活动实例并添加它们，或者仍然在元数据中注册的过时实例（不再活动），并将其删除。 您可以根据命令找到的实例自动更新元数据，也可以指定实例地址列表以添加元数据或从元数据中删除。 您还可以更新存储在元数据中的拓扑模式，例如在AdminAPI之外从单主模式更改为多主模式之后。

该命令的语法是 Cluster.rescan([options]) 。 该 options 词典支持以下内容：

该 cluster.checkInstanceState() 函数可用于验证实例上的现有数据不会阻止它加入集群。 此过程通过验证实例的全局事务标识符（GTID）状态与集群已处理的GTID进行比较来工作。 有关 GTID的 更多信息，请参见 第17.1.3.1节“GTID格式和存储” 。 通过此检查，您可以确定是否可以将已处理事务的实例添加到集群。

以下演示了在运行的MySQL Shell中发布它：

MySQL的-JS> cluster.checkInstanceState('ic@ic-4:3306')

此函数的输出可以是以下之一：

可以将具有“正常”状态的实例添加到群集，因为实例上的任何数据都与群集一致。 换句话说，正在检查的实例没有执行任何与集群执行的GTID冲突的事务，并且可以恢复到与其余集群实例相同的状态。

要解散InnoDB集群，您需要连接到读写实例，例如单主集群中的主实例，然后使用该 Cluster.dissolve() 命令。 这将删除与群集关联的所有元数据和配置，并禁用实例上的组复制。 不会删除在实例之间复制的任何数据。

该 Cluster.dissolve() 操作只能配置 ONLINE 可访问的 实例 。 如果您发布的成员无法访问群集的成员 Cluster.dissolve() 命令你必须决定溶解操作应该如何进行。 如果您有可能想要重新加入群集中标识为丢失的任何实例，强烈建议取消溶解操作并首先将缺失的实例重新联机，然后再继续执行溶解操作。 这可以确保所有实例都可以正确更新其元数据，并且不会出现裂脑情况。 但是，如果群集中无法到达的实例已永久离开群集，则除了强制执行溶解操作之外别无选择，这意味着将忽略缺少的实例，并且只有在线实例会受到操作的影响。

在交互模式下，如果在解散操作期间无法访问群集的成员，则会显示交互式提示，例如：

MySQL的-JS> Cluster.dissolve()
群集仍具有以下已注册的ReplicaSet：
{
    “clusterName”：“testCluster”， 
    “defaultReplicaSet”：{
        “名称”：“默认”， 
        “拓扑”：[
            {
                “地址”：“ic-1：3306”， 
                “label”：“ic-1：3306”， 
                “角色”：“HA”
            }， 
            {
                “地址”：“ic-2：3306”， 
                “label”：“ic-2：3306”， 
                “角色”：“HA”
            }， 
            {
                “地址”：“ic-3：3306”， 
                “label”：“ic-3：3306”， 
                “角色”：“HA”
            }
        ]
    }
}
警告：您即将解散整个群集并失去高位
它提供的可用性功能。此操作无法恢复。所有
成员将从其副本集中删除，复制将被停止，
内部恢复用户帐户和群集元数据将被删除。用户
在所有情况下，数据都将保持不变。

您确定要解散群集吗？[y / N]：y

错误：实例'ic-2：3306'无法删除，因为它位于'（MISSING）'
州。请将实例重新置于ONLINE并尝试解散群集
再次。如果永久无法访问实例，则可以选择
继续操作并仅从群集中删除实例
元数据。

您是否仍想继续（仅删除实例元数据）？
[y / N]：y

实例'ic-3：3306'试图离开集群......实例'ic-1：3306'
正试图离开集群......

警告：群集已成功解散，但以下实例是
跳过：'ic-2：3306'。请确保此实例永久不可用
或采取任何必要的手动操作，以确保群集完全解散。

在此示例中，群集由三个实例组成，其中一个实例在发出dissolve时处于脱机状态。 捕获错误，您可以选择如何继续。 在这种情况下，将 ic-2 忽略 缺少的 实例，并且可访问的成员会更新其元数据。

当MySQL Shell以非交互模式运行时（例如，在运行批处理文件时），您可以 Cluster.dissolve() 使用该 force 选项 配置 操作 的行为 。 要强制解析操作忽略任何无法访问的实例，请发出：

MySQL的-JS> Cluster.dissolve({force: true})

可以从群集中删除任何可以访问的实例，并忽略任何无法访问的实例。 本节中有关强制从群集中删除缺失实例的警告同样适用于强制解散操作的此技术。

您还可以使用该 操作 interactive 选项 Cluster.dissolve() 覆盖运行MySQL Shell的模式，例如，在运行批处理脚本时显示交互式提示。 例如：

MySQL的-JS> Cluster.dissolve({interactive: true})

在 dba.gtidWaitTimeout mysql外壳选项配置多长时间 Cluster.dissolve() 操作等待从集群中去除目标实例之前被应用集群的交易，但前提是目标实例 ONLINE 。 如果在等待要删除的任何实例上应用集群事务时达到超时，则会发出错误，除非使用force：true，在这种情况下会跳过错误。

可以将服务器实例配置为使用安全连接。 有关在MySQL中使用SSL的一般信息，请参见 第6.3节“使用加密连接” 。 本节介绍如何配置群集以使用SSL。 另一种安全可能性是配置哪些服务器可以访问群集，请参阅 创建服务器白名单 。

使用 dba.createCluster() 设置群集时，如果服务器实例提供SSL加密，则会在种子实例上自动启用它。 将 memberSslMode 选项 传递 给 dba.createCluster() 方法以指定其他SSL模式。 群集的SSL模式只能在创建时设置。 该 memberSslMode 选项是一个字符串，用于配置要使用的SSL模式，默认为 AUTO 。 允许的值为 DISABLED ， REQUIRED ，和 AUTO 。 这些模式定义为：

发出 cluster.addInstance() 和 cluster.rejoinInstance() 命令时，将根据为种子实例找到的设置启用或禁用实例上的SSL加密。

当使用 createCluster() 与 adoptFromGR 选择采用现有的组复制组，无SSL设置改变所采用的集群：

MySQL Shell始终为群集复制和组通信启用或禁用群集的SSL，请参见 第18.5.2节“组复制安全套接字层（SSL）支持” 。 被执行的验证并且如果发出错误这些设置是用于种子实例（例如作为的结果不同 dba.createCluster() 使用 adoptFromGR 添加一个新的实例给集群时）。 必须为群集中的所有实例启用或禁用SSL加密。 执行验证以确保在向集群添加新实例时保持此不变量。

该 deploySandboxInstance() 命令默认尝试部署具有SSL加密支持的沙箱实例。 如果不可能，则在没有SSL支持的情况下部署服务器实例。 使用 ignoreSslError 选项设置为false可确保使用SSL支持部署沙箱实例，如果无法提供SSL支持，则会发出错误。 如果 ignoreSslError 为true（默认值），则在操作期间如果无法提供SSL支持且在没有SSL支持的情况下部署服务器实例，则不会发出错误。

当使用群集的 createCluster() ， addInstance() 和 rejoinInstance() 方法，您可以选择指定属于群集批准服务器，被称为白名单列表。 通过以这种方式明确指定白名单，您可以提高群集的安全性，因为只有白名单中的服务器才能连接到群集。 使用该 ipWhitelist 选项可 group_replication_ip_whitelist 在实例上 配置 系统变量。 默认情况下，如果未明确指定，白名单将自动设置为服务器具有网络接口的专用网络地址。 要配置白名单，请指定要添加的服务器 ipWhitelist 使用该方法时的选项。 将服务器作为逗号分隔列表传递，并用引号括起来。 例如：

MySQL的-JS> cluster.addInstance("ic@ic-3:3306", {ipWhitelist: "203.0.113.0/24, 198.51.100.110"})

这会将实例配置为仅接受来自地址 203.0.113.0/24 和 服务器的连接 198.51.100.110 。 白名单还可以包括主机名，只有在其他服务器发出连接请求时才会解析主机名。

您可以使用脚本自动执行集群配置，这些脚本可以使用MySQL Shell运行。 例如：

外壳> mysqlsh -f setup-innodb-cluster.js

示例脚本文件的内容如下所示：

print（'MySQL InnoDB集群沙箱设置\ n'）;
打印（ '================================== \ n'）;
print（'设置带有3个MySQL服务器沙盒实例的MySQL InnoDB集群。\ n'）;
print（'实例将安装在〜/ mysql-sandboxes。\ n'）;
print（'它们将在端口3310,3320和3330上运行。\ n \ n'）;

var dbPass = shell.prompt（'请输入MySQL root帐户的密码：'，{type：“password”}）;

尝试{
   print（'\ nDeploying the sandbox instances。'）;
   dba.deploySandboxInstance（3310，{password：dbPass}）;
   打印（'。'）;
   dba.deploySandboxInstance（3320，{password：dbPass}）;
   打印（'。'）;
   dba.deploySandboxInstance（3330，{password：dbPass}）;
   print（'。\ nSandbox实例已成功部署。\ n \ n'）;

   print（'设置InnoDB集群...... \ n'）;
   shell.connect（'root @ localhost：3310'，dbPass）;

   var cluster = dba.createCluster（“prodCluster”）;

   print（'将实例添加到集群。'）;
   cluster.addInstance（{user：“root”，host：“localhost”，port：3320，password：dbPass}）;
   打印（'。'）;
   cluster.addInstance（{user：“root”，host：“localhost”，port：3330，password：dbPass}）;
   print（'。\ nInstances成功添加到集群。'）;

   print（'\ nInnoDB集群已成功部署。\ n'）;
} catch（e）{
   print（'\ n无法创建InnoDB集群。\ n \ n错误：'+
   + e.message +'\ n'）;
}

您可以选择配置单主群集如何选择新主节点，例如，将一个实例作为新主节点进行故障转移。 使用该 memberWeight 选项并 在创建群集时 将其传递给 dba.createCluster() and Cluster.addInstance() 方法。 该 memberWeight 选项接受0到100之间的整数值，该值是故障转移时自动主要选举的百分比权重。 当实例具有更高的设置的百分比数时 memberWeight ，更有可能在单主群集中被选为主要。 当主要选举发生时，如果多个实例具有相同的选举 memberWeight 然后，根据字典顺序（最低）的服务器UUID并选择第一个实例来确定实例的优先级。

设置值 memberWeight 可以 group_replication_member_weight 在实例上 配置 系统变量。 组复制将值范围限制为0到100，如果提供更高或更低的值，则自动调整它。 如果未提供任何值，则组复制使用默认值50。 更多信息 ， 请参见 第18.4.1.1节“单主模式” 。

例如，要配置一个群集，其中 ic-3 首选实例要故障转移到 ic-1 当前主节点，意外地离开群集 memberWeight ，如下所示：

dba.createCluster（'cluster1'，{memberWeight：35}）
var mycluster = dba.getCluster（）
mycluster.addInstance（'ic @ ic2'，{memberWeight：25}）
mycluster.addInstance（'ic @ ic3'，{memberWeight：50}）

如果主要故障转移在单主模式下发生，则 组复制可以指定故障转移保证（最终或 “ 读取您的写入 ” ）（请参见 第18.4.3.2节“配置事务一致性保证” ）。 您可以在创建时配置InnoDB集群的故障转移保证，方法是将该 consistency 选项（在8.0.14版中，此选项 failoverConsistency 是现已弃用 的 选项）传递给 dba.createCluster() 操作，该操作将配置 group_replication_consistency 种子实例上的系统变量。 此选项定义在单主组中选择新主节点时使用的新防护机制的行为。 防护限制连接从新主节点写入和读取，直到它应用来自旧主节点的任何挂起的更改积压（有时称为 “ 读取您的写入 ” ）。 当防护机制到位时，应用程序实际上不会在应用任何积压的情况下在短时间内向后看时间。 这可确保应用程序不会从新选择的主节点中读取过时信息。

consistency 仅当目标MySQL服务器版本为8.0.14或更高版本时才支持 该 选项，并且添加到已使用该 consistency 选项 配置的群集的实例将 自动配置为 group_replication_consistency 在支持该选项的所有集群成员上具有相同的 实例 。 变量默认值由组复制控制，并且 EVENTUAL 将 consistency 选项 更改 BEFORE_ON_PRIMARY_FAILOVER 为启用防护机制。 或者，使用 consistency=0 了 EVENTUAL 和 consistency=1 为 BEFORE_ON_PRIMARY_FAILOVER 。

默认情况下，InnoDB集群以单主模式运行，其中集群具有一个接受读写查询（R / W）的主服务器，并且集群中的所有其余实例仅接受读取查询（R / O） 。 当您将群集配置为在多主模式下运行时，群集中的所有实例都是主要的，这意味着它们同时接受读取和写入查询（R / W）。 如果群集的所有实例都运行MySQL服务器版本8.0.15或更高版本，则可以在群集联机时更改群集的拓扑。 在以前的版本中，必须完全解散并重新创建群集以进行配置更改。 第18.4.2节“配置在线组” ，因此您应遵守配置在线组的规则。

通常，当主节点意外离开集群时，单主节点会选择新的主节点，例如由于意外停止。 选举过程通常用于选择当前的第二个成为新的主要成员。 要覆盖选举过程并强制特定服务器成为新主服务器，请使用该 函数，其中 指定与应成为新主服务器的实例的连接。 这使您可以配置基础组复制组以选择特定实例作为新主服务器，从而绕过选举过程。 Cluster.setPrimaryInstance(instance) instance

您可以使用以下操作更改在单主服务器和多主服务器之间运行集群的模式（有时称为拓扑）：

您可以在实例联机时检查和修改InnoDB群集的适当设置。 要检查群集的当前设置，请使用以下操作：

您可以在集群级别或实例级别配置InnoDB集群的选项，同时实例保持联机状态。 这样就无需删除，重新配置，然后再添加实例来更改InnoDB集群选项。 使用以下操作：

将InnoDB集群选项与列出的操作一起使用的方式取决于是否可以将选项更改为在所有实例上都相同。 这些选项在群集（所有实例）和每个实例级别都是可更改的：

此选项仅在每个实例级别可更改：

这些选项仅在群集级别可更改：

当您将实例用作InnoDB集群的一部分时，将 配置 auto_increment_increment 和 auto_increment_offset 变量以避免多主集群自动增量冲突的可能性，最大为9（组复制组的最大支持大小）。 用于配置这些变量的逻辑可以概括为：