集群节点日志

节点日志 ndb_node_id_out.log 是在每个 MySQL Cluster 数据节点上创建的，以显示特定于本地节点的信息。
node_id 标识日志来源的本地节点。
此节点日志可能会变得非常大，并且需要管理来轮换或者清除旧日志。

一个示例日志：

....
2011-03-23 17:24:17 [ndbd] INFO     -- Angel pid: 262 started child: 263
2011-03-23 17:24:17 [ndbd] INFO     -- Configuration fetched from 'ndb-mgmd-node1:1186', generation: 1
NDBMT: MaxNoOfExecutionThreads=8
NDBMT: workers=4 threads=4
2011-03-23 17:24:17 [ndbd] INFO     -- NDB Cluster -- DB node 3
2011-03-23 17:24:17 [ndbd] INFO     -- mysql-5.1.51 ndb-7.1.10 -
2011-03-23 17:24:17 [ndbd] INFO     -- WatchDog timer is set to 6000 ms
2011-03-23 17:24:17 [ndbd] INFO     -- numa_set_interleave_mask(numa_all_nodes) : no numa support
2011-03-23 17:24:17 [ndbd] INFO     -- Ndbd_mem_manager::init(1) min: 13951Mb initial: 14335Mb
Adding 380Mb to ZONE_LO (1,12159)
NDBMT: num_threads=7
thr: 0 tid: 5 DBTC(0) DBDIH(0) DBDICT(0) NDBCNTR(0) QMGR(0) NDBFS(0) TRIX(0) DBUTIL(0) 
thr: 1 tid: 6 BACKUP(0) DBLQH(0) DBACC(0) DBTUP(0) SUMA(0) DBTUX(0) TSMAN(0) LGMAN(0) PGMAN(0) RESTORE(0) DBINFO(0) PGMAN(5) 
thr: 2 tid: 7 PGMAN(1) DBACC(1) DBLQH(1) DBTUP(1) BACKUP(1) DBTUX(1) RESTORE(1) 
thr: 3 tid: 8 PGMAN(2) DBACC(2) DBLQH(2) DBTUP(2) BACKUP(2) DBTUX(2) RESTORE(2) 
thr: 4 tid: 9 PGMAN(3) DBACC(3) DBLQH(3) DBTUP(3) BACKUP(3) DBTUX(3) RESTORE(3) 
thr: 6 tid: 1 CMVMI(0) 
thr: 5 tid: 10 PGMAN(4) DBACC(4) DBLQH(4) DBTUP(4) BACKUP(4) DBTUX(4) RESTORE(4) 
saving 103ae0000 at 100581d20 (0)
2011-03-23 17:24:20 [ndbd] INFO     -- Start initiated (mysql-5.1.51 ndb-7.1.10)
NDBFS/AsyncFile: Allocating 310392 for In/Deflate buffer
2011-03-23 17:24:42 [ndbd] INFO     -- timerHandlingLab now: 5031230115 sent: 5031229933 diff: 182
2011-03-23 17:24:42 [ndbd] INFO     -- Watchdog: User time: 189  System time: 2412
2011-03-23 17:24:42 [ndbd] WARNING  -- Watchdog: Warning overslept 244 ms, expected 100 ms.
Adding 7812Mb to ZONE_LO (12160,249983)
Adding 6143Mb to ZONE_LO (262145,196575)
....

轮转数据节点的日志文件涉及复制当前文件并将原始文件归零。
如果我们根本不需要日志文件，我们可以简单地跳过复制文件并将其清空。

shell> cp ndb_3_out.log ndb_3_out.log.1
shell> cat /dev/null > ndb_3_out.log

节点日志的另一种形式是节点错误日志，名称为 ndb_node_id_error.log。
这是一种摘要日志格式，列出了 MySQL 集群中该节点上发生的主要错误。
这通常是确定集群中节点健康状况的快速信息来源。
日志中的详细信息包括时间戳、错误消息、代码块和关联的跟踪文件。
一个示例格式是：

....
Time: Wednesday 24 August 2011 - 15:28:49
Status: Temporary error, restart node
Message: Internal program error (failed ndbrequire) (Internal error, programming error or missing error message, please report a bug)
Error: 2341
Error data: dbdih/DbdihMain.cpp
Error object: DBDIH (Line: 9138) 0x00000002
Program: /opt/mysql/mysql/bin/ndbmtd
Pid: 21999 thr: 0
Version: mysql-5.1.56 ndb-7.1.15
Trace: /home/mysql/data/logs/ndb_3_trace.log.10 /home/mysql/data/logs/ndb_3_trace.log.10_t1 /home/mysql/data
....

管理日志

MySQL Cluster 的管理节点默认写入数据目录中标识为 ndb_node_id_cluster.log 的集群日志。
通常，此处的 node_id 值为 1 或者 2，但这可能会因我们选择的节点 ID 而异。
集群日志很有用，因为它在一个文件中提供了整个集群的信息，尽管这也使得阅读起来有点棘手。
以下是集群日志的示例输出：

