An event report reported in the event logs has the following format:
datetime [string] severity -- message
09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed
This section discusses all reportable events, ordered by category and severity level within each category.
In the event descriptions, GCP and LCP mean “Global Checkpoint” and “Local Checkpoint”, respectively.
These events are associated with connections between Cluster nodes.
|8||Data nodes connected|
|8||Data nodes disconnected|
|8||SQL node or data node connection closed|
|8||SQL node or data node connection open|
|8||Connection using API version|
The logging messages shown here are associated with checkpoints.
|9||Start of GCP: REDO log is written to disk|
|7||Start of LCP: data written to disk|
|7||LCP completed normally|
|11||LCP on a fragment has been completed|
|7||UNDO logging blocked; buffer near overflow|
The following events are generated in response to the startup of a node or of the cluster and of its success or failure. They also provide information relating to the progress of the startup process, including information concerning logging activities.
|1||Data node start phases initiated (all nodes starting)|
|1||Start phases completed, all data nodes|
|15||Blocks received after completion of restart|
|4||Data node start phase |
|3||Node has been successfully included into the cluster; shows the node, managing node, and dynamic ID|
|8||Node has been refused for inclusion in the cluster; cannot be included in cluster due to misconfiguration, inability to establish communication, or other problem|
|8||Shows neighboring data nodes|
|1||Data node shutdown initiated|
|1||Data node shutdown complete|
|1||Forced shutdown of data node|
|1||Unable to shut down data node normally|
|4||New redo log started; GCI keep |
|10||New log started; log part |
|15||Undo records executed|
|7||Log file initialization status|
|7||Log file completion status|
|10||Start read for local checkpoint|
|10||Read for local checkpoint completed|
|8||Running the redo log|
The following events are generated when restarting a node and relate to the success or failure of the node restart process.
|7||Completed copying of dictionary information|
|7||Completed copying distribution information|
|7||Starting to copy fragments|
|10||Completed copying a fragment|
|7||Completed copying all fragments|
|8||Node failure phase completed|
|8||Reports that a node has failed|
|6||Report whether an arbitrator is found or not; there are seven different
possible outcomes when seeking an arbitrator, listed
|2||Report arbitrator results; there are eight different possible results
for arbitration attempts, listed here:
|7||GCP takeover started|
|7||GCP takeover complete|
|7||LCP takeover started|
|7||LCP takeover complete (state = |
|6||Connection check started|
|6||Connection check completed|
|6||Node failure phase failed|
The following events are of a statistical nature. They provide information such as numbers of transactions and other operations, amount of data sent or received by individual nodes, and memory usage.
|8||Report transaction statistics, including numbers of transactions, commits, reads, simple reads, writes, concurrent operations, attribute information, and aborts|
|8||Number of operations|
|7||Report number of tables created|
|9||Mean internal job scheduling statistics|
|9||Number of thread configuration loops|
|9||Mean number of bytes sent to node |
|9||Mean number of bytes received from node |
|5||Data and index memory usage (80%, 90%, and 100%)|
These events relate to NDB Cluster schema operations.
|8||Schema objected created|
|8||Schema object updated|
|8||Schema object dropped|
These events relate to Cluster errors and warnings. The presence of one or more of these generally indicates that a major malfunction or failure has occurred.
|2||General warning event|
|4||Change in subscription status|
These events provide general information about the state of the cluster and activities associated with Cluster maintenance, such as logging and heartbeat transmission.
|11||Create log: Log part, log file, size in MB|
|2||General informational event|
|7||Event buffer status|
|7||Improved event buffer status information; added in NDB 7.5.1|
SentHeartbeat events are available only if
NDB Cluster was compiled with
Node node_id: Event buffer status: used=bytes_used (used as a percent of alloc) alloc=bytes_allocated (alloc as a % of max. If max is 0 (unlimited) the % will not be printed) max=bytes_available (if not configured, max will be 0, meaning unlimited, i.e. no limit on event buffer memory usage) latest_consumed_epoch=epoch that was consumed completely (using nextEvent()) latest_buffered_epoch=epoch which is buffered completely in the event buffer ndb_reference=the object id of the Ndb that originates the report report_reason=the reason for reporting this log event Note: latest_consumed_epoch is the same as apply_gci of the old EventBufferStatus and latest_buffered_epoch is the same as latest_gci of the old EventBufferStatus. Remember to chagnge the explanations of apply_gci and latest_gci in the old EventBufferStatus.
These events are associated with entering and exiting single user mode.
|7||Entering or exiting single user mode|
These events provide information about backups being created or restored.
|7||Backup failed to start|
|7||Backup aborted by user|
|7||Started restoring from backup|
|7||Restoring log files|
|7||Completed restoring from backup|