MySQL Shell 8.4  /  MySQL InnoDB ClusterSet  /  InnoDB ClusterSet 状态和拓扑

8.6 InnoDB ClusterSet 状态和拓扑

本节介绍以下内容

InnoDB ClusterSet 状态

AdminAPI 的 clusterSet.status() 命令返回一个 JSON 对象，描述 InnoDB ClusterSet 部署的状态。输出包括 InnoDB ClusterSet 部署本身的状态，以及 ClusterSet 中每个 InnoDB 集群的全局状态和集群状态。扩展输出添加了每个集群中每个成员服务器的状态、有关 InnoDB ClusterSet 管理的异步复制通道的信息以及其他配置和状态信息。该命令报告 ClusterSet 复制以及服务器本身的状态。如果存在任何问题，将包含警告和错误消息以更详细地解释问题。

使用 clusterSet.status() 的 MySQL Shell 实例可以连接到 InnoDB ClusterSet 的任何活动成员。可以通过 InnoDB ClusterSet 中任何其他活动集群来检索元数据，该元数据来自主集群。

如果 InnoDB ClusterSet 中的任何集群存在问题，第 8.9 节，“InnoDB ClusterSet 修复和重新加入” 说明了修复问题并将集群重新加入 ClusterSet（或者如果问题无法修复则将其删除）的步骤。如果存在问题的集群是主集群，首先需要执行受控切换（如果它仍在运行，如 第 8.7 节，“InnoDB ClusterSet 受控切换” 中所述），或者执行紧急故障转移（如果它没有运行或无法联系，如 第 8.8 节，“InnoDB ClusterSet 紧急故障转移” 中所述）。

您可以使用 extended 选项（默认值为 0）来增加输出的详细程度，如下所示

  • extended: 0 或省略该选项返回有关 InnoDB ClusterSet 部署、ClusterSet 中每个 InnoDB 集群的可用性状态以及每个副本集群的 ClusterSet 复制状态的基本信息。

  • extended: 1 添加 ClusterSet 中每个 InnoDB 集群的拓扑、每个集群中每个单独成员服务器的状态以及有关每个副本集群的 ClusterSet 复制通道状态的更多详细信息。

  • extended: 2 添加有关每个集群中每个单独成员服务器以及 ClusterSet 复制通道的更多详细信息，包括 GTID 集。

  • extended: 3 添加 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-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."
}

要获取代表目标服务器实例的 InnoDB ClusterSet 的 ClusterSet 对象的句柄，请使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令。如果目标服务器实例是 InnoDB ClusterSet 部署中的一部分 InnoDB 集群的成员，即使 InnoDB ClusterSet 部署的主集群当前不可达，这些命令也能正常工作。使用该对象时，目标服务器实例本身必须可达。如果目标实例是已标记为无效的集群的成员，该命令会返回警告，但仍然返回 ClusterSet 对象。如果目标实例当前不是 InnoDB ClusterSet 部署的成员，该命令会返回错误。 ClusterSet 对象包含您从中检索它的服务器的连接详细信息，因此，以前从现在离线的成员服务器中检索到的 ClusterSet 对象将不再起作用，您需要从 InnoDB ClusterSet 部署中在线的服务器中再次获取它。

ClusterSet 对象默认为使用它获取的帐户进行需要权限的操作。使用适当的用户帐户连接到服务器实例时，获取该对象很重要，以便使用该对象执行您要执行的操作。InnoDB ClusterSet 部署过程中的某些操作需要权限，并且对象中存储的默认用户帐户用于此，因此该过程不需要存储任何其他用户帐户。要监视和排查已设置的 InnoDB ClusterSet，请使用 InnoDB Cluster 管理员帐户。对于初始集群部署过程，请使用 InnoDB Cluster 服务器配置帐户。有关更多信息，请参阅 第 8.3 节，“InnoDB ClusterSet 用户帐户”。

使用 clusterSet.status() 函数时，InnoDB ClusterSet 部署报告的整体 ClusterSet 状态（status 字段）可以是以下之一

HEALTHY

InnoDB ClusterSet 中的主集群运行正常，所有副本集群都运行正常。

AVAILABLE

InnoDB ClusterSet 中的主集群运行正常，但一个或多个副本集群功能受损或无法正常运行。

UNAVAILABLE

InnoDB ClusterSet 中的主集群无法正常运行，因为它离线或失去仲裁，或者 MySQL Shell 无法联系主集群以确定其状态。

