NDB群集日志消息

本节包含有关响应不同群集日志事件而写入群集日志的消息的信息。它提供有关NDB运输商错误的其他更具体的信息。

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

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

常见NDB群集日志消息

日志信息	描述	活动名称	事件类型	优先	严重程度
`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节点或SQL节点`api_node_id`不再与数据节点通信`data_node_id`。	CommunicationClosed	Connection	8	INFO
`Node data_node_id: Communication to Node api_node_id opened`	具有节点ID的API节点或SQL节点`api_node_id`现在正在与数据节点通信`data_node_id`。	CommunicationOpened	Connection	8	INFO
`Node mgm_node_id: Node api_node_id: API version`	具有节点ID的API节点`api_node_id`已`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`	具有序列ID的本地检查点`lcp`已在节点上启动`node_id`。可以使用的最新GCI具有索引`current_gci`，可以从中还原群集的最旧GCI具有索引`old_gci`。	LocalCheckpointStarted	Checkpoint	7	INFO
`Node node_id: Local checkpoint lcp completed`	`lcp`节点`node_id`上具有序列ID的本地检查点已完成。	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上的磁盘`node_id`。进行中的GCI具有该索引`started_gci`，最近完成的GCI具有该索引`completed_gci`。	LCPFragmentCompleted	Checkpoint	11	INFO
`Node node_id: ACC Blocked num_1 and TUP Blocked num_2 times last second`	撤消日志记录被阻止，因为日志缓冲区即将溢出。	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`开始。有关启动阶段的列表，请参见“ 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`	Node `president_id`已被选为“总裁”。`own_id`并且`dynamic_id`应始终`node_id`与报告节点的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`	该节点已发现其在群集中的相邻节点（node `id_1`和node `id_2`）。`node_id`，`own_id`和`dynamic_id`应该始终相同；如果不是，则表明集群节点严重配置错误。	FIND_NEIGHBOURS	StartUp	8	INFO
`Node node_id:type shutdown initiated`	该节点已收到关闭信号。的`type`关闭的或者是`Cluster`或`Node`。	NDBStopStarted	StartUp	1个	INFO
`Node node_id: Node shutdown completed` [][]`,actionInitiated by signal signal.`	该节点已关闭。该报告可以包括`action`，其如果存在的话是一个`restarting`，`no start`或`initial`。该报告还可能包括对`NDB`议定书的提及`signal`;有关可能的信号，请参阅《操作和信号》。	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)`	该节点已被强制关闭。的`action`（之一`restarting`，`no start`或`initial`）随后被采取，如果有的话，也有报道。如果关闭是在节点启动时发生的，则报告将包括`start_phase`节点发生故障的时间。如果这是`signal`发送到节点的结果，则还将提供此信息（有关更多信息，请参阅“操作和信号”）。如果已知导致故障的错误，则也包括在内；有关`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]`	这将报告在节点启动期间引用的全局检查点。之前的重做日志`keep_pos`已删除。`last_pos`是数据节点参与的最后一个全局检查点；`restore_pos`是实际用于还原所有数据节点的全局检查点。	StartREDOLog	StartUp	4	INFO
`startup_message`[单独列出；见下文。]	在不同情况下可以记录许多可能的启动消息。这些分别列出；请参见“ 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`已在被检测的内核块，其中块是1 ，，，或; 有关更多信息，请参见 NDB内核块。`block``NDBDBTCDBDICTDBDIHDBLQH`	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]`或或或或或或`Prepare arbitrator node node_id[ticket=ticket_id]Receive arbitrator node node_id[ticket=ticket_id]Started arbitrator node node_id[ticket=ticket_id]Lost arbitrator node node_id- process failure[state=state_code]Lost arbitrator node node_id- process exit[state=state_code]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`或`Arbitration check won - all node groups and more than 1/2 nodes left`或`Arbitration check won - node group majority`或`Arbitration check lost - missing node group`或`Network partitioning - arbitration required`或或或或或`Arbitration won - positive reply from node node_idArbitration lost - negative reply from node node_idNetwork partitioning - no arbitrator availableNetwork partitioning - no arbitrator configuredArbitration 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`	该节点正在向`bytes`每个节点发送平均字节数`node_id`	SendBytesStatistic	Statistic	9	INFO
`Mean receive size to Node =node_id last 4096 sends =bytes 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`	该节点至少错过了3个心跳信号`node2_id`，因此已宣布该节点为“死机”	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`	例如，当在相对较短的时间段内应用许多更新时，可以在使用重事件缓冲区时看到此报告。该报告显示字节数和已使用的事件缓冲存储器的百分比，分配的字节和仍可用的百分比，以及最新的缓冲和消耗的时期；有关更多信息，请	EventBufferStatus2	Info	7	INFO
`Node node_id: Entering single user mode`，，`Node node_id: Entered single user mode Node API_node_id has exclusive accessNode node_id: Entering single user mode`	进入和退出单用户模式时，这些报告将被写入集群日志。`API_node_id`是具有对集群的独占访问权的API或SQL的节点ID（有关更多信息，请参见“ 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`发出命令时，该消息也会显示在集群管理客户端中；有关更多信息，请参见“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`已完成；有关更多信息，请参见“NDB集群在线备份”	BackupCompleted	Backup	7	INFO
`Node node_id: Backup request from mgm_node_id failed to start. Error:error_code`	备份无法启动；有关错误代码，请参见 MGM API错误	BackupFailedToStart	Backup	7	ALERT
`Node node_id: Backup backup_id started from mgm_node_id has been aborted. Error:error_code`	开始后，备份可能已终止，可能是由于用户的干预	BackupAborted	Backup	7	ALERT

