怎么查看 mysql 用的什么集群模式 mysql查看集群状态命令

转载

编程之翼 2024-04-26 15:02:25

文章标签 mysql 数据库 MySQL Shell InnoDB ClusterSet 文章分类 MySQL 数据库

文章目录

InnoDB ClusterSet 状态
InnoDB ClusterSet 拓扑
InnoDB ClusterSet 的 MySQL Router 状态

InnoDB ClusterSet 状态

AdminAPI 的 clusterSet.status() 命令返回描述 InnoDB clusterSet 部署状态的 JSON 对象。输出包括 InnoDB ClusterSet 部署本身的状态以及 ClusterSet 中每个 InnoDB Cluster 的全局和集群状态。扩展输出添加了每个集群中每个成员服务器的状态、有关 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 字段）可以是以下之一：

InnoDB ClusterSet 中的主集群运行正常，所有副本集群运行正常。 AVAILABLE InnoDB ClusterSet 中的主集群功能正常，但一个或多个副本集群功能受损或不正常。 UNAVAILABLE InnoDB ClusterSet 中的主集群无法运行，因为它处于脱机状态或已失去法定人数（quorum），或者 MySQL Shell 无法联系主集群以确定其状态。

InnoDB ClusterSet 部署报告的总体 ClusterSet 状态取决于每个 InnoDB Cluster 的总体状态。ClusterSet 中的 InnoDB Cluster 报告三种状态：

全局状态（globalStatus 字段）是 InnoDB Cluster 在 InnoDB ClusterSet 中角色的状态。该状态显示集群在 InnoDB ClusterSet 部署中是否仍能正常运行，即使它存在一些问题，例如成员服务器当前处于脱机状态。无论成员服务器的状态如何，InnoDB Cluster 都可以在故障切换期间标记为无效，如果是，则显示为全局状态。
集群状态（status 字段）是 InnoDB Cluster 自身功能的状态。此状态显示集群是否存在任何技术问题，例如一个或多个成员脱机、法定人数不足或组复制错误状态。集群可以容忍某些问题，但作为 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 字段）可以是以下之一：

集群在 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 Cluster 报告的集群状态（ status 字段）可以是以下之一，这些都可以为主集群或副本集群报告：

集群中的所有成员服务器都处于组复制的 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 Repair and Rejoin”。

OFFLINE 集群中的所有成员服务器都处于 Group Replication 的 OFFLINE 状态。这种情况下的集群不能作为 InnoDB ClusterSet 部署的一部分。如果当前不应该脱机，则要将处于此状态的集群设置为 OK 状态，请参阅 8.9 InnoDB ClusterSet 的修复和重新加入。

ERROR 集群中的所有成员服务器都处于组复制的 ERROR 状态。这种情况下的集群不能作为 InnoDB ClusterSet 部署的一部分。要使处于此状态的集群达到

OK 状态，请参阅

8.9 InnoDB ClusterSet 的修复和重新加入。

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

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

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 集群中每个成员服务器的 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 Router 状态

要查看为 InnoDB ClusterSet 注册的 MySQL Router 实例，请在连接到 InnoDB ClusterSet 部署中的任何成员服务器时，在 MySQL Shell 中执行 clusterSet.listRouters() 命令。该命令返回所有注册的 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 路由器实例的名称、使用 MySQL 经典协议和 X 协议的读写流量的端口号、目标集群以及实例最后一次登录目标集群的时间。如果 MySQL Router 的版本低于使用此 InnoDB ClusterSet 部署所需的版本，则实例信息会说明这一点。

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

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 已经通过 如果没有为 MySQL Router 实例显示特定的路由选项，如上面的 Rome2 示例所示，这意味着该实例没有该策略集，它遵循全局策略。Rome1 的输出显示“ target_cluster”：“primary”，这与全局策略相同。这是因为 Rome1 已经通过 clusterSet.setRoutingOption()命令将路由选项显式设置为“ primary”` ，在这种情况下会显示该选项。要清除路由选项，请将其设置为空。

路由选项如下：

使用此设置，MySQL Router 将流量从客户端应用程序引导到 InnoDB ClusterSet 部署中的集群，该集群当前是主集群。主集群可以接受读和写流量。遵循主模式是全局策略和单个 MySQL 路由器实例的默认模式。

“target_cluster”: “clusterName”

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

“invalidated_cluster_policy”: “drop_all”

使用此设置，当集群标记为 INVALIDATED 时，MySQL Router 将禁止应用程序对其进行读写通信。处于此状态的集群当前根本没有作为 InnoDB ClusterSet 部署的一部分运行，因此无法接收写入。它可能是在紧急故障切换过程中被标记为无效的前主群集，也可能是因为在故障切换或受控切换时无法访问或不可用而被标记为失效的副本群集。此设置是全局策略和单个 MySQL 路由器实例的默认设置。

“invalidated_cluster_policy”: “accept_ro”

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

“stats_updates_frequency”: “numberOfSeconds”

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

如果设置为 0（默认值），则不进行定期更新。MySQL 路由器将该值舍入为 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 秒。

如果该值为空，则清除选项值，默认值将生效。

use_replica_primary_as_rw: [true | false]

此选项指示 MySQL Router 允许它打开或关闭以特定群集为目标的路由器上的读写（R/W）端口（其中 target_cluster 未设置为 primary ），从而允许您在副本集群上使用 R/W 端口。副本集群继续只接受 R/O 流量。在发生切换或故障切换时，R/W 端口保持不变。

如果设置为 true，则打开副本集群中的 MySQL 路由器 R/W 端口。

如果设置为 false（默认值），则路由器的行为不变，并且在副本集群中关闭R/W端口。

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

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。