MySQL Cluster Tutorial - cdn.oreillystatic.com
MySQL Cluster Tutorial - cdn.oreillystatic.com
MySQL Cluster Tutorial - cdn.oreillystatic.com
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
ndb_mgm> 2 restart<br />
Node 2: Node shutdown initiated<br />
Node 2: Node shutdown <strong>com</strong>pleted, restarting, no start.<br />
Node 2 is being restarted<br />
ndb_mgm> Node 2: Started (version 7.1.2)<br />
START BACKUP<br />
This <strong>com</strong>mand initiates a cluster backup. This is covered in more detail in the 'Online<br />
Backup' section of this document.<br />
It can basically be executed using:<br />
ndb_mgm> start backup<br />
Waiting for <strong>com</strong>pleted, this may take several minutes<br />
Node 3: Backup 1 started from node 1<br />
Node 3: Backup 1 started from node 1 <strong>com</strong>pleted<br />
StartGCP: 474 StopGCP: 477<br />
#Records: 2053 #LogRecords: 0<br />
Data: 50312 bytes Log: 0 bytes<br />
There are additional parameters for this <strong>com</strong>mand too. These can change the backup<br />
number (normally sequential), whether or not the client should wait for it to <strong>com</strong>plete and<br />
whether the snapshot should be consistent to the point of the start of the backup, or end of<br />
the backup. So:<br />
START BACKUP [backup_id] [wait_option] [snapshot_option]<br />
wait_option:<br />
WAIT {STARTED | COMPLETED} | NOWAIT<br />
snapshot_option:<br />
SNAPSHOTSTART | SNAPSHOTEND<br />
The default is:<br />
START BACKUP {next_backup_id} WAIT COMPLETED SNAPSHOTEND<br />
REPORT<br />
There are currently two reports you can get using this <strong>com</strong>mand, BACKUPSTATUS and<br />
MEMORYUSAGE. Although shorter versions of these names can be used. For example:<br />
ndb_mgm> all report memory<br />
Node 2: Data usage is 0%(22 32K pages of total 2560)<br />
Node 2: Index usage is 0%(16 8K pages of total 2336)<br />
Node 3: Data usage is 0%(22 32K pages of total 2560)<br />
Node 3: Index usage is 0%(16 8K pages of total 2336)<br />
DUMP<br />
This is probably the most dangerous <strong>com</strong>mand and should not be used on a production<br />
cluster. The developers added dump codes in various cluster <strong>com</strong>ponents to get<br />
information out or trigger an action. If there are any results for the code these are sent to<br />
the management node's log file. Using the wrong number for a dump code can easily take<br />
down an entire cluster. One example is the dump code '1000' which does the same as<br />
REPORT MEMORYUSAGE, but it is recorded in the management node log instead:<br />
ndb_mgm> all dump 1000<br />
Sending dump signal with data:<br />
0x000003e8<br />
Sending dump signal with data:<br />
0x000003e8<br />
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 19/81