NDB群集日志启动消息

以下列表中提供了可能的带有说明的启动消息：

Initial start, waiting for %s to connect, nodes[ all:%s connected:%s no-wait:%s ]
Waiting until nodes:%s connects, nodes[ all:%s connected:%s no-wait:%s ]
Waiting %u sec for nodes %s to connect, nodes[ all:%s connected:%s no-wait:%s ]
Waiting for non partitioned start, nodes[ all:%s connected:%s missing:%s no-wait:%s ]
Waiting %u sec for non partitioned start, nodes[ all:%s connected:%s missing:%s no-wait:%s ]
Initial start with nodes %s[ missing:%s no-wait:%s ]
Start with all nodes %s
Start with nodes %s[ missing:%s no-wait:%s ]
Start potentially partitioned with nodes %s[ missing:%s no-wait:%s ]
Unknown startreport: 0x%x[%s %s %s %s ]

群集日志中的事件缓冲区报告

NDB使用一个或多个内存缓冲区处理从数据节点接收的事件。Ndb订阅表事件的每个对象都有一个这样的缓冲区，这意味着每个执行二进制日志记录的mysqld通常都有两个缓冲区（一个用于模式事件的缓冲区，一个用于数据事件的缓冲区）。每个缓冲区包含由事件组成的时期。这些事件包括操作类型（插入，更新，删除）和行数据（图像加元数据之前和之后）。

NDB在群集日志中生成消息以描述这些缓冲区的状态。尽管这些报告显示在群集日志中，但是它们引用API节点上的缓冲区（与大多数其他群集日志消息不同，这些消息是由数据节点生成的）。

群集日志中的事件缓冲区日志记录报告使用以下格式：

Node node_id: Event buffer status (object_id):
used=bytes_used (percent_used% of alloc)
alloc=bytes_allocated (percent_alloc% of max) max=bytes_available
latest_consumed_epoch=latest_consumed_epoch
latest_buffered_epoch=latest_buffered_epoch
report_reason=report_reason

此处列出了构成此报告的字段，并提供了描述：

node_id：报告来源的节点的ID。
object_id：Ndb报告来源的对象的ID 。
bytes_used：缓冲区使用的字节数。
percent_used：使用的已分配字节百分比。
bytes_allocated：分配给此缓冲区的字节数。
percent_alloc：使用的可用字节百分比；如果ndb_eventbuffer_max_alloc等于0（无限制），则不打印。
bytes_available：可用字节数；如果ndb_eventbuffer_max_alloc为0（无限制），则为0。
latest_consumed_epoch：最近完成的时代。（在NDB API应用程序中，这是通过调用来完成的nextEvent()。）
latest_buffered_epoch：最近（完全）缓冲在事件缓冲区中的时期。
report_reason：制作报告的原因。可能的原因在本节后面显示。

