Skip to content

Backup#

Any highly available DBMS requires a backup service. In RonDB this was implemented already in version 2.1 of NDB Cluster. So it has been around for more than 15 years in NDB.

Starting a backup is easy. It is started via the RonDB management client.

ndb_mgm --ndb-connectstring=mgm_host
ndb_mgm> START BACKUP

This command kicks off the execution of a backup in the entire cluster. When the backup is completed it will report back to the RonDB management client a completion report. The completion report contains some statistics about the backup execution such as how many records were backed up, how many log records were written to the backup as part of the backup, which is the starting global checkpoint identifier and what is the last global checkpoint identifier and how many bytes were written.

The backup can take considerable time to execute if there is a large amount of data in the cluster. The speed of writing backups is controlled by the same set of configuration parameters that control the local checkpoint speed, thus MinDiskWriteSpeed and MaxDiskWriteSpeed.

The result of the backup is written into a set of files per node. The first file is called BACKUP-nodeid.backupid.Data.

This file contains the data backed up. Next, there is a file called BACKUP-nodeid.backupid.ctl. This file contains the metadata of the tables backed up. Finally, there is a file called BACKUP-nodeid.backupid.log. This file contains all changes since the backup was started.

Backup algorithm#

A backup is executed starting from a specific global checkpoint. All changes from this global checkpoint until the last global checkpoint triggers a write to the log file mentioned above.

The backup scans each table partition to find all records in the database. Before the data is scanned we record all table definitions in the control file of the backup.

To restore a database from a backup means first restoring the tables from the control file, next the data file is processed to insert all rows in the database again. Finally, the log is executed to install all changes during the backup execution. The log is needed to ensure that the backup is a transaction consistent checkpoint at the last global checkpoint. It is possible to define the backup point to the be first global checkpoint if desirable. This means that the log will record how to UNDO the actions that happened during the backup rather than how to REDO the actions.

The START BACKUP command#

It is possible to specify for how long to wait until control is returned such that new commands can be issued in the NDB management client. It is possible to use:

  1. START BACKUP NOWAIT

  2. START BACKUP WAIT COMPLETED

  3. START BACKUP WAIT STARTED

WAIT COMPLETED is the default setting. NOWAIT means that we don’t wait at all. The completion report will still be reported back to the management client even if new commands have been issued.

WAIT STARTED means that we wait for backup to start, but not wait for it to complete.

Next, it is possible to change whether the backup is taken at the start of the backup or at the finish of the backup.

  1. START BACKUP SNAPSHOTSTART

  2. START BACKUP SNAPSHOTEND

SNAPSHOTEND is the default.

Aborting a backup#

If for some reason we discover that the backup cannot proceed it is possible to abort it. This is performed from the RonDB management client as well by using the ABORT BACKUP command.

ndb_mgm --ndb-connectstring=mgm_host
ndb_mgm> ABORT BACKUP backupid

This command causes all backup files so far created by the backup to be deleted.

Backup file placement#

The backup files are by default placed in the directory BACKUP under the RonDB data nodes data directory. There will be one such directory in each data node in the cluster. For each backup a new directory is created under this directory called BACKUP-backupid.

Often it is a good idea to place the backup files in a directory you decide on yourself. In this case set this directory in the cluster configuration parameter BackupDataDir.

Backup configuration#

Most of the configuration parameters are shared with the local checkpoint process. These are the following parameters:

The configuration parameter that is strictly used by the backup and not by the local checkpoint process is the BackupLogBufferSize. This is where all changes are recorded during the backup process. If the bandwidth to the disk have occasional dips it is useful to increase this buffer size. If a change occurs and there is no room in the log buffer the backup will be aborted. This parameter is set automatically based on the number of threads in the RonDB data node.

There is one such log buffer of the configured size in each ldm thread.

Backup file management#

Once a backup is completed, the files created are in the hands of the DBA. There is no automatic maintenance of those files. Thus it is important to not execute a backup when there is no file space on the device.

For stability reasons it is a good idea to place the BackupDataDir on a separate device from the RonDB data directory. This ensures that creating backups cannot jeopardize the operation of RonDB. Filling the disk device means that there will be no space for checkpoints anymore and this can lead to a crash of the node and even of the entire cluster. By placing backups on a separate device this is no longer possible.

Backing up metadata in RonDB#

It is possible to use the backups to recreate tables in MySQL. In many cases it is advisable to use backups only for the data part of the backup and instead use mysqldump for the metadata part.

mysqldump \
    --no-data \
    --databases \
    list_of_database_names > backup_metadata.sql

The above command dumps the table definitions together with the CREATE DATABASE commands to restore the databases used by RonDB. By placing RonDB tables in their own database this makes it possible to only perform a backup of the RonDB tables used by the MySQL Server and avoid all local tables that might exist at the same time in the MySQL Server.

mysqldump can also be used to dump other things such as stored procedures, stored functions, triggers, views and so forth. These MySQL objects are not part of the RonDB backups. The RonDB backups only backup the tables and their data.