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

版本 9.0

8.4 当前
8.0
5.7

8.0 日语

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

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

下表列出了最常见的 NDB 集群日志消息。有关集群日志、日志事件和事件类型的详细信息，请参阅第 25.6.3 节“NDB 集群中生成的事件报告”。这些日志消息也对应于 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` 是负责此全局检查点的主节点。	`全局检查点已启动`	`检查点`	9	`信息`
`节点 node_id：全局检查点 gci 已完成`	ID 为 `gci` 的全局检查点已完成；节点 `node_id` 是负责此全局检查点的主节点。	`全局检查点已完成`	`检查点`	10	`信息`
`节点 node_id：本地检查点 lcp 已启动。保留 GCI = current_gci 最旧的可恢复 GCI = old_gci`	序列 ID 为 `lcp` 的本地检查点已在节点 `node_id` 上启动。可使用的最新 GCI 的索引为 `current_gci`，可从中恢复集群的最旧 GCI 的索引为 `old_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` 正在开始其启动过程。	`NDB 启动已启动`	`启动`	1	`信息`
`节点 node_id：已启动 version`	运行 `NDB` 版本 `version` 的数据节点 `node_id` 已成功启动。	`NDB 启动已完成`	`启动`	1	`信息`
`节点 node_id：重启完成后收到 STTORRY`	节点已收到指示集群重启已完成的信号。	`已收到 STTORRY`	`启动`	15	`信息`
`节点 node_id：启动阶段 phase 已完成（type）`	节点已完成 `type` 启动的启动阶段 `phase`。有关启动阶段的列表，请参阅第 25.6.4 节“NDB 集群启动阶段摘要”。（`type` 是 `initial`、`system`、`node`、`initial node` 或 `<Unknown>` 之一。）	`启动阶段已完成`	`启动`	4	`信息`
`节点 node_id：CM_REGCONF president = president_id，own Node = own_id，our dynamic id = dynamic_id`	节点 `president_id` 已被选为 “president”。`own_id` 和 `dynamic_id` 应始终与报告节点的 ID（`node_id`）相同。	`CM_REGCONF`	`启动`	3	`信息`
`节点 node_id：从节点 president_id 到我们节点 node_id 的 CM_REGREF。原因 = cause`	报告节点（ID 为 `node_id`）无法接受节点 `president_id` 作为 president。问题的 `cause` 给出为以下之一：`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`。	`NDB 停止已启动`	`启动`	1	`信息`
`节点 node_id：节点关闭已完成` [`, action`] [`由信号 signal 启动。`]	节点已关闭。此报告可能包含 `action`，如果存在，则为 `restarting`、`no start` 或 `initial` 之一。该报告还可能包含对 `NDB` 协议 `signal` 的引用；有关可能的信号，请参阅操作和信号。	`NDB 停止已完成`	`启动`	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 集群 API 错误。	`NDB 停止已强制执行`	`启动`	1	`警报`
`节点 node_id：节点关闭已中止`	节点关闭过程已被用户中止。	`NDB 停止已中止`	`启动`	1	`信息`
`节点 node_id：StartLog: [GCI Keep: keep_pos LastCompleted: last_pos NewestRestorable: restore_pos]`	这将报告节点启动期间引用的全局检查点。在 `keep_pos` 之前的重做日志将被删除。`last_pos` 是数据节点参与的最后一个全局检查点；`restore_pos` 是实际用于恢复所有数据节点的全局检查点。	`StartREDOLog`	`启动`	4	`信息`
`startup_message` [单独列出；请参阅下文。]	在不同情况下可以记录许多可能的启动消息。这些消息单独列出；请参阅第 25.6.2.2 节“NDB 集群日志启动消息”。	`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	`信息`
`节点 node_id：节点 node1_id 已完成节点 node2_id 的故障转移`	数据节点 `node1_id` 已检测到数据节点 `node2_id` 的故障。	`NodeFailCompleted`	`NodeRestart`	8	`警报`
`所有节点都已完成节点 node_id 的故障转移`	所有（剩余的）数据节点都已检测到数据节点 `node_id` 的故障。	`NodeFailCompleted`	`NodeRestart`	8	`警报`
`node_idblock 的节点故障已完成`	已在 `block``NDB` 内核块中检测到数据节点 `node_id` 的故障，其中块是 `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_code]` 或 `准备仲裁器节点 node_id [票据=ticket_id]` 或 `接收仲裁器节点 node_id [票据=ticket_id]` 或 `启动仲裁器节点 node_id [票据=ticket_id]` 或 `丢失仲裁器节点 node_id - 进程故障 [状态=state_code]` 或 `丢失仲裁器节点 node_id - 进程退出 [状态=state_code]` 或 `丢失仲裁器节点 node_id - error_message [状态=state_code]`	这是关于集群中仲裁的当前状态和进度的报告。 `node_id` 是选择作为仲裁器的管理节点或 SQL 节点的节点 ID。 `state_code` 是仲裁状态代码，如 `include/kernel/signaldata/ArbitSignalData.hpp` 中所示。发生错误时，将提供 `error_message`，该消息也在 `ArbitSignalData.hpp` 中定义。 `ticket_id` 是仲裁器在被选中后，向所有参与其选择的节点发放的唯一标识符；这用于确保每个请求仲裁的节点都是参与选择过程的节点之一。	`ArbitState`	`NodeRestart`	6	`信息`
`仲裁检查失败 - 剩余节点数少于 1/2` 或 `仲裁检查成功 - 所有节点组和超过 1/2 的节点剩余` 或 `仲裁检查成功 - 节点组多数` 或 `仲裁检查失败 - 缺少节点组` 或 `网络分区 - 需要仲裁` 或 `仲裁成功 - 来自节点 node_id 的肯定回复` 或 `仲裁失败 - 来自节点 node_id 的否定回复` 或 `网络分区 - 没有可用的仲裁器` 或 `网络分区 - 未配置仲裁器` 或 `仲裁失败 - error_message [状态=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：最近 8192 次 doJob 中的平均循环计数器 = count`		`JobStatistic`	`统计`	9	`信息`
`最近 4096 次发送到节点 = node_id 的平均发送大小 = bytes 字节`	此节点每次发送到节点 `node_id` 的平均数据量为 `bytes` 字节	`SendBytesStatistic`	`统计`	9	`信息`
`最近 4096 次从节点 = node_id 接收的平均大小 = bytes 字节`	此节点每次从节点 `node_id` 接收数据时，平均接收的数据量为 `bytes`	`ReceiveBytesStatistic`	`统计`	9	`信息`
`节点 node_id：数据使用量为 data_memory_percentage%（总共 data_pages_total 个 32K 页面中使用了 data_pages_used 个）` / `节点 node_id：索引使用量为 index_memory_percentage%（总共 index_pages_total 个 8K 页面中使用了 index_pages_used 个）`	当在集群管理客户端中发出 `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）：已用=bytes_used（已分配的 percent_used%）已分配=bytes_allocated 最大=bytes_available latest_consumed_epoch=latest_consumed_epoch latest_buffered_epoch=latest_buffered_epoch 报告原因=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 单用户模式”）；消息 `未知的单用户报告 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	`警报`