MySQL 外壳 8.0  / 第 7 章 MySQL InnoDB 集群  /  7.7 监控InnoDB集群

7.7 监控InnoDB集群

本节介绍如何使用 AdminAPI 监视 InnoDB Cluster。

使用Cluster.describe()

要获取有关 InnoDB Cluster 本身结构的信息,请使用以下 Cluster.describe() 函数:

mysql-js> cluster.describe();
{
    "clusterName": "testCluster",
    "defaultReplicaSet": {
        "name": "default",
        "topology": [
            {
                "address": "ic-1:3306",
                "label": "ic-1:3306",
                "role": "HA"
            },
            {
                "address": "ic-2:3306",
                "label": "ic-2:3306",
                "role": "HA"
            },
            {
                "address": "ic-3:3306",
                "label": "ic-3:3306",
                "role": "HA"
            }
        ]
    }
}

此函数的输出显示了 InnoDB 集群的结构,包括其所有配置信息等。地址、标签和角色值与使用检查集群的状态 Cluster.status()中描述的值相匹配。

检查集群的状态 Cluster.status()

集群对象提供了status()一种方法,使您能够检查集群的运行情况。在检查 InnoDB Cluster 的状态之前,您需要通过连接到 InnoDB Cluster 对象的任何实例来获取对 InnoDB Cluster 对象的引用。但是,如果要更改集群的配置,则必须连接到“R/W”实例。Issuingstatus()根据您所连接的服务器实例知道的集群视图检索集群的状态,并输出状态报告。

重要的

实例在集群中的状态直接影响状态报告中提供的信息。因此,请确保您连接到的实例的状态为 ONLINE

有关 InnoDB 集群如何运行的信息,请使用集群的status()方法:

mysql-js> var cluster = dba.getCluster()
mysql-js> cluster.status()
{
    "clusterName": "testcluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "ic-1:3306",
        "ssl": "REQUIRED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "ic-1:3306": {
                "address": "ic-1:3306",
                "memberRole": "PRIMARY",
                "mode": "R/W",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            },
            "ic-2:3306": {
                "address": "ic-2:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            },
            "ic-3:3306": {
                "address": "ic-3:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            }
        }
        "topologyMode": "Single-Primary"
    },
    "groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}