InnoDB ClusterSet 部署报告的整体 ClusterSet 状态取决于每个 InnoDB 集群的整体状态。ClusterSet 中的 InnoDB 集群会报告三种状态

  • 全局状态（globalStatus 字段）是 InnoDB 集群在 InnoDB ClusterSet 部署中的角色方面的状态。此状态显示集群是否仍然可以在 InnoDB ClusterSet 部署中正常运行，即使它存在一些问题，例如成员服务器当前离线。在故障转移过程中，无论成员服务器的状态如何，都可以将 InnoDB 集群标记为无效，如果是这种情况，则将其显示为全局状态。

  • 集群状态（status 字段）是 InnoDB 集群在自身运行方面的状态。此状态显示集群是否存在任何技术问题，例如一个或多个成员离线、失去仲裁或 Group Replication 错误状态。集群可以容忍某些问题，但仍然可以作为 InnoDB ClusterSet 部署的一部分正常运行。由于这个原因，使用默认的详细程度， clusterSet.status() 函数仅报告导致全局状态问题的集群的集群状态。要查看 InnoDB ClusterSet 中所有集群的集群状态（无论它是否导致全局状态问题），请使用 extended 选项指定更高的详细程度。

  • ClusterSet 复制状态（clusterSetReplicationStatus 字段）是副本 InnoDB 集群的 ClusterSet 复制通道的状态。此状态显示副本集群是否在从主集群复制时存在任何问题，以便可以单独考虑这些问题，而不是与集群中成员服务器的任何技术问题混淆。副本 InnoDB 集群无论是否导致全局状态问题，都会报告 ClusterSet 复制状态。主 InnoDB 集群没有此状态字段，因为 ClusterSet 复制通道不在主集群上运行。

在更高的详细程度下， clusterSet.status() 函数的扩展输出显示了每个 InnoDB 集群中每个成员服务器的状态。输出包括成员的 Group Replication 状态（memberState 字段），以及对于副本集群中的服务器，成员上的复制状态。有关 Group Replication 状态的信息，请参阅 Group Replication 服务器状态。

InnoDB 集群报告的全局状态（globalStatus 字段）可以是以下之一

OK

集群在 InnoDB ClusterSet 部署中运行正常。集群中的至少一个成员服务器处于 Group Replication 的 ONLINE 状态，并且复制组拥有仲裁。如果集群是副本集群，则 ClusterSet 复制状态也是 OK。此全局状态并不一定意味着集群没有任何技术问题。一些成员可能离线，或者集群可能拥有的成员数量过少，无法容忍故障。但是，集群运行良好，可以继续作为 InnoDB ClusterSet 部署的一部分。主集群或副本集群都可以拥有此全局状态。

OK_NOT_REPLICATING

集群运行正常，但 ClusterSet 复制通道上的复制已停止，无论是作为受控停止还是由于复制错误。只有副本集群才能拥有此全局状态。

OK_NOT_CONSISTENT

集群运行正常，但集群上的事务集（GTID 集）与主集群上的事务集不一致，因此副本集群上存在主集群没有的额外事务。ClusterSet 复制通道上的复制可能已停止，无论是作为受控停止还是由于复制错误，或者该通道可能仍在复制。只有副本集群才能拥有此全局状态。具有此状态的副本集群不可用于计划切换，尽管可以进行强制故障转移。

OK_MISCONFIGURED

集群运行正常，但检测到 ClusterSet 复制通道配置错误。例如，通道可能从错误的源进行复制。复制通道可能仍在运行，或者复制可能已停止。只有副本集群才能拥有此全局状态。

NOT_OK

由于技术问题，集群无法正常运行，无法作为 InnoDB ClusterSet 部署的一部分。它失去了仲裁，或者所有成员服务器都处于 Group Replication 的 OFFLINE 状态。主集群或副本集群可以拥有此全局状态。如果主集群具有此全局状态，则 InnoDB ClusterSet 部署将被赋予状态 UNAVAILABLE。

UNKNOWN

集群是 InnoDB ClusterSet 部署的主集群，但 MySQL Shell 目前无法与其联系以确定其状态。在无法联系主集群时，InnoDB ClusterSet 部署将被赋予状态 UNAVAILABLE。

INVALIDATED

集群在故障转移过程中失效。在受控切换过程中，数据一致性得到保证，原始主集群被降级为工作中的只读副本集群。但是，在紧急故障转移过程中，数据一致性无法保证，因此为安全起见，原始主集群在故障转移过程中被标记为失效。如果副本集群在故障转移时或在受控切换期间无法访问或不可用，则也会被标记为失效。具有此全局状态的集群无法正常运行，无法作为 InnoDB ClusterSet 部署的一部分。集群不一定存在任何技术问题，并且可能能够在手动验证后重新加入 InnoDB ClusterSet 部署。如果可以联系集群，则应验证它已关闭，以便它不接受新事务。