....
2011-09-01 13:33:30 [MgmtSrvr] INFO     -- Node 4: Node 26: API mysql-5.1.51 ndb-7.1.9
2011-09-01 13:33:30 [MgmtSrvr] INFO     -- Node 4: Node 18: API mysql-5.1.51 ndb-7.1.9
2011-09-01 13:33:31 [MgmtSrvr] INFO     -- Node 3: Local checkpoint 98 started. Keep GCI = 258791 oldest restorable GCI = 258792
2011-09-01 13:33:32 [MgmtSrvr] INFO     -- Node 4: Start phase 101 completed (node restart)
2011-09-01 13:33:32 [MgmtSrvr] INFO     -- Node 3: DICT: unlocked by node 4 for NodeRestart
2011-09-01 13:40:53 [MgmtSrvr] INFO     -- Node 5: Data usage is 82(294191 32K pages of total 356352)
2011-09-01 13:40:53 [MgmtSrvr] INFO     -- Node 5: Index usage is 84(176477 8K pages of total 209024)
2011-09-01 13:40:55 [MgmtSrvr] INFO     -- Node 3: Data usage is 82(294216 32K pages of total 356352)
2011-09-01 13:53:24 [MgmtSrvr] INFO     -- Node 3: Local checkpoint 98 completed
2011-09-01 13:53:24 [MgmtSrvr] INFO     -- Node 6: Suma: asking node 3 to recreate subscriptions on me
2011-09-01 13:53:24 [MgmtSrvr] INFO     -- Node 6: Start phase 5 completed (node restart)
2011-09-01 13:53:24 [MgmtSrvr] INFO     -- Node 6: Start phase 6 completed (node restart)
2011-09-01 13:53:24 [MgmtSrvr] INFO     -- Node 6: Start phase 7 completed (node restart)
....

与集群日志相关的信息也可以发送到 stdout 或者使用 syslog 工具而不是写入文件。
这些可以使用参数 LogDestination 进行调整，该参数指定将日志信息发送到何处。
如果包含值“FILE:”，则它定义了用于记录的文件名，并且还允许最大文件大小和最大文件数。
例如：

LogDestination="FILE:filename=cluster.log,maxsize=1000000,maxfiles=6"

maxsize 字符串以字节为单位设置最大文件大小，然后将日志滚动到新文件。
发生这种情况时，通过将 .N 添加到文件名来重命名旧日志，其中 N 是下一个未使用的递增值。
如果发生翻转时存在的文件数超过 maxfiles，则将删除最旧的文件。

跟踪文件日志

跟踪文件位于发生错误需要生成跟踪文件的本地节点上。
跟踪文件给出了节点通过代码所采用的路径以及错误发生时它在何处完成的指示。
日志基本上分为几个部分，第一部分显示通过代码的路径，第二部分显示沿该路径发生的信号/事件。
以下是跟踪文件的示例片段：

....
NDBFS   001461 
NDBFS   001433 001294 001452 
DBTC    004649 
NDBFS   001461 001294 
DBTC    004649 
NDBFS   001461 001294 
QMGR    000208 003661 003665 
--------------- Signal ---------------
r.bn: 252 "QMGR", r.proc: 3, r.soird: 618218 gsn: 254 "FAIL_REP" prio: 0
s.bn: 252 "QMGR", s.proc: 6, s.soird: 1208832226 length: 3 trace: 8 #sec: 0 fragInf: 0
 FailedNode: 5, FailCause: 5
--------------- Signal ---------------
r.bn: 253 "NDBFS", r.proc: 3, r.soird: 618217 gsn: 164 "CONTINUEB" prio: 1
s.bn: 253 "NDBFS", s.proc: 3, s.soird: 618215 length: 1 trace: 0 #sec: 0 fragInf: 0
 Scanning the memory channel again with no delay
--------------- Signal ---------------
r.bn: 253 "NDBFS", r.proc: 3, r.soird: 618216 gsn: 264 "FSREADREQ" prio: 1
s.bn: 262/1 "RESTORE", s.proc: 3, s.soird: 24744752 length: 7 trace: 2 #sec: 0 fragInf: 0
 UserPointer: 0
 FilePointer: 1484
 UserReference: H'03060003 Operation flag: H'00000023 (No sync, Format=List of global pages)
List of shared pages)
 varIndex: 765
 numberOfPages: 1
 pageData:  H'000440bf, 
--------------- Signal ---------------
r.bn: 253 "NDBFS", r.proc: 3, r.soird: 618215 gsn: 164 "CONTINUEB" prio: 0
s.bn: 253 "NDBFS", s.proc: 3, s.soird: 618209 length: 1 trace: 0 #sec: 0 fragInf: 0
 Scanning the memory channel every 10ms
....

集群日志概述

MySQL 集群本质上可能很复杂，这需要更复杂的日志记录方法来管理所有信息。
日志记录可以在全局级别执行，指示集群的整体健康状况以及节点如何交互。
还有一个本地日志记录级别，它提供特定节点的状态以及可能会或者可能不会影响其他节点的任何内部错误。

集群的全局日志记录是通过日志事件完成的，这些日志事件指示时间戳、严重性级别和所有进入日志文件的消息。
事件类型从统计计数器到连接级别和错误类型不等。
日志事件很好地表明了集群的整体健康状况，以及发生了哪些进程会导致出现问题。