的输出 Cluster.status() 提供以下信息:

  • clusterName: 期间分配给此集群的名称dba.createCluster()

  • defaultReplicaSet:属于 InnoDB Cluster 并包含数据集的服务器实例。

  • primary:仅在集群以单主模式运行时显示。显示当前主实例的地址。如果不显示该字段,则集群运行在多主模式下。

  • ssl:集群是否使用安全连接。显示 REQUIRED或的值DISABLED,具体取决于memberSslMode选项在 createCluster()或 期间的配置方式addInstance()。此参数返回的值对应于 group_replication_ssl_mode 实例上服务器变量的值。请参阅 第 7.6 节,“保护 InnoDB Cluster”

  • status:InnoDB Cluster 的状态。状态描述了该集群提供的高可用性。状态为以下之一:

    • OK:集群在线并且可以容忍n失败。集群中有三个或更多成员,并且它们正在运行。

    • OK_PARTIAL:集群在线并且可以容忍n失败。集群中至少有3个成员服务器处于Group Replication的在线状态。但是,一个或多个成员服务器当前未作为集群的活动成员参与。

    • OK_NO_TOLERANCE: 集群不能容忍任何故障。

    • OK_NO_TOLERANCE_PARTIAL: 集群不能容忍任何故障。集群中有一台或两台成员服务器在线,但有一台或多台服务器处于离线、恢复、错误或无法访问状态。由于某些成员不可用,集群对故障没有足够的容忍度。

    • NO_QUORUM:集群没有法定人数,这意味着复制组的大多数成员服务器无法就决策达成一致,并且无法处理写入事务。

    • OFFLINE: 群内所有成员均离线。

    • ERROR: 集群中没有在线成员。

    • UNREACHABLE: 没有连接到任何在线成员。

    • UNKNOWN: 没有连接到任何在线成员。

    • FENCED_WRITES: 集群被隔离以防止写入流量。

  • topology:MySQL服务器实例的状态。状态为以下之一:

    • Host name of instance:实例的主机名,例如 "localhost:3310"

    • memberRole组复制插件报告的成员角色,请参阅表的 MEMBER_ROLEreplication_group_members

    • mode:服务器是读写(“R/W”)还是只读(“R/O”)。从版本 8.0.17 开始,这 super_read_only 取决于实例上变量的当前状态,以及集群是否有法定人数。在以前的版本中,mode 的值取决于实例是作为主实例还是辅助实例。通常,如果实例是主实例,则模式为“R/W”,如果实例是辅助实例,则模式为“R/O”。集群中没有可见仲裁的任何实例都被标记为“R/O”,而不管 super_read_only 变量的状态如何。

    • replicationLag:返回以下值之一:

      • 最后一个事务提交时间戳和最后一个事务应用时间戳之间的时间差,格式为 HH:MM:SS。

        如果使用多个工作人员,则从执行最旧事务的工作人员中检索该值。

      • null: 复制连接或 SQL 线程未运行。

      • applier_queue_applied: 应用程序队列已应用所有内容。即,如果最后排队的事务和最后申请的事务相同,或者申请的事务为0。

    • role:这个实例在集群中提供什么功能。目前只有 HA,以实现高可用性。

    • status:集群中此元素的状态。状态为以下之一:

      • ONLINE:实例在线并参与集群。

      • OFFLINE:该实例已失去与其他实例的连接。

      • RECOVERING:该实例正在尝试通过检索它在成为在线成员之前所需的事务来与集群同步。

      • UNREACHABLE:实例已失去与集群的通信。

      • ERROR:实例在恢复阶段或应用事务时遇到错误。

        重要的

        实例进入ERROR 状态后,该 super_read_only 选项将设置为ON。要离开该ERROR状态,您必须手动配置实例 super_read_only=OFF

      • (MISSING):实例的状态,它是已配置集群的一部分,但当前不可用。

        笔记

        state是InnoDB Cluster特有的MISSING,不是Group Replication产生的状态。MySQL Shell 使用此状态来指示在元数据中注册但无法在实时集群视图中找到的实例。

    • groupInformationSourceMember: 用于获取集群信息的内部连接,显示为类似 URI 的连接字符串。通常是最初用于创建集群的连接。

  • version:实例上运行的 MySQL 服务器版本。有关详细信息,请参阅 检查实例上的 MySQL 版本

要显示有关集群的更多信息,请使用该 extended选项。从 8.0.17 版本开始,该 extended选项支持整数或布尔值。要配置 提供的附加信息,请使用以下值: Cluster.status({'extended':value})

  • 0:禁用附加信息,默认

  • 1:包括有关组复制协议版本、组名称、通信堆栈、集群成员 UUID、集群成员角色和组复制报告的状态的信息,以及受保护的系统变量列表

  • 2:包括有关连接和应用程序处理的事务的信息

  • 3:包含有关每个集群成员执行的复制的更详细统计信息。

使用布尔值设置extended等同于设置整数值 0 和 1。在 8.0.17 之前的版本中,该extended选项仅为布尔值。同样,之前的版本使用 queryMembers布尔选项来提供有关集群中实例的更多信息,相当于设置extended为 3。该 queryMembers选项已弃用,并计划在未来版本中删除。

当您发出 Cluster.status({'extended':1})extended选项设置为 true时,输出包括:

  • defaultReplicaSet对象的以下附加属性:

  • 对象的每个对象的以下附加属性 topology

    • fenceSysVars包含由 AdminAPI 配置的受防护系统变量名称的列表。目前考虑的受保护系统变量是 read_only, super_read_onlyoffline_mode。列出系统变量而不考虑它们的值。

    • instanceErrors对于每个实例,显示可以为该实例检测到的任何诊断信息。例如,如果实例是辅助实例并且 super_read_only 变量未设置为ON,则会显示警告。此信息可用于排除错误。

    • memberId每个集群成员 UUID。

    • memberStateGroup Replication 插件报告的 Member State,请参阅表的 MEMBER_STATEreplication_group_members

