运维首页 > 数据运维 > 朝花夕拾16章MySQL Shell 8.6 InnoDB ClusterSet状态和拓扑

朝花夕拾16章MySQL Shell 8.6 InnoDB ClusterSet状态和拓扑

2024年 2月 21日 77.0k 0

本节描述以下内容：

  • InnoDB ClusterSet 状态
  • InnoDB ClusterSet 拓扑
  • InnoDB ClusterSet 的 MySQL 路由器状态

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 集群的拓扑、每个集群中每个成员服务器的状态以及有关每个副本集群的 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()or *cluster*.getClusterSet() 命令。如果目标服务器实例是属于 InnoDB ClusterSet 部署一部分的 InnoDB Cluster 的成员，那么即使当前无法访问 InnoDB ClusterSet 部署的主集群，这些命令也会起作用。当您使用该对象时，目标服务器实例本身必须可访问。如果目标实例是已标记为无效的集群的成员，则该命令将返回警告，但仍返回对象ClusterSet。如果目标实例当前不是 InnoDB ClusterSet 部署的成员，则该命令将返回错误。该ClusterSet对象包含您从中检索它的服务器的连接详细信息，因此 ClusterSet您之前从现在离线的成员服务器检索到的对象将不再起作用，您需要从在线服务器再次获取它在 InnoDB ClusterSet 部署中。

该ClusterSet对象默认使用提取该对象时所用的帐户来执行需要权限的操作。当您使用适当的用户帐户连接到服务器实例以执行您想要使用它执行的操作时，获取该对象非常重要。InnoDB ClusterSet部署过程中的一些操作需要权限，为此使用对象中存储的默认用户帐户，因此该过程不需要存储任何其他用户帐户。对于已设置的 InnoDB ClusterSet 的监控和故障排除，InnoDB Cluster 管理员帐户是合适的。对于初始集群部署过程，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 Cluster 的总体状态。ClusterSet 中的 InnoDB Cluster 报告三种状态：

  • 全局状态（globalStatus字段）是InnoDB Cluster在InnoDB ClusterSet中的角色的状态。此状态显示集群是否仍然可以在 InnoDB ClusterSet 部署中正常运行，即使它存在一些问题，例如成员服务器当前离线。InnoDB 集群在故障转移期间可以被标记为无效，无论成员服务器的状态如何，如果是这样，这将显示为全局状态。
  • 集群状态（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 部署中运行良好。集群中至少有一台成员服务器处于组复制 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状态，并且集群中的成员数为3个或以上。

  • OK_PARTIAL

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

  • OK_NO_TOLERANCE

    集群中的所有成员服务器都处于Group Replication的ONLINE状态，但集群中的成员少于3个，因此对故障的容忍度不高。在这种情况下，集群运行良好，可以继续作为 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 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() 。

有关 的信息 *clusterSet*.setRoutingOption()，请参阅setRoutingOption()。

InnoDB ClusterSet 的 MySQL 路由器状态

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

穿过生命散发芬芳
数据运维
0 0

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF，云和恩墨技术通讯（2024年7月刊）
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论

穿过生命散发芬芳

这个人很懒，什么都没有留下～

文章8392 评论0