MySQL Shell 9.0  /  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 集群管理员帐户是合适的。对于初始集群部署过程，InnoDB 集群服务器配置帐户是合适的。有关详细信息，请参见 第 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 集群在其自身运行方面的状态。此状态显示集群是否存在任何技术问题，例如一个或多个成员处于脱机状态、丢失仲裁或组复制错误状态。集群可以容忍某些问题，但仍可以作为 InnoDB ClusterSet 部署的一部分正常运行。因此，在默认详细级别下，clusterSet.status() 函数仅报告那些导致全局状态问题的集群的集群状态。要查看 InnoDB ClusterSet 中所有集群的集群状态（无论它是否导致全局状态问题），请使用 extended 选项指定更高的详细级别。

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

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

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

OK（正常）

集群在 InnoDB ClusterSet 部署中运行正常。集群中至少有一个成员服务器处于组复制的 ONLINE 状态，并且复制组具有仲裁。如果集群是副本集群，则 ClusterSet 复制状态也为 OK。此全局状态并不一定意味着集群没有技术问题。某些成员可能处于脱机状态，或者集群的成员可能太少，无法容忍故障。但是，集群的运行状况足以继续作为 InnoDB ClusterSet 部署的一部分。主集群或副本集群可以具有此全局状态。

OK_NOT_REPLICATING（正常，未复制）

集群运行正常，但 ClusterSet 复制通道上的复制已停止，原因是受控停止或复制错误。只有副本集群可以具有此全局状态。

OK_NOT_CONSISTENT（正常，不一致）

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

OK_MISCONFIGURED（正常，配置错误）

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

NOT_OK

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

UNKNOWN

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

INVALIDATED

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

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

OK（正常）

集群中的所有成员服务器都处于组复制的 ONLINE 状态，并且集群中有三个或更多成员。

OK_PARTIAL

集群中至少有三个成员服务器处于组复制的 ONLINE 状态。但是，一个或多个成员服务器处于组复制的 OFFLINE、RECOVERING、ERROR 或 UNREACHABLE 状态，因此它们当前未作为集群的活动成员参与。处于这种情况的集群足以继续作为 InnoDB ClusterSet 部署的一部分运行，但要将其恢复到 OK 状态，请解决成员服务器的问题。

OK_NO_TOLERANCE

集群中的所有成员服务器都处于组复制的 ONLINE 状态，但集群中的成员少于三个，因此它没有足够的容错能力。处于这种情况的集群足以继续作为 InnoDB ClusterSet 部署的一部分运行，但要将其恢复到 OK 状态，请添加更多成员服务器。

OK_NO_TOLERANCE_PARTIAL

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

NO_QUORUM

集群没有仲裁，这意味着大多数复制组的成员服务器不可用于就决策达成一致。如果成员自愿离开或被组决定驱逐，则组复制能够将自身重新配置为新的组编号，因此仲裁丢失意味着丢失的成员服务器要么出现故障，要么被网络分区与其他服务器断开连接。处于这种情况的集群无法作为 InnoDB ClusterSet 部署的一部分运行。要将处于此状态的集群恢复到 OK 状态，请参阅第 8.9 节“InnoDB ClusterSet 修复和重新加入”。

OFFLINE

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

ERROR

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

UNKNOWN

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

INVALIDATED

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

集群状态与 InnoDB 集群作为组复制组的技术问题相关，而不是与复制过程相关。对于副本集群，还将报告 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。


上一页   首页   向上   下一页
下载本手册
PDF (US Ltr) - 2.3Mb
PDF (A4) - 2.3Mb