MySQL 8.0 Reference Manual
MySQL 8.0 Release Notes
The following table lists the most common
NDB cluster log messages. For
information about the cluster log, log events, and event types,
see Section 6.3, “Event Reports Generated in NDB Cluster”. These log
messages also correspond to log event types in the MGM API; see
The Ndb_logevent_type Type, for related information
of interest to Cluster API developers.
Table 6.1 Common NDB cluster log messages
| Log Message | Description | Event Name | Event Type | Priority | Severity |
|---|---|---|---|---|---|
Node |
The data node having node ID node_id has
connected to the management server (node
mgm_node_id). |
Connected |
Connection |
8 | INFO |
Node |
The data node having node ID data_node_id has
disconnected from the management server (node
mgm_node_id). |
Disconnected |
Connection |
8 | ALERT |
Node |
The API node or SQL node having node ID
api_node_id is no longer
communicating with data node
data_node_id. |
CommunicationClosed |
Connection |
8 | INFO |
Node |
The API node or SQL node having node ID
api_node_id is now
communicating with data node
data_node_id. |
CommunicationOpened |
Connection |
8 | INFO |
Node |
The API node having node ID api_node_id has
connected to management node
mgm_node_id using
NDB API version
version (generally the same as
the MySQL version number). |
ConnectedApiVersion |
Connection |
8 | INFO |
Node |
A global checkpoint with the ID gci has been
started; node node_id is the
master responsible for this global checkpoint. |
GlobalCheckpointStarted |
Checkpoint |
9 | INFO |
Node |
The global checkpoint having the ID gci has
been completed; node node_id
was the master responsible for this global checkpoint. |
GlobalCheckpointCompleted |
Checkpoint |
10 | INFO |
Node |
The local checkpoint having sequence ID lcp
has been started on node
node_id. The most recent GCI
that can be used has the index
current_gci, and the oldest GCI
from which the cluster can be restored has the index
old_gci. |
LocalCheckpointStarted |
Checkpoint |
7 | INFO |
Node |
The local checkpoint having sequence ID lcp
on node node_id has been
completed. |
LocalCheckpointCompleted |
Checkpoint |
8 | INFO |
Node |
The node was unable to determine the most recent usable GCI. | LCPStoppedInCalcKeepGci |
Checkpoint |
0 | ALERT |
Node |
A table fragment has been checkpointed to disk on node
node_id. The GCI in progress
has the index started_gci, and
the most recent GCI to have been completed has the index
completed_gci. |
LCPFragmentCompleted |
Checkpoint |
11 | INFO |
Node |
Undo logging is blocked because the log buffer is close to overflowing. | UndoLogBlocked |
Checkpoint |
7 | INFO |
Node |
Data node node_id, running
NDB version
version, is beginning its
startup process. |
NDBStartStarted |
StartUp |
1 | INFO |
Node |
Data node node_id, running
NDB version
version, has started
successfully. |
NDBStartCompleted |
StartUp |
1 | INFO |
Node |
The node has received a signal indicating that a cluster restart has completed. | STTORRYRecieved |
StartUp |
15 | INFO |
Node |
The node has completed start phase phase of a
type start. For a listing of
start phases, see
Section 6.4, “Summary of NDB Cluster Start Phases”.
(type is one of
initial, system,
node, initial node,
or <Unknown>.) |
StartPhaseCompleted |
StartUp |
4 | INFO |
Node |
Node president_id has been selected as
“president”.
own_id and
dynamic_id should always be the
same as the ID (node_id) of the
reporting node. |
CM_REGCONF |
StartUp |
3 | INFO |
Node |
The reporting node (ID node_id) was unable to
accept node president_id as
president. The cause of the
problem is given as one of Busy,
Election with wait = false,
Not president, Election
without selecting new candidate, or No
such cause. |
CM_REGREF |
StartUp |
8 | INFO |
Node |
The node has discovered its neighboring nodes in the cluster (node
id_1 and node
id_2).
node_id,
own_id, and
dynamic_id should always be the
same; if they are not, this indicates a serious
misconfiguration of the cluster nodes. |
FIND_NEIGHBOURS |
StartUp |
8 | INFO |
Node |
The node has received a shutdown signal. The
type of shutdown is either
Cluster or Node. |
NDBStopStarted |
StartUp |
1 | INFO |
Node [,
]
[Initiated by signal
] |
The node has been shut down. This report may include an
action, which if present is one
of restarting, no
start, or initial. The report
may also include a reference to an
NDB Protocol
signal; for possible signals,
refer to
Operations and Signals. |
NDBStopCompleted |
StartUp |
1 | INFO |
Node [,
action]. [Occurred
during startphase
]
[ Initiated by
]
[Caused by error
[(extra info
]] |
The node has been forcibly shut down. The
action (one of
restarting, no
start, or initial)
subsequently being taken, if any, is also reported. If the
shutdown occurred while the node was starting, the report
includes the start_phase during
which the node failed. If this was a result of a
signal sent to the node, this
information is also provided (see
Operations and Signals,
for more information). If the error causing the failure is
known, this is also included; for more information about
NDB error messages and
classifications, see NDB Cluster API Errors. |
NDBStopForced |
StartUp |
1 | ALERT |
Node |
The node shutdown process was aborted by the user. | NDBStopAborted |
StartUp |
1 | INFO |
Node |
This reports global checkpoints referenced during a node start. The redo
log prior to keep_pos is
dropped. last_pos is the last
global checkpoint in which data node the participated;
restore_pos is the global
checkpoint which is actually used to restore all data
nodes. |
StartREDOLog |
StartUp |
4 | INFO |
startup_message [Listed separately;
see below.] |
There are a number of possible startup messages that can be logged under different circumstances. These are listed separately; see Section 6.2.2, “NDB Cluster Log Startup Messages”. | StartReport |
StartUp |
4 | INFO |
Node |
Copying of data dictionary information to the restarted node has been completed. | NR_CopyDict |
NodeRestart |
8 | INFO |
Node |
Copying of data distribution information to the restarted node has been completed. | NR_CopyDistr |
NodeRestart |
8 | INFO |
Node |
Copy of fragments to starting data node
node_id has begun |
NR_CopyFragsStarted |
NodeRestart |
8 | INFO |
Node |
Fragment fragment_id from table
table_id has been copied to
data node node_id |
NR_CopyFragDone |
NodeRestart |
10 | INFO |
Node |
Copying of all table fragments to restarting data node
node_id has been completed |
NR_CopyFragsCompleted |
NodeRestart |
8 | INFO |
Node |
Data node node1_id has detected the failure
of data node node2_id |
NodeFailCompleted |
NodeRestart |
8 | ALERT |
All nodes completed failure of Node
|
All (remaining) data nodes have detected the failure of data node
node_id |
NodeFailCompleted |
NodeRestart |
8 | ALERT |
Node failure of
|
The failure of data node node_id has been
detected in the
blockNDB
kernel block, where block is 1 of
DBTC,
DBDICT,
DBDIH, or
DBLQH; for more
information, see
NDB Kernel Blocks |
NodeFailCompleted |
NodeRestart |
8 | ALERT |
Node |
A data node has failed. Its state at the time of failure is described by
an arbitration state code
state_code: possible state code
values can be found in the file
include/kernel/signaldata/ArbitSignalData.hpp. |
NODE_FAILREP |
NodeRestart |
8 | ALERT |
President restarts arbitration thread
[state= or
Prepare arbitrator node
or
Receive arbitrator node
or
Started arbitrator node
or
Lost arbitrator node
or
Lost arbitrator node
or
Lost arbitrator node
|
This is a report on the current state and progress of arbitration in the
cluster. node_id is the node ID
of the management node or SQL node selected as the
arbitrator. state_code is an
arbitration state code, as found in
include/kernel/signaldata/ArbitSignalData.hpp.
When an error has occurred, an
error_message, also defined in
ArbitSignalData.hpp, is provided.
ticket_id is a unique
identifier handed out by the arbitrator when it is
selected to all the nodes that participated in its
selection; this is used to ensure that each node
requesting arbitration was one of the nodes that took part
in the selection process. |
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
or
Arbitration lost - negative reply from node
or
Network partitioning - no arbitrator
available or Network partitioning - no
arbitrator configured or Arbitration
failure - |
This message reports on the result of arbitration. In the event of
arbitration failure, an
error_message and an
arbitration state_code are
provided; definitions for both of these are found in
include/kernel/signaldata/ArbitSignalData.hpp. |
ArbitResult |
NodeRestart |
2 | ALERT |
Node |
This node is attempting to assume responsibility for the next global checkpoint (that is, it is becoming the master node) | GCP_TakeoverStarted |
NodeRestart |
7 | INFO |
Node |
This node has become the master, and has assumed responsibility for the next global checkpoint | GCP_TakeoverCompleted |
NodeRestart |
7 | INFO |
Node |
This node is attempting to assume responsibility for the next set of local checkpoints (that is, it is becoming the master node) | LCP_TakeoverStarted |
NodeRestart |
7 | INFO |
Node |
This node has become the master, and has assumed responsibility for the next set of local checkpoints | LCP_TakeoverCompleted |
NodeRestart |
7 | INFO |
Node |
This report of transaction activity is given approximately once every 10 seconds | TransReportCounters |
Statistic |
8 | INFO |
Node |
Number of operations performed by this node, provided approximately once every 10 seconds | OperationReportCounters |
Statistic |
8 | INFO |
Node |
A table having the table ID shown has been created | TableCreated |
Statistic |
7 | INFO |
Node |
JobStatistic |
Statistic |
9 | INFO |
|
Mean send size to Node = |
This node is sending an average of bytes
bytes per send to node node_id |
SendBytesStatistic |
Statistic |
9 | INFO |
Mean receive size to Node = |
This node is receiving an average of bytes of
data each time it receives data from node
node_id |
ReceiveBytesStatistic |
Statistic |
9 | INFO |
Node /
Node |
This report is generated when a DUMP
1000 command is issued in the cluster management
client |
MemoryUsage |
Statistic |
5 | INFO |
Node |
A transporter error occurred while communicating with node
node2_id; for a listing of
transporter error codes and messages, see
NDB Transporter Errors, in
MySQL NDB Cluster Internals Manual |
TransporterError |
Error |
2 | ERROR |
Node |
A warning of a potential transporter problem while communicating with
node node2_id; for a listing of
transporter error codes and messages, see
NDB Transporter Errors, for more
information |
TransporterWarning |
Error |
8 | WARNING |
Node |
This node missed a heartbeat from node
node2_id |
MissedHeartbeat |
Error |
8 | WARNING |
Node |
This node has missed at least 3 heartbeats from node
node2_id, and so has declared
that node “dead” |
DeadDueToHeartbeat |
Error |
8 | ALERT |
Node |
This node has sent a heartbeat to node
node2_id |
SentHeartbeat |
Info |
12 | INFO |
Node |
This report is seen during heavy event buffer usage, for example, when many updates are being applied in a relatively short period of time; the report shows the number of bytes and the percentage of event buffer memory used, the bytes allocated and percentage still available, and the latest buffered and consumed epochs; for more information, see Section 6.2.3, “Event Buffer Reporting in the Cluster Log” | EventBufferStatus2 |
Info |
7 | INFO |
Node , Node
, Node
|
These reports are written to the cluster log when entering and exiting
single user mode; API_node_id
is the node ID of the API or SQL having exclusive access
to the cluster (for more information, see
Section 6.6, “NDB Cluster Single User Mode”); the
message Unknown single user report
indicates
an error has taken place and should never be seen in
normal operation |
SingleUser |
Info |
7 | INFO |
Node |
A backup has been started using the management node having
mgm_node_id; this message is
also displayed in the cluster management client when the
START BACKUP command
is issued; for more information, see
Section 6.8.2, “Using The NDB Cluster Management Client to Create a Backup” |
BackupStarted |
Backup |
7 | INFO |
Node |
The backup having the ID backup_id has been
completed; for more information, see
Section 6.8.2, “Using The NDB Cluster Management Client to Create a Backup” |
BackupCompleted |
Backup |
7 | INFO |
Node |
The backup failed to start; for error codes, see MGM API Errors | BackupFailedToStart |
Backup |
7 | ALERT |
Node |
The backup was terminated after starting, possibly due to user intervention | BackupAborted |
Backup |
7 | ALERT |