High Availability MySQL Cookbook phần 4 potx

Chapter 2

57

These are the files that are on node1 (which had a nodeID of 3 according to the

management client output earlier).

[root@node1 ~]# cd /var/lib/mysql-cluster/BACKUP/

[root@node1 BACKUP]# ls -lh

total 4.0K

drwxr-x--- 2 root root 4.0K Jul 23 22:31 BACKUP-1

[root@node1 BACKUP]# cd BACKUP-1/

[root@node1 BACKUP-1]# ls -lh

total 156K

-rw-r--r-- 1 root root 126K Jul 23 22:31 BACKUP-1-0.3.Data

-rw-r--r-- 1 root root 18K Jul 23 22:31 BACKUP-1.3.ctl

-rw-r--r-- 1 root root 52 Jul 23 22:31 BACKUP-1.3.log

Node2 will have exactly the same files; the only difference is the nodeID (which is 4). The

same can be seen on the other two storage nodes as follows:

[root@node2 ~]# cd /var/lib/mysql-cluster/BACKUP/BACKUP-1/

[root@node2 BACKUP-1]# ls -lh

total 152K

-rw-r--r-- 1 root root 122K Jul 23 22:31 BACKUP-1-0.4.Data

-rw-r--r-- 1 root root 18K Jul 23 22:31 BACKUP-1.4.ctl

-rw-r--r-- 1 root root 52 Jul 23 22:31 BACKUP-1.4.log

The default location for backups is the BACKUP subfolder in DataDir;

however, the parameter BackupDataDir in config.ini file can be

specified to set this to something else and it is best practice to use a separate

block device for backups, if possible. For example, we could change the

[NDBD_DEFAULT] section to store backups on /mnt/disk2 as follows:

[ndbd default]

DataDir=/var/lib/mysql-cluster

BackupDataDir=/mnt/disk2

NoOfReplicas=2

MySQL Cluster Backup and Recovery

58

There's more…

There are three tricks for the initiation of online backups:

Preventing commands hanging

The START BACKUP command, by default, waits for the backup to complete before returning

control of the management client to the user. This can be annoying, and there are two other

options to achieve the backup:

START BACKUP NOWAIT: This returns control to the user immediately; the

management client will display the output when the backup is completed (and you

can always check the cluster management log.) This has the disadvantage that if

a backup is going to fail, it is likely to fail during this brief initial period where the

management client passes the backup instruction to all storage nodes.

START BACKUP WAIT STARTED: This returns control to the user as soon as the

backup is started (that is, each of the storage nodes has confirmed receipt of the

instruction to start a backup). A backup is unlikely to fail after this point unless

there is a fairly significant change to the cluster (such as a node failure).

Aborting backups in progress

It is possible to abort a backup that is in progress using the ABORT BACKUP <number>, which

will return control immediately and display the output, once all storage nodes confirm receipt

of the abort command.

All of these management client commands can be passed using the following syntax:

[root@node5 ~]# ndb_mgm -e COMMAND

For example, by adding these commands to the cron:

[root@node5 ~]# crontab -e

Add a line such as the following one:

@hourly /usr/bin/ndb_mgm -e "START BACKUP NOWAIT" 2>&1

This trick is particularly useful for simple scripting.

Defining an exact time for a consistent backup

By default, an online backup of a MySQL Cluster takes a consistent backup across all nodes

at the end of the process. This means that if you had two different clusters and ran an online

backup at the same time, the backup would not take place at exactly the same time. The

difference between the two backups would be a function of the backup duration, which

depends on various factors such as the performance of the node and the amount of data to

backup. This also means that if you required a backup of a cluster at an exact time, you can

only guess how long a backup will take and try to configure a backup at the right time.