查看有关恢复和常规事务 I/O、应用程序工作线程统计信息和任何滞后的信息;应用程序协调器统计信息,如果启用了并行复制应用程序;错误,以及来自接收方和应用程序线程的其他信息,使用 2 或 3 的值 extended。当您使用这些值时,将打开到集群中每个实例的连接,以便可以查询其他实例特定的统计信息。输出中包含的确切统计信息取决于实例的状态和配置以及服务器版本。此信息与 replication_group_member_stats 表中显示的信息相匹配,请参阅匹配列的说明以获取更多信息。实例是ONLINEtransactions在输出中包含一个部分。RECOVERING输出中包含一个 recovery部分的实例。当您设置extended为 2 时,无论哪种情况,这些部分都可以包含以下内容:

  • appliedCount: 看 COUNT_TRANSACTIONS_REMOTE_APPLIED

  • checkedCount: 看 COUNT_TRANSACTIONS_CHECKED

  • committedAllMembers: 看 TRANSACTIONS_COMMITTED_ALL_MEMBERS

  • conflictsDetectedCount: 看 COUNT_CONFLICTS_DETECTED

  • inApplierQueueCount: 看 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE

  • inQueueCount: 看 COUNT_TRANSACTIONS_IN_QUEUE

  • lastConflictFree: 看 LAST_CONFLICT_FREE_TRANSACTION

  • proposedCount: 看 COUNT_TRANSACTIONS_LOCAL_PROPOSED

  • rollbackCount: 看 COUNT_TRANSACTIONS_LOCAL_ROLLBACK

设置extended为 3 时,该 connection部分显示 replication_connection_status 表中的信息。值 3 相当于将不推荐使用的 queryMembers选项设置为 true。该connection 部分可以包含以下内容:

currentlyQueueing部分包含有关当前排队的事务的信息:

  • immediateCommitTimestamp: 看 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToNowTime:见 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 负号NOW()

  • originalCommitTimestamp: 看 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime:见 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 负号NOW()

  • startTimestamp: 看 QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP

  • transaction: 看 QUEUEING_TRANSACTION

  • lastHeartbeatTimestamp: 看 LAST_HEARTBEAT_TIMESTAMP

lastQueued部分包含有关最近排队的事务的信息:

  • endTimestamp: 看 LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP

  • immediateCommitTimestamp: 看 LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToEndTime: LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 减号NOW()

  • originalCommitTimestamp: 看 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTime: LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 减号NOW()

  • queueTime: LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP 减号 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP

  • startTimestamp: 看 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP

  • transaction: 看 LAST_QUEUED_TRANSACTION

  • receivedHeartbeats: 看 COUNT_RECEIVED_HEARTBEATS

  • receivedTransactionSet: 看 RECEIVED_TRANSACTION_SET

  • threadId: 看 THREAD_ID

使用多线程副本的实例有一个 workers部分包含有关工作线程的信息,并与 replication_applier_status_by_worker 表中显示的信息相匹配。

lastApplied部分显示有关工作人员申请的最后一笔交易的以下信息:

  • applyTime:见 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP 负号 LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP

  • endTimestamp: 看 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP

  • immediateCommitTimestamp: 看 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToEndTime:见 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 负号NOW()

  • originalCommitTimestamp: 看 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTime:见 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 负号NOW()

  • startTimestamp: 看 LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP

  • transaction: 看 LAST_APPLIED_TRANSACTION

currentlyApplying部分显示有关工作程序当前正在应用的事务的以下信息:

  • immediateCommitTimestamp: 看 APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToNowTime:见 APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 负号NOW()

  • originalCommitTimestamp: 看 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime:见 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 负号NOW()

  • startTimestamp: 看 APPLYING_TRANSACTION_START_APPLY_TIMESTAMP

  • transaction: 看 APPLYING_TRANSACTION

lastProcessed部分包含有关工作人员处理的最后一笔交易的以下信息:

  • bufferTime: LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 减号 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP

  • endTimestamp: 看 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

  • immediateCommitTimestamp: 看 LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToEndTime: LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 减号 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

  • originalCommitTimestamp: 看 LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTime: LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 减号 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

  • startTimestamp: 看 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP

  • transaction: 看 LAST_PROCESSED_TRANSACTION

