MySQL :: MySQL 8.4 参考手册 :: 25.6.2.1 NDB Cluster：集群日志中的消息

版本 8.4

8.0 日语

MySQL 8.4 参考手册 / ... / NDB Cluster：集群日志中的消息

25.6.2.1 NDB Cluster：集群日志中的消息

下表列出了最常见的 NDB 集群日志消息。有关集群日志、日志事件和事件类型的详细信息，请参阅第 25.6.3 节，“NDB Cluster 中生成的事件报告”。这些日志消息还对应于 MGM API 中的日志事件类型；有关与集群 API 开发人员相关的感兴趣的信息，请参阅 Ndb_logevent_type 类型。

表 25.25 常见的 NDB 集群日志消息

日志消息	描述	事件名称	事件类型	优先级	严重性
`节点 mgm_node_id：节点 data_node_id 已连接`	具有节点 ID `node_id` 的数据节点已连接到管理服务器（节点 `mgm_node_id`）。	`已连接`	`连接`	8	`信息`
`节点 mgm_node_id：节点 data_node_id 已断开连接`	具有节点 ID `data_node_id` 的数据节点已断开与管理服务器（节点 `mgm_node_id`）的连接。	`已断开连接`	`连接`	8	`警报`
`节点 data_node_id：与节点 api_node_id 的通信已关闭`	具有节点 ID `api_node_id` 的 API 节点或 SQL 节点不再与数据节点 `data_node_id` 通信。	`通信已关闭`	`连接`	8	`信息`
`节点 data_node_id：与节点 api_node_id 的通信已打开`	具有节点 ID `api_node_id` 的 API 节点或 SQL 节点现在正在与数据节点 `data_node_id` 通信。	`通信已打开`	`连接`	8	`信息`
`节点 mgm_node_id：节点 api_node_id：API version`	具有节点 ID `api_node_id` 的 API 节点已使用 `NDB` API 版本 `version`（通常与 MySQL 版本号相同）连接到管理节点 `mgm_node_id`。	`已连接的 API 版本`	`连接`	8	`信息`
`节点 node_id：全局检查点 gci 已启动`	具有 ID `gci` 的全局检查点已启动；节点 `node_id` 是负责此全局检查点的 master。	`全局检查点已启动`	`检查点`	9	`信息`
`节点 node_id：全局检查点 gci 已完成`	具有 ID `gci` 的全局检查点已完成；节点 `node_id` 是负责此全局检查点的 master。	`全局检查点已完成`	`检查点`	10	`信息`
`节点 node_id：本地检查点 lcp 已启动。保留 GCI = current_gci 最旧可恢复 GCI = old_gci`	具有序列 ID `lcp` 的本地检查点已在节点 `node_id` 上启动。可以使用索引 `current_gci` 获取最近的 GCI，而集群可以从索引 `old_gci` 获取最旧的 GCI 进行恢复。	`本地检查点已启动`	`检查点`	7	`信息`
`节点 node_id：本地检查点 lcp 已完成`	节点 `node_id` 上具有序列 ID `lcp` 的本地检查点已完成。	`本地检查点已完成`	`检查点`	8	`信息`
`节点 node_id：本地检查点在 CALCULATED_KEEP_GCI 中停止`	节点无法确定最新的可用 GCI。	`LCP 停止于 CalcKeepGci`	`检查点`	0	`警报`
`节点 node_id：表 ID = table_id，片段 ID = fragment_id 已在节点 node_id 上完成 LCP，maxGciStarted：started_gci，maxGciCompleted：completed_gci`	表片段已在节点 `node_id` 上写入磁盘。正在进行的 GCI 索引为 `started_gci`，最近完成的 GCI 索引为 `completed_gci`。	`LCP 片段已完成`	`检查点`	11	`信息`
`节点 node_id：ACC 被阻塞 num_1 次，TUP 被阻塞 num_2 次，最近一秒`	撤消日志被阻塞，因为日志缓冲区即将溢出。	`撤消日志被阻塞`	`检查点`	7	`信息`
`节点 node_id：已启动，version`	运行 `NDB` 版本 `version` 的数据节点 `node_id` 正在启动。	`NDBStart 已启动`	`启动`	1	`信息`
`节点 node_id：已启动，version`	运行 `NDB` 版本 `version` 的数据节点 `node_id` 已成功启动。	`NDBStart 已完成`	`启动`	1	`信息`
`节点 node_id：重启完成后收到 STTORRY`	节点已收到信号，表明集群重启已完成。	`已收到 STTORRY`	`启动`	15	`信息`
`节点 node_id：启动阶段 phase 已完成（type）`	节点已完成 `type` 启动的启动阶段 `phase`。有关启动阶段的列表，请参阅第 25.6.4 节，“NDB Cluster 启动阶段摘要”。（`type` 是 `initial`、`system`、`node`、`initial node` 或 `<Unknown>` 之一。）	`启动阶段已完成`	`启动`	4	`信息`
`节点 node_id：CM_REGCONF 主席 = president_id，自身节点 = own_id，动态 ID = dynamic_id`	节点 `president_id` 已被选为 “主席”。 `own_id` 和 `dynamic_id` 应始终与报告节点的 ID (`node_id`) 相同。	`CM_REGCONF`	`启动`	3	`信息`
`节点 node_id：来自节点 president_id 到自身节点 node_id 的 CM_REGREF。原因 = cause`	报告节点（ID `node_id`）无法接受节点 `president_id` 作为主席。问题的原因被给出为 `Busy`、`Election with wait = false`、`Not president`、`Election without selecting new candidate` 或 `No such cause` 之一。	`CM_REGREF`	`启动`	8	`信息`
`节点 node_id：我们是具有动态 ID dynamic_id 的节点 own_id，我们的左邻居是节点 id_1，我们的右邻居是节点 id_2`	节点已在集群中发现其邻居节点（节点 `id_1` 和节点 `id_2`）。 `node_id`、`own_id` 和 `dynamic_id` 应始终相同；如果它们不同，则表示集群节点存在严重配置错误。	`FIND_NEIGHBOURS`	`启动`	8	`信息`
`节点 node_id：type 关闭已启动`	节点已收到关闭信号。关闭的 `type` 为 `Cluster` 或 `Node`。	`NDBStop 已启动`	`启动`	1	`信息`
`节点 node_id：节点关闭已完成` [`, action`] [`由信号 signal 启动。`]	节点已关闭。此报告可能包含一个 `action`，如果存在，则为 `restarting`、`no start` 或 `initial` 之一。该报告还可能包含对 `NDB` 协议 `signal` 的引用；有关可能的信号，请参阅操作和信号。	`NDBStop 已完成`	`启动`	1	`信息`
`节点 node_id：强制节点关闭已完成` [`, action`]`.` [`发生在启动阶段 start_phase 期间。`] [ `由 signal 启动。`] [`由错误 error_code 引起：'error_message(error_classification)。 error_status'.` [`(附加信息 extra_code)`]]	节点已被强制关闭。随后采取的 `action`（如果存在，则为 `restarting`、`no start` 或 `initial` 之一）也会在报告中显示。如果关闭发生在节点启动期间，则报告会包含节点失败时的 `start_phase`。如果这是由发送到节点的 `signal` 引起的，则该信息也会提供（有关详细信息，请参阅操作和信号）。如果已知导致失败的错误，则也会包含在内；有关 `NDB` 错误消息和分类的详细信息，请参阅 NDB Cluster API 错误。	`NDBStop 已强制执行`	`启动`	1	`警报`
`节点 node_id：节点关闭已中止`	节点关闭过程已由用户中止。	`NDBStop 已中止`	`启动`	1	`信息`
`节点 node_id：StartLog：[GCI 保留：keep_pos 最后完成：last_pos 最新的可恢复项：restore_pos]`	这报告了节点启动期间引用的全局检查点。`keep_pos` 之前的重做日志将被删除。 `last_pos` 是数据节点参与的最后一个全局检查点；`restore_pos` 是实际用于恢复所有数据节点的全局检查点。	`StartREDOLog`	`启动`	4	`信息`
`startup_message` [单独列出；请参阅下文。]	在不同情况下，可能会记录许多可能的启动消息。这些消息将单独列出；请参阅第 25.6.2.2 节，“NDB Cluster 日志启动消息”。	`StartReport`	`启动`	4	`信息`
`节点 node_id：节点重启已完成，字典信息的副本`	已完成将数据字典信息复制到已重启的节点。	`NR_CopyDict`	`NodeRestart`	8	`信息`
`节点 node_id: 节点重启已完成复制分布信息`	已完成将数据分布信息复制到已重启的节点。	`NR_CopyDistr`	`NodeRestart`	8	`信息`
`节点 node_id: 节点重启开始将碎片复制到节点 node_id`	已开始将碎片复制到起始数据节点 `node_id`	`NR_CopyFragsStarted`	`NodeRestart`	8	`信息`
`节点 node_id: 表 ID = table_id，碎片 ID = fragment_id 已复制到节点 node_id`	来自表 `table_id` 的碎片 `fragment_id` 已复制到数据节点 `node_id`	`NR_CopyFragDone`	`NodeRestart`	10	`信息`
`节点 node_id: 节点重启已完成将碎片复制到节点 node_id`	已完成将所有表碎片复制到重启的数据节点 `node_id`	`NR_CopyFragsCompleted`	`NodeRestart`	8	`信息`
`节点 node1_id: 节点 node2_id 的故障已完成`	数据节点 `node1_id` 已检测到数据节点 `node2_id` 的故障	`NodeFailCompleted`	`NodeRestart`	8	`警报`
`所有节点已完成节点 node_id 的故障`	所有（剩余）数据节点已检测到数据节点 `node_id` 的故障	`NodeFailCompleted`	`NodeRestart`	8	`警报`
`节点 node_idblock 的故障已完成`	在 `block``NDB` 内核块中已检测到数据节点 `node_id` 的故障，其中块为 1，属于 `DBTC`、`DBDICT`、`DBDIH` 或 `DBLQH`；有关更多信息，请参见 NDB 内核块	`NodeFailCompleted`	`NodeRestart`	8	`警报`
`节点 mgm_node_id: 节点 data_node_id 出现故障。故障时的节点状态为 state_code`	一个数据节点出现故障。其故障时的状态由仲裁状态代码 `state_code` 描述：可能的状态代码值可以在文件 `include/kernel/signaldata/ArbitSignalData.hpp` 中找到。	`NODE_FAILREP`	`NodeRestart`	8	`警报`
`主席重启仲裁线程 [state=state_code]` 或 `准备仲裁节点 node_id [ticket=ticket_id]` 或 `接收仲裁节点 node_id [ticket=ticket_id]` 或 `启动仲裁节点 node_id [ticket=ticket_id]` 或 `丢失仲裁节点 node_id - 进程故障 [state=state_code]` 或 `丢失仲裁节点 node_id - 进程退出 [state=state_code]` 或 `丢失仲裁节点 node_id - error_message [state=state_code]`	这是关于集群中仲裁当前状态和进度的报告。 `node_id` 是选为仲裁者的管理节点或 SQL 节点的节点 ID。 `state_code` 是仲裁状态代码，如 `include/kernel/signaldata/ArbitSignalData.hpp` 中所示。当发生错误时，会提供一个 `error_message`，同样在 `ArbitSignalData.hpp` 中定义。 `ticket_id` 是仲裁者在被选为参与其选择的节点时发放的唯一标识符；这用于确保每个请求仲裁的节点都是参与选择过程的节点之一。	`ArbitState`	`NodeRestart`	6	`信息`
`仲裁检查失败 - 剩余节点少于一半` 或 `仲裁检查成功 - 所有节点组和剩余节点超过一半` 或 `仲裁检查成功 - 节点组多数` 或 `仲裁检查失败 - 缺少节点组` 或 `网络分区 - 需要仲裁` 或 `仲裁成功 - 来自节点 node_id 的肯定回复` 或 `仲裁失败 - 来自节点 node_id 的否定回复` 或 `网络分区 - 无可用仲裁者` 或 `网络分区 - 未配置仲裁者` 或 `仲裁失败 - error_message [state=state_code]`	此消息报告仲裁结果。如果仲裁失败，会提供一个 `error_message` 和一个仲裁 `state_code`；这两个的定义都可以在 `include/kernel/signaldata/ArbitSignalData.hpp` 中找到。	`ArbitResult`	`NodeRestart`	2	`警报`
`节点 node_id: GCP 接管已开始`	此节点正在尝试承担下一个全局检查点的责任（即，它将成为主节点）	`GCP_TakeoverStarted`	`NodeRestart`	7	`信息`
`节点 node_id: GCP 接管已完成`	此节点已成为主节点，并承担了下一个全局检查点的责任	`GCP_TakeoverCompleted`	`NodeRestart`	7	`信息`
`节点 node_id: LCP 接管已开始`	此节点正在尝试承担下一组本地检查点的责任（即，它将成为主节点）	`LCP_TakeoverStarted`	`NodeRestart`	7	`信息`
`节点 node_id: LCP 接管已完成`	此节点已成为主节点，并承担了下一组本地检查点的责任	`LCP_TakeoverCompleted`	`NodeRestart`	7	`信息`
`节点 node_id: 事务计数 = transactions，提交计数 = commits，读取计数 = reads，简单读取计数 = simple_reads，写入计数 = writes，AttrInfo 计数 = AttrInfo_objects，并发操作 = concurrent_operations，中止计数 = aborts，扫描 = scans，范围扫描 = range_scans`	此事务活动报告大约每 10 秒提供一次	`TransReportCounters`	`统计`	8	`信息`
`节点 node_id: 操作=operations`	此节点执行的操作数量，大约每 10 秒提供一次	`OperationReportCounters`	`统计`	8	`信息`
`节点 node_id: ID 为 table_id 的表已创建`	已创建具有显示的表 ID 的表	`TableCreated`	`统计`	7	`信息`
`节点 node_id: doJob 中最后 8192 次的平均循环计数 = count`		`JobStatistic`	`统计`	9	`信息`
`发送到节点 = node_id 的平均发送大小，最后 4096 次发送 = bytes 字节`	此节点平均每次向节点 `node_id` 发送 `bytes` 字节	`SendBytesStatistic`	`统计`	9	`信息`
`接收来自节点 = node_id 的平均接收大小，最后 4096 次发送 = bytes 字节`	此节点每次从节点 `node_id` 接收数据时，平均接收 `bytes` 字节的数据	`ReceiveBytesStatistic`	`统计`	9	`信息`
`节点 node_id: 数据使用率为 data_memory_percentage% (data_pages_used 个 32K 页面，共 data_pages_total 个)` / `节点 node_id: 索引使用率为 index_memory_percentage% (index_pages_used 个 8K 页面，共 index_pages_total 个)`	此报告是在集群管理客户端中发出 `DUMP 1000` 命令时生成的	`MemoryUsage`	`统计`	5	`信息`
`节点 node1_id: 传输器到节点 node2_id 报告错误 error_code: error_message`	与节点 `node2_id` 通信时发生了传输器错误；有关传输器错误代码和消息的列表，请参见 NDB 传输器错误，位于 MySQL NDB Cluster 内部手册中	`TransporterError`	`错误`	2	`ERROR`
`节点 node1_id: 传输器到节点 node2_id 报告错误 error_code: error_message`	与节点 `node2_id` 通信时存在潜在传输器问题的警告；有关传输器错误代码和消息的列表，请参见 NDB 传输器错误，以获取更多信息	`TransporterWarning`	`错误`	8	`WARNING`
`节点 node1_id: 节点 node2_id 丢失心跳 heartbeat_id`	此节点丢失了来自节点 `node2_id` 的心跳	`MissedHeartbeat`	`错误`	8	`WARNING`
`节点 node1_id: 由于丢失心跳，节点 node2_id 被宣布死亡`	此节点已丢失来自节点 `node2_id` 的至少 3 个心跳，因此已宣布该节点 “死亡”	`DeadDueToHeartbeat`	`错误`	8	`警报`
`节点 node1_id: 节点已向节点 = node2_id 发送心跳`	此节点已向节点 `node2_id` 发送心跳	`SentHeartbeat`	`信息`	12	`信息`
`节点 node_id: 事件缓冲区状态 (object_id): used=bytes_used (percent_used% of alloc) alloc=bytes_allocated max=bytes_available latest_consumed_epoch=latest_consumed_epoch latest_buffered_epoch=latest_buffered_epoch report_reason=report_reason`	此报告在事件缓冲区使用量很大的情况下出现，例如，在相对较短的时间内应用了许多更新时；报告显示了事件缓冲区内存的使用字节数和百分比、已分配的字节数和剩余的百分比，以及最新的已缓冲和已消费纪元；有关更多信息，请参见第 25.6.2.3 节，“集群日志中的事件缓冲区报告”	`EventBufferStatus2`	`信息`	7	`信息`
`节点 node_id: 进入单用户模式`，`节点 node_id: 已进入单用户模式，节点 API_node_id 拥有独占访问权限`，`节点 node_id: 进入单用户模式`	这些报告在进入和退出单用户模式时写入集群日志；`API_node_id` 是拥有对集群的独占访问权限的 API 或 SQL 的节点 ID（有关更多信息，请参见第 25.6.6 节，“NDB Cluster 单用户模式”）；消息 `Unknown single user report API_node_id` 表示发生了错误，并且在正常操作中不应该出现	`SingleUser`	`信息`	7	`信息`
`节点 node_id: 从节点 mgm_node_id 启动备份 backup_id`	使用具有 `mgm_node_id` 的管理节点已启动备份；当发出 `START BACKUP` 命令时，此消息也会显示在集群管理客户端中；有关更多信息，请参见第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”	`BackupStarted`	`备份`	7	`信息`
`节点 node_id：从节点 mgm_node_id 启动的备份 backup_id 已完成。StartGCP：start_gcp StopGCP：stop_gcp 记录数：records 日志记录数：log_records 数据：data_bytes 字节日志：log_bytes 字节`	ID 为 `backup_id` 的备份已完成；有关更多信息，请参见第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”	`BackupCompleted`	`备份`	7	`信息`
`节点 node_id：来自 mgm_node_id 的备份请求无法启动。错误：error_code`	备份无法启动；有关错误代码，请参见 MGM API 错误	`BackupFailedToStart`	`备份`	7	`警报`
`节点 node_id：从 mgm_node_id 启动的备份 backup_id 已中止。错误：error_code`	备份在启动后可能由于用户干预而终止	`BackupAborted`	`备份`	7	`警报`