recovery—that is, recovery of data changes made since a
given point in time—is performed after restoring a full
backup that returns the server to its state when the backup was
made. Performing point-in-time recovery of NDB Cluster tables
with NDB Cluster and NDB Cluster Replication can be accomplished
using a native
NDB data backup
(taken by issuing
BACKUP in the ndb_mgm client) and
ndb_binlog_index table (from a
dump made using mysqldump).
To perform point-in-time recovery of NDB Cluster, it is necessary to follow the steps shown here:
Back up all
NDBdatabases in the cluster, using the
START BACKUPcommand in the ndb_mgm client (see Section 21.6.8, “Online Backup of NDB Cluster”).
At some later point, prior to restoring the cluster, make a backup of the
mysql.ndb_binlog_indextable. It is probably simplest to use mysqldump for this task. Also back up the binary log files at this time.
This backup should be updated regularly—perhaps even hourly—depending on your needs.
(Catastrophic failure or error occurs.)
Locate the last known good backup.
Clear the data node file systems (using ndbd
NDB Cluster Disk Data tablespace and log files are not removed by
--initial. You must delete these manually.
TRUNCATE TABLEwith the
Execute ndb_restore, restoring all data. You must include the
--restore-epochoption when you run ndb_restore, so that the
ndb_apply_statustable is populated correctly. (See Section 21.5.24, “ndb_restore — Restore an NDB Cluster Backup”, for more information.)
ndb_binlog_indextable from the output of mysqldump and restore the binary log files from backup, if necessary.
Find the epoch applied most recently—that is, the maximum
epochcolumn value in the
ndb_apply_statustable—as the user variable
SELECT @LATEST_EPOCH:=MAX(epoch) FROM mysql.ndb_apply_status;
Find the latest binary log file (
@FIRST_FILE) and position (
Positioncolumn value) within this file that correspond to
SELECT Position, @FIRST_FILE:=File FROM mysql.ndb_binlog_index WHERE epoch > @LATEST_EPOCH ORDER BY epoch ASC LIMIT 1;
Using mysqlbinlog, replay the binary log events from the given file and position up to the point of the failure. (See Section 4.6.7, “mysqlbinlog — Utility for Processing Binary Log Files”.)
See also Section 7.5, “Point-in-Time (Incremental) Recovery”, for more information about the binary log, replication, and incremental recovery.