8.6 InnoDB ClusterSet状态和拓扑

MySQL 外壳 8.0 / 第 8 章 MySQL InnoDB ClusterSet / 8.6 InnoDB ClusterSet状态和拓扑

8.6 InnoDB ClusterSet状态和拓扑

本节介绍以下内容：

InnoDB ClusterSet 状态

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

您使用的 MySQL Shell 实例 clusterSet.status() 可以连接到 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 Cluster 以及每个副本集群的 ClusterSet 复制状态的基本信息。
extended: 1添加 ClusterSet 中每个 InnoDB Cluster 的拓扑、每个集群中每个单独成员服务器的状态，以及有关每个副本集群的 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."
}

要获取ClusterSet表示目标服务器实例的 InnoDB ClusterSet 的对象的句柄，请使用dba.getClusterSet()或 cluster.getClusterSet() 命令。如果目标服务器实例是作为 InnoDB ClusterSet 部署的一部分的 InnoDB Cluster 的成员，即使当前无法访问 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 Cluster 的整体状态。ClusterSet 中的 InnoDB Cluster 报告三种状态：

全局状态（globalStatus字段）是关于 InnoDB Cluster 在 InnoDB ClusterSet 中的角色的状态。此状态显示集群在 InnoDB ClusterSet 部署中是否仍然可以正常运行，即使它有一些问题，例如成员服务器当前处于脱机状态。InnoDB Cluster 在故障转移期间可以标记为无效，而不管成员服务器的状态如何，如果是这样，这将显示为全局状态。
集群状态（status字段）是 InnoDB 集群关于其自身功能的状态。此状态显示集群是否存在任何技术问题，例如一个或多个成员离线、仲裁丢失或组复制错误状态。集群可以容忍某些问题，但作为 InnoDB ClusterSet 部署的一部分仍然可以正常运行。出于这个原因，在默认的详细级别下， clusterSet.status() 函数仅报告导致全局状态问题的那些集群的集群状态。要查看 InnoDB ClusterSet 中所有集群的集群状态，无论它是否导致全局状态问题，请使用该 extended选项指定更高的详细级别。
ClusterSet 复制状态（clusterSetReplicationStatus字段）是副本 InnoDB Cluster 的 ClusterSet 复制通道的状态。此状态显示副本集群是否存在从主集群复制的任何问题，因此可以将这些问题与集群中成员服务器的任何技术问题分开考虑。副本 InnoDB Cluster 报告 ClusterSet 复制状态，无论它是否导致全局状态问题。主 InnoDB Cluster 没有此状态字段，因为 ClusterSet 复制通道未在主集群上运行。

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

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

OK: 集群在 InnoDB ClusterSet 部署中运行良好。集群中至少有一台成员服务器处于Group Replication ONLINE状态，并且复制组有quorum。如果集群是副本集群，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 Cluster 报告的集群状态（status字段）可以是以下之一，可以为主集群或副本集群报告：

OK: 集群中的所有成员服务器都处于Group Replication的ONLINE状态，并且集群中有3个或更多成员。
OK_PARTIAL: 集群中至少有3个成员服务器处于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: 集群没有法定人数，这意味着复制组的大多数成员服务器无法就决策达成一致。如果成员自愿离开或被组决策开除，组复制能够将自身重新配置为新的组号，因此法定人数的丢失意味着丢失的成员服务器已经失败或被网络分区与其他服务器切断。这种情况下的集群不能作为 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 Cluster 作为 Group Replication 组的技术问题有关，而不是复制过程。对于副本集群，ClusterSet 复制状态（clusterSetReplicationStatus字段）也报告如下：

OK: ClusterSet 复制通道正在运行。
STOPPED: ClusterSet 复制通道已以受控方式停止。当接收器线程、应用程序线程或两个线程都已停止时，会显示此状态。
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 Cluster 中每个成员服务器的 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() 函数的扩展输出提供。

InnoDB ClusterSet 的 MySQL 路由器状态

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

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 部署的全局策略，请 clusterSet.routingOptions() 在连接到 InnoDB ClusterSet 部署中的任何成员服务器时在 MySQL Shell 中发出。特定 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，这意味着该实例没有设置该策略，它遵循全局策略。Rome1shows的输出 "target_cluster": "primary"，与全局策略相同。这是因为Rome1已"primary"通过 clusterSet.setRoutingOption() 命令明确设置了路由选项，在这种情况下会显示该选项。要清除路由选项，请将其设置为null。

路由选项如下：

"target_cluster": "primary"

使用此设置，MySQL Router 将来自客户端应用程序的流量定向到 InnoDB ClusterSet 部署中的集群，该部署当前是主集群。主集群可以接受读取和写入流量。Follow the primary 模式是全局策略和单个 MySQL Router 实例的默认模式。

"target_cluster": "clusterName"

使用此设置，MySQL Router 将流量从应用程序定向到 InnoDB ClusterSet 部署中的指定集群，无论它当前是主集群还是副本集群。如果目标集群当前是主集群，则 MySQL Router 打开写入端口，应用程序可以写入实例。如果目标集群当前是只读副本集群，则 MySQL Router 只允许读取流量，拒绝写入流量。如果这种情况由于目标集群的切换或故障转移而发生变化，则 MySQL Router 会相应地更改允许的请求类型。如果应用程序只发出读取请求（可以在副本集群上发出）并且您希望将该流量路由到本地集群，则此模式很有用。请注意，集群名称区分大小写。

"invalidated_cluster_policy": "drop_all"

使用此设置，当集群标记为时 INVALIDATED，MySQL Router 不允许应用程序对其进行读取和写入流量。处于此状态的集群当前根本无法作为 InnoDB ClusterSet 部署的一部分运行，并且无法接收写入。它可能是在紧急故障转移过程中被标记为无效的前主集群，或者是由于在故障转移或受控切换期间无法访问或不可用而被标记为无效的副本集群。此设置是全局策略和单个 MySQL Router 实例的默认设置。

"invalidated_cluster_policy": "accept_ro"

使用此设置，当集群标记为时 INVALIDATED，MySQL Router 允许从应用程序读取流量但丢弃写入流量。尽管无效的集群不一定有任何技术问题，但数据正在变得陈旧，因此此设置意味着除非问题很快得到解决，否则将发生陈旧的读取。但是，在陈旧读取不是高优先级的情况下，此设置可以提供更高的可用性。

"stats_updates_frequency": "numberOfSeconds"

此选项以秒为单位定义 MySQL 路由器签入更新之间的间隔。

如果设置为 0（默认值），则不会进行定期更新。MySQL Router 将该值四舍五入为其 TTL 的倍数。例如：

如果低于 TTL，则向上取整为 TTL。例如：如果TTL=30和 stats_updates_frequency=1，则有效频率为 30 秒。
如果不是 TTL 的倍数，则向上取整并根据 TTL 进行调整。例如，如果 TTL=5和 stats_updates_frequency=11，则有效频率为 15 秒，或者如果 TTL=5和 stats_updates_frequency=13，则有效频率为 15 秒。

如果值为null，则选项值被清除，默认值生效。

您可以使用命令更改 InnoDB ClusterSet 部署中 MySQL Router 实例的路由选项 clusterSet.setRoutingOption() 。有关执行此操作的说明，请参阅第 8.5 节，“将 MySQL 路由器与 InnoDB ClusterSet 集成”。