Backups and the recovery process are a very important topic for a database management system. Backups act as the last line of defense if everything else goes wrong. There are two possible causes of these catastrophic events. The first is a user-induced failure, in which a user accidentally or maliciously affects your data in a negative way. An example would be if someone issued DROP TABLE or DELETE to remove data. The only way to recover in the event of such an action would be to use a backup. The second possible cause of a catastrophic data loss is if you have simultaneous hardware failures on all the members of a node group. For example, if all the node groups suffer a hard drive corruption/failure, there won't be data available to recover from. Generally, to mitigate the danger from these events occurring, you should make backups quite frequently (normally at least once per day, if not more frequently).
You may also need to do a backup and recover from it if you are upgrading or changing a system setting. Many upgrades and configuration changes can be online, but some cannot be. The configuration parameters that require a backup/recovery process are ones that affect the partitioning of the data, including NoOfReplicas, as well as those that change the number of data nodes in the cluster. As far as software upgrades are concerned, generally minor updates (for example, from version 5.0.12 to version 5.0.13) can be done in an online manner through a rolling upgrade process (as explained in Chapter1, "Installation"). Major version upgrades (for example, from version 4.1 to version 5.0) also require a backup/restore in order to proceed.
Installation
Configuration
Backup and Recovery
Security and Management
Performance
Troubleshooting
Common Setups
A MySQL Cluster Binaries
B Management Commands
C Glossary of Cluster Terminology
Index