如果启用了并行复制应用程序,则 workers 数组中的对象数量 transactionsrecovery 与配置的 workers 数量相匹配,并且包含一个额外的协调器对象。显示的信息与 replication_applier_status_by_coordinator 表中的信息相匹配。该对象可以包含:

currentlyProcessing部分包含有关工作人员正在处理的交易的以下信息:

  • immediateCommitTimestamp: 看 PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToNowTime: PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 减号NOW()

  • originalCommitTimestamp: 看 PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime: PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 减号NOW()

  • startTimestamp: 看 PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP

  • transaction: 看 PROCESSING_TRANSACTION

worker如果在表中检测到错误,对象将具有以下信息 replication_applier_status_by_worker

  • lastErrno: 看 LAST_ERROR_NUMBER

  • lastError: 看 LAST_ERROR_MESSAGE

  • lastErrorTimestamp: 看 LAST_ERROR_TIMESTAMP

connection如果在表中检测到错误,对象将具有以下信息 replication_connection_status

  • lastErrno: 看 LAST_ERROR_NUMBER

  • lastError: 看 LAST_ERROR_MESSAGE

  • lastErrorTimestamp: 看 LAST_ERROR_TIMESTAMP

coordinator如果在表中检测到错误,对象将具有以下信息 replication_applier_status_by_coordinator

  • lastErrno: 看 LAST_ERROR_NUMBER

  • lastError: 看 LAST_ERROR_MESSAGE

  • lastErrorTimestamp: 看 LAST_ERROR_TIMESTAMP

监控恢复操作

的输出 Cluster.status() 显示有关处于RECOVERING状态的实例的恢复操作进度的信息。显示使用 MySQL 克隆或增量恢复进行恢复的实例的信息。监控这些字段:

  • recoveryStatusText字段包括有关正在使用的恢复类型的信息。当 MySQL Clone 工作时,该字段显示Cloning in progress。当增量恢复工作时,该字段显示正在进行分布式恢复

  • 当使用 MySQL Clone 时,该 recovery字段包含一个字典,其中包含以下字段:

    • cloneStartTime: 克隆过程开始的时间戳

    • cloneState: 克隆进度的状态

    • currentStage:克隆进程已达到的当前阶段

    • currentStageProgress:当前阶段进度,以完成百分比表示

    • currentStageState: 当前阶段状态

    示例 Cluster.status() 输出,为简洁起见进行了修剪:

    ...
    "recovery": {
    "cloneStartTime": "2019-07-15 12:50:22.730",
    "cloneState": "In Progress",
    "currentStage": "FILE COPY",
    "currentStageProgress": 61.726837675213865,
    "currentStageState": "In Progress"
    },
    "recoveryStatusText": "Cloning in progress",
    ...
  • 当使用增量恢复并且该 extended选项设置为 1 或更大时,该recovery字段包括一个具有以下字段的字典:

    • state: group_replication_recovery通道 状态

    • recoveryChannel:执行增量恢复或恢复通道状态未关闭的实例显示。增量恢复利用接收线程从源接收事务,应用程序线程将接收到的事务应用到实例上。提供以下信息:

      • applierQueuedTransactionSetSize:当前排队等待应用的事务数。

      • applierState:复制应用程序的当前状态, ON或者OFF

      • applierStatus:应用程序线程的当前状态。applierThreadState 字段中显示的状态的聚合。可以是以下之一:

        • APPLIED_ALL: 没有等待应用的排队事务

        • APPLYING: 有正在申请的交易

        • ON: 线程已连接并且没有排队的事务

        • ERROR: 应用交易时出错

        • OFF: applier线程被禁用

      • applierThreadState:任何应用程序线程的当前状态。提供有关应用程序线程正在做什么的详细信息。有关详细信息,请参阅 复制 SQL 线程状态

      • receiverStatus:接收线程的当前状态。receiverThreadState字段中显示的状态的聚合 。可以是以下之一:

        • ON: 接收线程已成功连接并准备接收

        • CONNECTING:接收器线程正在连接到源

        • ERROR: 接收交易时出错

        • OFF: 接收器线程已正常断开连接

      • receiverThreadState:接收线程的当前状态。提供关于接收器线程正在做什么的详细信息。有关详细信息,请参阅 复制 I/O(接收器)线程状态

      • source:正在应用的事务的来源。

    示例 Cluster.status() 输出,为简洁起见进行了修剪:

    ...
    "recovery": {
                        "recoveryChannel": {
                            "applierQueuedTransactionSetSize": 2284, 
                            "applierStatus": "APPLYING", 
                            "applierThreadState": "Opening tables", 
                            "receiverStatus": "ON", 
                            "receiverThreadState": "Queueing master event to the relay log", 
                            "source": "ic-2:3306"
                        }, 
                        "state": "ON"
                    },
    ...