下表描述了可能的报告原因：

ENOUGH_FREE_EVENTBUFFER：事件缓冲区有足够的空间。
LOW_FREE_EVENTBUFFER：事件缓冲区的可用空间不足。
可以通过设置ndb_report_thresh_binlog_mem_usage服务器变量来调整触发这些报告的无阈值百分比级别。
BUFFERED_EPOCHS_OVER_THRESHOLD：缓冲的纪元数是否已超过配置的阈值。此数字是全部收到的最新纪元与最近消耗的纪元之间的差（在NDB API应用程序中，这是通过调用nextEvent()或来完成的nextEvent2()）。每秒生成一次报告，直到缓冲的纪元数低于阈值为止，可以通过设置ndb_report_thresh_binlog_epoch_slip服务器变量来调整该阈值。您还可以通过调用NDB API应用程序中的阈值setEventBufferQueueEmptyEpoch()。
PARTIALLY_DISCARDING：事件缓冲区内存已用完，ndb_eventbuffer_max_alloc即已使用了100％。即使使用率超过100％，任何部分缓冲的时期也会被缓冲到完成，但是接收到的任何新时期都会被丢弃。这意味着事件流中已出现间隙。
COMPLETELY_DISCARDING：没有时期被缓冲。
PARTIALLY_BUFFERING：差距之后的无缓冲百分比已提高到阈值，可以在mysql客户端中使用ndb_eventbuffer_free_percent服务器系统变量或在NDB API应用程序中通过调用来设置该阈值set_eventbuffer_free_percent()。新纪元被缓冲。由于间隔而无法完成的时期将被丢弃。
COMPLETELY_BUFFERING：所有收到的纪元都将被缓冲，这意味着有足够的事件缓冲存储器。事件流中的缝隙已消除。

NDB群集：NDB传输器错误

本节列出了在传输器错误的情况下写入集群日志的错误代码，名称和消息。

0x00

TE_NO_ERROR

没错

0x01

TE_ERROR_CLOSING_SOCKET

关闭套接字时发现错误

0x02

TE_ERROR_IN_SELECT_BEFORE_ACCEPT

接受前发现错误。运输商将重试

0x03

TE_INVALID_MESSAGE_LENGTH

在邮件中发现错误（无效的邮件长度）

0x04

TE_INVALID_CHECKSUM

在消息中发现错误（校验和）

0x05

TE_COULD_NOT_CREATE_SOCKET

创建套接字时发现错误（无法创建套接字）

0x06

TE_COULD_NOT_BIND_SOCKET

绑定服务器套接字时发现错误

0x07

TE_LISTEN_FAILED

侦听服务器套接字时发现错误

0x08

TE_ACCEPT_RETURN_ERROR

接受期间发现错误（接受返回错误）

0x0b

TE_SHM_DISCONNECT

远程节点已断开连接

0x0c

TE_SHM_IPC_STAT

无法检查shm段

0x0d

TE_SHM_UNABLE_TO_CREATE_SEGMENT

无法创建shm段

0x0e

TE_SHM_UNABLE_TO_ATTACH_SEGMENT

无法附加shm段

0x0f

TE_SHM_UNABLE_TO_REMOVE_SEGMENT

无法删除shm段

0x10

TE_TOO_SMALL_SIGID

签名ID太小

0x11

TE_TOO_LARGE_SIGID

签名ID太大

0x12

TE_WAIT_STACK_FULL

等待堆栈已满

0x13

TE_RECEIVE_BUFFER_FULL

接收缓冲区已满

0x14

TE_SIGNAL_LOST_SEND_BUFFER_FULL

发送缓冲区已满，尝试强制发送失败

0x15

TE_SIGNAL_LOST

发送失败，原因不明（信号丢失）

0x16

TE_SEND_BUFFER_FULL

发送缓冲区已满，但解决了一段时间

0x21

TE_SHM_IPC_PERMANENT

Shm ipc永久错误

注意

传输程序错误代码0x17至 0x20和0x22 保留用于SCI连接，此版本的NDB Cluster不支持这些错误，因此此处不包括。