MySQL :: MySQL 8.3 Reference Manual :: 25.6.2.1 NDB Cluster: Messages in the Cluster Log

version 8.3

8.0 current
5.7

8.0 Japanese

MySQL 8.3 Reference Manual / ... / NDB Cluster: Messages in the Cluster Log

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

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

表 25.53 常见 NDB 集群日志消息

Log Message	Description	Event Name	Event Type	Priority	Severity
`Node mgm_node_id: Node data_node_id Connected`	节点 ID 为 `node_id` 的数据节点已经连接到管理服务器（节点 `mgm_node_id`）。	`Connected`	`Connection`	8	`INFO`
`Node mgm_node_id: Node data_node_id Disconnected`	节点 ID 为 `data_node_id` 的数据节点已经从管理服务器（节点 `mgm_node_id`）断开连接。	`Disconnected`	`Connection`	8	`ALERT`
`Node data_node_id: Communication to Node api_node_id closed`	节点 ID 为 `api_node_id` 的 API 节点或 SQL 节点不再与数据节点 `data_node_id` 通信。	`CommunicationClosed`	`Connection`	8	`INFO`
`Node data_node_id: Communication to Node api_node_id opened`	节点 ID 为 `api_node_id` 的 API 节点或 SQL 节点现在正在与数据节点 `data_node_id` 通信。	`CommunicationOpened`	`Connection`	8	`INFO`
`Node mgm_node_id: Node api_node_id: API version`	节点 ID 为 `api_node_id` 的 API 节点已经连接到管理节点 `mgm_node_id`，使用 `NDB` API 版本 `version`（通常与 MySQL 版本号相同）。	`ConnectedApiVersion`	`Connection`	8	`INFO`
`Node node_id: Global checkpoint gci started`	全局检查点 ID 为 `gci` 的全局检查点已经启动；节点 `node_id` 是负责该全局检查点的主节点。	`GlobalCheckpointStarted`	`Checkpoint`	9	`INFO`
`Node node_id: Global checkpoint gci completed`	全局检查点 ID 为 `gci` 的全局检查点已经完成；节点 `node_id` 是负责该全局检查点的主节点。	`GlobalCheckpointCompleted`	`Checkpoint`	10	`INFO`
`Node node_id: Local checkpoint lcp started. Keep GCI = current_gci oldest restorable GCI = old_gci`	节点 `node_id` 上的本地检查点序列 ID 为 `lcp` 的本地检查点已经启动。最新的 GCI 可以用于恢复的索引为 `current_gci`，而最旧的 GCI 可以从中恢复的索引为 `old_gci`。	`LocalCheckpointStarted`	`Checkpoint`	7	`INFO`
`Node node_id: Local checkpoint lcp completed`	节点 `node_id` 上的本地检查点序列 ID 为 `lcp` 的本地检查点已经完成。	`LocalCheckpointCompleted`	`Checkpoint`	8	`INFO`
`Node node_id: Local Checkpoint stopped in CALCULATED_KEEP_GCI`	节点无法确定最新的可用 GCI。	`LCPStoppedInCalcKeepGci`	`Checkpoint`	0	`ALERT`
`Node node_id: Table ID = table_id, fragment ID = fragment_id has completed LCP on Node node_id maxGciStarted: started_gci maxGciCompleted: completed_gci`	节点 `node_id` 上的表碎片已经被 checkpoint 到磁盘。正在进行的 GCI 的索引为 `started_gci`，而最新完成的 GCI 的索引为 `completed_gci`。	`LCPFragmentCompleted`	`检查点`	11	`INFO`
`Node node_id: ACC Blocked num_1 and TUP Blocked num_2 times last second`	Undo 日志记录被阻止，因为日志缓冲区即将溢出。	`UndoLogBlocked`	`Checkpoint`	7	`INFO`
`Node node_id: Start initiated version`	数据节点 `node_id`，运行 `NDB` 版本 `version`，正在启动过程中。	`NDBStartStarted`	`StartUp`	1	`INFO`
`Node node_id: Started version`	数据节点 `node_id`，运行 `NDB` 版本 `version`，已经成功启动。	`NDBStartCompleted`	`StartUp`	1	`INFO`
`Node node_id: STTORRY received after restart finished`	节点已经收到集群重启完成的信号。	`STTORRYRecieved`	`StartUp`	15	`INFO`
`Node node_id: Start phase phase completed (type)`	节点已经完成启动阶段 `phase` 的 `type` 启动。有关启动阶段的列表，请参阅第 25.6.4 节，「NDB 集群启动阶段概述」。（`type` 是 `initial`、`system`、`node`、`initial node` 或 `<Unknown>` 之一。）	`StartPhaseCompleted`	`StartUp`	4	`INFO`
`Node node_id: CM_REGCONF president = president_id, own Node = own_id, our dynamic id = dynamic_id`	节点 `president_id` 已经被选为「总统」。 `own_id` 和 `dynamic_id` 应该总是与报告节点的 ID (`node_id`) 相同。	`CM_REGCONF`	`StartUp`	3	`INFO`
`Node node_id: CM_REGREF from Node president_id to our Node node_id. Cause = cause`	报告节点（ID `node_id`）无法接受节点 `president_id` 作为总统。问题的原因是 `cause`，可能是 `Busy`、`Election with wait = false`、`Not president`、`Election without selecting new candidate` 或 `No such cause`。	`CM_REGREF`	`StartUp`	8	`INFO`
`Node node_id: We are Node own_id with dynamic ID dynamic_id, our left neighbor is Node id_1, our right is Node id_2`	节点已经发现集群中的邻居节点（节点 `id_1` 和节点 `id_2`）。 `node_id`、`own_id` 和 `dynamic_id` 应该总是相同的；如果它们不同，这表明集群节点的严重misconfiguration。	`FIND_NEIGHBOURS`	`StartUp`	8	`INFO`
`Node node_id: type shutdown initiated`	节点已经收到关闭信号。关闭类型是 `Cluster` 或 `Node`。	`NDBStopStarted`	`StartUp`	1	`INFO`
`Node node_id: Node shutdown completed` [`, action`] [`Initiated by signal signal.`]	节点已经关闭。该报告可能包括一个 `action`，如果存在，则是 `restarting`、`no start` 或 `initial`。该报告可能还包括对 `NDB` 协议 `signal` 的引用；有关可能的信号，请参阅 Operations and Signals。	`NDBStopCompleted`	`StartUp`	1	`INFO`
`Node node_id: Forced node shutdown completed` [`, action`]`.` [`Occurred during startphase start_phase.`] [ `Initiated by signal.`] [`Caused by error error_code: 'error_message(error_classification). error_status'.` [`(extra info extra_code)`]]	节点已经被强制关闭。随后采取的操作（如果有的话）也将被报告。如果节点是在启动过程中关闭的，那么报告将包括失败的阶段。如果这是由于发送给节点的信号所致，这些信息也将被提供（参见Operations and Signals，以获取更多信息）。如果错误导致的失败是已知的，也将被包括；有关`NDB`错误消息和分类的更多信息，请参见NDB Cluster API Errors。	`NDBStopForced`	`StartUp`	1	`ALERT`
`Node node_id: Node shutdown aborted`	节点关闭过程被用户中止。	`NDBStopAborted`	`StartUp`	1	`INFO`
`Node node_id: StartLog: [GCI Keep: keep_pos LastCompleted: last_pos NewestRestorable: restore_pos]`	这报告了在节点启动期间引用的全局检查点。redo 日志在 `keep_pos` 之前的部分将被删除。`last_pos` 是数据节点参与的最后一个全局检查点;`restore_pos` 是用于恢复所有数据节点的全局检查点。	`StartREDOLog`	`StartUp`	4	`INFO`
`startup_message` [Listed separately; see below.]	在不同的情况下可能会记录多种启动消息。这些消息将单独列出；参见第 25.6.2.2 节，“NDB 集群日志启动消息”。	`StartReport`	`StartUp`	4	`INFO`
`Node node_id: Node restart completed copy of dictionary information`	已经完成了对重新启动节点的数据字典信息的复制。	`NR_CopyDict`	`NodeRestart`	8	`INFO`
`Node node_id: Node restart completed copy of distribution information`	已经完成了对重新启动节点的数据分布信息的复制。	`NR_CopyDistr`	`NodeRestart`	8	`INFO`
`Node node_id: Node restart starting to copy the fragments to Node node_id`	已经开始将碎片复制到启动数据节点 `node_id`。	`NR_CopyFragsStarted`	`NodeRestart`	8	`INFO`
`Node node_id: Table ID = table_id, fragment ID = fragment_id have been copied to Node node_id`	已经将碎片 `fragment_id` 从表 `table_id` 复制到数据节点 `node_id`。	`NR_CopyFragDone`	`NodeRestart`	10	`INFO`
`Node node_id: Node restart completed copying the fragments to Node node_id`	已经完成了对重新启动数据节点 `node_id` 的所有表碎片的复制。	`NR_CopyFragsCompleted`	`NodeRestart`	8	`INFO`
`Node node_id: Node node1_id completed failure of Node node2_id`	数据节点 `node1_id` 已经检测到数据节点 `node2_id` 的失败。	`NodeFailCompleted`	`NodeRestart`	8	`ALERT`
`All nodes completed failure of Node node_id`	所有（剩余的）数据节点已经检测到数据节点 `node_id` 的失败。	`NodeFailCompleted`	`NodeRestart`	8	`ALERT`
`Node failure of node_idblock completed`	数据节点 `node_id` 的失败已经在 `block``NDB` 内核块中检测到，块可以是 `DBTC`、`DBDICT`、`DBDIH` 或 `DBLQH`；有关更多信息，请参阅 NDB 内核块	`NodeFailCompleted`	`NodeRestart`	8	`ALERT`
`Node mgm_node_id: Node data_node_id has failed. The Node state at failure was state_code`	数据节点已经失败。其失败时的状态由仲裁状态代码 `state_code` 描述：可能的状态代码值可以在文件 `include/kernel/signaldata/ArbitSignalData.hpp` 中找到。	`NODE_FAILREP`	`NodeRestart`	8	`ALERT`
`President restarts arbitration thread [state=state_code]` or `Prepare arbitrator node node_id [ticket=ticket_id]` or `Receive arbitrator node node_id [ticket=ticket_id]` or `Started arbitrator node node_id [ticket=ticket_id]` or `Lost arbitrator node node_id - process failure [state=state_code]` or `Lost arbitrator node node_id - process exit [state=state_code]` or `Lost arbitrator node 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	`INFO`
`Arbitration check lost - less than 1/2 nodes left` or `Arbitration check won - all node groups and more than 1/2 nodes left` or `Arbitration check won - node group majority` or `Arbitration check lost - missing node group` or `Network partitioning - arbitration required` or `Arbitration won - positive reply from node node_id` or `Arbitration lost - negative reply from node node_id` or `Network partitioning - no arbitrator available` or `Network partitioning - no arbitrator configured` or `Arbitration failure - error_message [state=state_code]`	这是仲裁结果的报告。在仲裁失败的情况下，将提供一个 `error_message` 和仲裁状态代码 `state_code`，定义在 `include/kernel/signaldata/ArbitSignalData.hpp` 中。	`ArbitResult`	`NodeRestart`	2	`ALERT`
`Node node_id: GCP Take over started`	该节点正在尝试接管下一个全局检查点（即，它正在成为主节点）	`GCP_TakeoverStarted`	`NodeRestart`	7	`INFO`
`Node node_id: GCP Take over completed`	该节点已经成为主节点，并且已经接管了下一个全局检查点	`GCP_TakeoverCompleted`	`NodeRestart`	7	`INFO`
`Node node_id: LCP Take over started`	该节点正在尝试接管下一个本地检查点集（即，它正在成为主节点）	`LCP_TakeoverStarted`	`NodeRestart`	7	`INFO`
`Node node_id: LCP Take over completed`	该节点已经成为主节点，并且已经接管了下一个本地检查点集	`LCP_TakeoverCompleted`	`NodeRestart`	7	`INFO`
`Node node_id: Trans. Count = transactions, Commit Count = commits, Read Count = reads, Simple Read Count = simple_reads, Write Count = writes, AttrInfo Count = AttrInfo_objects, Concurrent Operations = concurrent_operations, Abort Count = aborts, Scans = scans, Range scans = range_scans`	大约每 10 秒报告一次事务活动	`TransReportCounters`	`Statistic`	8	`INFO`
`Node node_id: Operations=operations`	大约每 10 秒报告一次该节点执行的操作数量	`OperationReportCounters`	`Statistic`	8	`INFO`
`Node node_id: Table with ID = table_id created`	已经创建了一个表，表 ID 如下所示	`TableCreated`	`Statistic`	7	`INFO`
`Node node_id: Mean loop Counter in doJob last 8192 times = count`		`JobStatistic`	`Statistic`	9	`INFO`
`Mean send size to Node = node_id last 4096 sends = bytes bytes`	该节点平均每次发送 `字节` 字节到节点 `node_id`	`SendBytesStatistic`	`Statistic`	9	`INFO`
`Mean receive size to Node = node_id last 4096 sends = bytes bytes`	该节点平均每次从节点 `node_id` 接收 `字节` 数据	`ReceiveBytesStatistic`	`Statistic`	9	`INFO`
`Node node_id: Data usage is data_memory_percentage% (data_pages_used 32K pages of total data_pages_total)` / `Node node_id: Index usage is index_memory_percentage% (index_pages_used 8K pages of total index_pages_total)`	当在集群管理客户端中发出 `DUMP 1000` 命令时生成此报告	`MemoryUsage`	`Statistic`	5	`INFO`
`Node node1_id: Transporter to node node2_id reported error error_code: error_message`	在与节点 `node2_id` 通信时发生传输器错误；有关传输器错误代码和消息的列表，请参阅 NDB 传输器错误，在 MySQL NDB 集群内部手册中	`TransporterError`	`Error`	2	`ERROR`
`Node node1_id: Transporter to node node2_id reported error error_code: error_message`	在与节点 `node2_id` 通信时可能出现传输器问题的警告；有关传输器错误代码和消息的列表，请参阅 NDB 传输器错误，以获取更多信息	`TransporterWarning`	`Error`	8	`WARNING`
`Node node1_id: Node node2_id missed heartbeat heartbeat_id`	该节点从节点 `node2_id` 缺少心跳	`MissedHeartbeat`	`Error`	8	`WARNING`
`Node node1_id: Node node2_id declared dead due to missed heartbeat`	该节点至少从节点 `node2_id` 缺少 3 次心跳，因此宣布该节点为“死亡”	`DeadDueToHeartbeat`	`Error`	8	`ALERT`
`Node node1_id: Node Sent Heartbeat to node = node2_id`	该节点向节点 `node2_id` 发送心跳	`SentHeartbeat`	`Info`	12	`INFO`
`Node node_id: Event buffer status (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`	在事件缓冲区使用率很高时，例如，在短时间内应用了许多更新时，会看到该报告；该报告显示事件缓冲区内存的使用情况、分配的字节数和可用百分比、最新的缓冲和消费 epoch；有关更多信息，请参阅第 25.6.2.3 节，“事件缓冲区报告在集群日志中”	`EventBufferStatus2`	`Info`	7	`INFO`
`Node node_id: Entering single user mode`, `Node node_id: Entered single user mode Node API_node_id has exclusive access`, `Node node_id: Entering single user mode`	这些报告是在单用户模式下写入集群日志的；`API_node_id` 是拥有独占集群访问权的 API 或 SQL 的节点 ID（有关更多信息，请参阅第 25.6.6 节，“NDB 集群单用户模式”）；消息 `Unknown single user report API_node_id` 表示错误已经发生，正常情况下不应该看到	`SingleUser`	`Info`	7	`INFO`
`Node node_id: Backup backup_id started from node mgm_node_id`	使用管理节点 `mgm_node_id` 启动了备份；该消息也将在集群管理客户端中显示，当 `START BACKUP` 命令被发出时；有关更多信息，请参阅第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”	`BackupStarted`	`Backup`	7	`INFO`
`Node node_id: Backup backup_id started from node mgm_node_id completed. StartGCP: start_gcp StopGCP: stop_gcp #Records: records #LogRecords: log_records Data: data_bytes bytes Log: log_bytes bytes`	备份拥有 ID `backup_id` 已经完成；有关更多信息，请参阅第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”	`备份完成`	`备份`	7	`信息`
`Node node_id: Backup request from mgm_node_id failed to start. Error: error_code`	备份无法启动；有关错误代码，请参阅 MGM API 错误	`备份无法启动`	`备份`	7	`警报`
`Node node_id: Backup backup_id started from mgm_node_id has been aborted. Error: error_code`	备份在启动后被终止，可能是由于用户干预	`备份中止`	`备份`	7	`警报`

PREV HOME UP NEXT