InnoDB Cluster 和组复制协议

从 MySQL 8.0.16 开始,Group Replication 有了组通信协议的概念,请参阅 设置组的通信协议版本 以获取背景信息。组复制通信协议版本通常必须明确管理,并设置为适应您希望组支持的最旧的 MySQL 服务器版本。但是,每当使用 AdminAPI 操作更改集群拓扑时,InnoDB Cluster 会自动透明地管理其成员的通信协议版本。集群始终使用当前属于集群或加入集群的所有实例所支持的最新通信协议版本。

  • 当实例加入集群、移除实例、重新加入集群,或对集群进行重新扫描或重启操作时,通信协议版本自动设置为当前最早的MySQL Server实例支持的版本版本。

  • 当您通过从集群中删除实例、升级它们并将它们添加回集群来执行滚动升级时,当旧 MySQL Server 版本的最后一个剩余实例在之前从集群中删除时,通信协议版本会自动升级它的升级。

要查看集群中使用的通信协议版本,请使用 启用Cluster.status()extended选项的功能。通信协议版本在该 GRProtocolVersion字段中返回,前提是集群具有法定人数并且没有集群成员不可访问。

检查实例上的MySQL版本

以下操作可以报告有关实例上运行的 MySQL Server 版本的信息:

  • Cluster.status()

  • Cluster.describe()

  • Cluster.rescan()

行为因 Cluster对象会话的 MySQL 服务器版本而异。

  • Cluster.status()

    如果满足以下任一要求, version则为对象的每个实例 JSON 对象返回一个字符串属性topology

    • 对象的Cluster当前会话版本为 8.0.11 或更高版本。

    • 对象的Cluster当前会话正在运行早于 8.0.11 版的版本,但extended 选项设置为 3(或弃用 queryMembers的是 true)。

    例如在运行版本 8.0.16 的实例上:

    "topology": {
        "ic-1:3306": {
            "address": "ic-1:3306",
            "mode": "R/W",
            "readReplicas": {},
            "role": "HA",
            "status": "ONLINE",
            "version": "8.0.16"
    }

    例如在运行版本 5.7.24 的实例上:

    "topology": {
        "ic-1:3306": {
            "address": "ic-1:3306",
            "mode": "R/W",
            "readReplicas": {},
            "role": "HA",
            "status": "ONLINE",
            "version": "5.7.24"
    }
  • Cluster.describe()

    如果Cluster对象的当前会话是 8.0.11 或更高版本, version则为对象的每个实例 JSON 对象返回一个字符串topology 属性

    例如在运行版本 8.0.16 的实例上:

    "topology": [
        {
            "address": "ic-1:3306",
            "label": "ic-1:3306",
            "role": "HA",
            "version": "8.0.16"
        }
    ]
  • Cluster.rescan()

    如果Cluster对象的当前会话是 8.0.11 或更高版本,并且 Cluster.rescan() 操作检测到不属于集群的实例,version则为对象的每个实例 JSON 对象返回一个字符串属性 newlyDiscoveredInstance

    例如在运行版本 8.0.16 的实例上:

    "newlyDiscoveredInstances": [
        {
            "host": "ic-4:3306",
            "member_id": "82a67a06-2ba3-11e9-8cfc-3c6aa7197deb",
            "name": null,
            "version": "8.0.16"
        }
    ]