Rechercher dans le manuel MySQL

22.6.9.2 Point-In-Time Recovery Using NDB Cluster Replication

Table des matières

Point-in-time 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 CREATE BACKUP in the ndb_mgm client) and restoring the 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:

  1. Back up all NDB databases in the cluster, using the START BACKUP command in the ndb_mgm client (see Section 22.5.3, “Online Backup of NDB Cluster”).

  2. At some later point, prior to restoring the cluster, make a backup of the mysql.ndb_binlog_index table. 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.

  3. (Catastrophic failure or error occurs.)

  4. Locate the last known good backup.

  5. Clear the data node file systems (using ndbd --initial or ndbmtd --initial).

    Note

    NDB Cluster Disk Data tablespace and log files are not removed by --initial. You must delete these manually.

  6. Use DROP TABLE or TRUNCATE TABLE with the mysql.ndb_binlog_index table.

  7. Execute ndb_restore, restoring all data. You must include the --restore-epoch option when you run ndb_restore, so that the ndb_apply_status table is populated correctly. (See Section 22.4.23, “ndb_restore — Restore an NDB Cluster Backup”, for more information.)

  8. Restore the ndb_binlog_index table from the output of mysqldump and restore the binary log files from backup, if necessary.

  9. Find the epoch applied most recently—that is, the maximum epoch column value in the ndb_apply_status table—as the user variable @LATEST_EPOCH (emphasized):

    1. SELECT @LATEST_EPOCH:=MAX(epoch)
    2.     FROM mysql.ndb_apply_status;

  10. Find the latest binary log file (@FIRST_FILE) and position (Position column value) within this file that correspond to @LATEST_EPOCH in the ndb_binlog_index table:

    1. SELECT Position, @FIRST_FILE:=File
    2.     FROM mysql.ndb_binlog_index
    3.     WHERE epoch > @LATEST_EPOCH ORDER BY epoch ASC LIMIT 1;

  11. Using mysqlbinlog, replay the binary log events from the given file and position up to the point of the failure. (See Section 4.6.8, “mysqlbinlog — Utility for Processing Binary Log Files”.)

See also Section 7.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”, for more information about the binary log, replication, and incremental recovery.


Rechercher dans le manuel MySQL

Traduction non disponible

Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.

Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-mysql-cluster-replication-pitr.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Références

  1. Consulter le document html Langue du document :en Manuel MySQL : https://dev.mysql.com/

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Table des matières Haut