为 InnoDB 集群报告的集群状态（status 字段）可以是以下之一，这些状态都可以报告为主集群或副本集群

OK

集群中的所有成员服务器都处于 Group Replication 的 ONLINE 状态，并且集群中至少有三个成员。

OK_PARTIAL

集群中至少有三个成员服务器处于 Group Replication 的 ONLINE 状态。但是，一个或多个成员服务器处于 Group Replication 的 OFFLINE、RECOVERING、ERROR 或 UNREACHABLE 状态，因此它们目前没有作为集群的活动成员参与。处于此情况下的集群运行良好，可以继续作为 InnoDB ClusterSet 部署的一部分，但要将其提升为 OK 状态，请解决成员服务器的问题。

OK_NO_TOLERANCE

集群中的所有成员服务器都处于 Group Replication 的 ONLINE 状态，但集群中少于三个成员，因此它没有足够的容错能力。处于此情况下的集群运行良好，可以继续作为 InnoDB ClusterSet 部署的一部分，但要将其提升为 OK 状态，请添加更多成员服务器。

OK_NO_TOLERANCE_PARTIAL

集群中有一两个成员服务器处于 Group Replication 的 ONLINE 状态，但一个或多个成员服务器处于 Group Replication 的 OFFLINE、RECOVERING、ERROR 或 UNREACHABLE 状态。因此，由于某些成员不可用，集群没有足够的容错能力。处于此情况下的集群运行良好，可以继续作为 InnoDB ClusterSet 部署的一部分，但要将其提升为 OK 状态，请解决成员服务器的问题。

NO_QUORUM

集群没有仲裁，这意味着复制组的大多数成员服务器都无法访问，无法就决策达成一致。如果成员自愿离开或被组决策驱逐，Group Replication 能够重新配置自身以适应新的组号，因此仲裁丢失意味着丢失的成员服务器已经故障或被网络分区从其他服务器隔离开来。处于此情况下的集群无法作为 InnoDB ClusterSet 部署的一部分运行。要将此状态的集群提升为 OK 状态，请参阅 第 8.9 节“InnoDB ClusterSet 修复和重新加入”。

OFFLINE

集群中的所有成员服务器都处于 Group Replication 的 OFFLINE 状态。处于此情况下的集群无法作为 InnoDB ClusterSet 部署的一部分运行。要将此状态的集群提升为 OK 状态（如果它目前不应处于脱机状态），请参阅 第 8.9 节“InnoDB ClusterSet 修复和重新加入”。

ERROR

集群中的所有成员服务器都处于 Group Replication 的 ERROR 状态。处于此情况下的集群无法作为 InnoDB ClusterSet 部署的一部分运行。要将此状态的集群提升为 OK 状态，请参阅 第 8.9 节“InnoDB ClusterSet 修复和重新加入”。

UNKNOWN

MySQL Shell 目前无法联系任何成员服务器以确定集群的状态。如果这是主集群，则 InnoDB ClusterSet 部署将被赋予状态 UNAVAILABLE。

INVALIDATED

集群在故障转移过程中失效。在受控切换过程中，数据一致性得到保证，原始主集群被降级为工作中的只读副本集群。但是，在紧急故障转移过程中，数据一致性无法保证，因此为安全起见，原始主集群在故障转移过程中被标记为失效。如果副本集群在故障转移时或在受控切换期间无法访问或不可用，则也会被标记为失效。具有此全局状态的集群无法正常运行，无法作为 InnoDB ClusterSet 部署的一部分。集群不一定存在任何技术问题，并且可能能够在手动验证后重新加入 InnoDB ClusterSet 部署。如果可以联系集群，则应验证它已关闭，以便它不接受新事务。要处理这种情况，请参阅 第 8.9 节“InnoDB ClusterSet 修复和重新加入”。

集群状态与 InnoDB 集群作为 Group Replication 组的技术问题有关，而不是与复制过程有关。对于副本集群，还会报告 ClusterSet 复制状态（clusterSetReplicationStatus 字段）如下

OK

ClusterSet 复制通道正在运行。

STOPPED

ClusterSet 复制通道已以受控方式停止。当接收器线程、应用器线程或两个线程都已停止时，将显示此状态。

CONNECTING

复制通道正在连接。如果连接过程中发生错误，则会忽略该错误，直到通道状态更新为 ON 或 OFF。

ERROR

ClusterSet 复制通道已因复制错误而停止，例如配置错误或与主集群上的一组事务不同的事务集。

MISCONFIGURED

已检测到 ClusterSet 复制通道的配置错误，例如从错误的源进行复制。通道可能仍在运行，或者复制可能已停止。

MISSING

此集群中的服务器上不存在 ClusterSet 复制通道。

UNKNOWN

MySQL Shell 目前无法联系副本集群以确定复制通道的状态。

如果集群的唯一问题是 ClusterSet 复制通道，则对集群发出 clusterSet.rejoinCluster() 命令会自动更正通道的配置（如果有必要）并重新启动通道。这可能足以解决问题。有关执行此操作的说明，请参阅 第 8.9.5 节“将集群重新加入 InnoDB ClusterSet”。

InnoDB ClusterSet 拓扑

如果您只想查看 InnoDB ClusterSet 的拓扑结构，而不需要状态信息，则可以使用 clusterSet.describe() 函数。此函数返回一个 JSON 对象，描述 InnoDB ClusterSet 部署的拓扑结构，并提供每个 InnoDB 集群中每个成员服务器的 IP 地址和标识符。例如

mysql-js> myclusterset.describe()
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "topology": [
                {
                    "address": "127.0.0.1:3310",
                    "label": "127.0.0.1:3310"
                },
                {
                    "address": "127.0.0.1:3320",
                    "label": "127.0.0.1:3320"
                },
                {
                    "address": "127.0.0.1:3330",
                    "label": "127.0.0.1:3330"
                }
            ]
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "topology": [
                {
                    "address": "127.0.0.1:4410",
                    "label": "127.0.0.1:4410"
                },
                {
                    "address": "127.0.0.1:4420",
                    "label": "127.0.0.1:4420"
                },
                {
                    "address": "127.0.0.1:4430",
                    "label": "127.0.0.1:4430"
                }
            ]
        }
    },
    "domainName": "testclusterset",
    "primaryCluster": "clusterone"
}

此信息也由 clusterSet.status() 函数的扩展输出提供。

有关 clusterSet.setRoutingOption() 的信息，请参阅 第 6.10.4 节“路由选项”。

InnoDB ClusterSet 的 MySQL Router 状态

要查看为 InnoDB ClusterSet 注册的 MySQL Router 实例，请在连接到 InnoDB ClusterSet 部署中的任何成员服务器时，在 MySQL Shell 中发出 clusterSet.listRouters() 命令。该命令返回所有注册的 MySQL Router 实例的详细信息，或者返回您使用其路由器实例定义指定的单个路由器实例。例如

mysql-js> myclusterset.listRouters()
{
    "domainName": "testclusterset",
    "routers": {
       "mymachine::Rome1": {
            "hostname": "mymachine",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        },
        "mymachine2::Rome2": {
            "hostname": "mymachine2",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        }
    }
}

实例信息包括 MySQL Router 实例的名称、使用 MySQL 经典协议和 X 协议的读写流量的端口号、目标集群以及实例上次与目标集群进行检查的时间。如果 MySQL Router 的版本低于与此 InnoDB ClusterSet 部署一起使用所需的版本，则实例信息会说明这一点。

要查看为每个 MySQL Router 实例设置的路由选项以及 InnoDB ClusterSet 部署的全局策略，请在连接到 InnoDB ClusterSet 部署中的任何成员服务器时，在 MySQL Shell 中发出 clusterSet.routingOptions()。特定 MySQL Router 实例的设置会覆盖全局策略。例如

mysql-js> myclusterset.routingOptions()
{
    "domainName": "testclusterset",
    "global": {
        "invalidated_cluster_policy": "drop_all",
        "target_cluster": "primary"
    },
    "routers": {
        "mymachine::Rome1":  {
            "target_cluster": "primary"
            "invalidated_cluster_policy": "accept_ro"
        },
        "mymachine2::Rome2": {}
    }
}

如果特定路由选项未显示在 MySQL Router 实例中，如上面的 Rome2 示例所示，则意味着该实例未设置该策略，并且它遵循全局策略。Rome1 的输出显示 "target_cluster": "primary"，这与全局策略相同。这是因为 Rome1 已通过 clusterSet.setRoutingOption() 命令明确地将路由选项设置为 "primary"，在这种情况下，该选项将被显示。要清除路由选项，请将其设置为 null。


PREV   HOME   UP   NEXT
下载本手册
PDF (US Ltr) - 2.2Mb
PDF (A4) - 2.3Mb