Backing Up Cluster Data

You can perform backups with Galera Cluster at the same regularity as with a standard database server, using a backup script. Since replication ensures that all nodes have the exact same data, running a backup script on one node will backup the data on all nodes in the cluster.

The problem with such a simple backup method, though, is that it lacks a Global Transaction ID (GTID). You can use backups of this kind to recover data, but they are insufficient for use in recovering nodes to a well-defined state. Furthermore, some backup procedures can block cluster operations during the backup.

Getting backups with the associated Global Transaction ID requires a different approach.

State Snapshot Transfer as Backup

Taking a full data backup is very similar to node provisioning through a State Snapshot Transfer. In both cases, the node creates a full copy of the database contents, using the same mechanism to associate a Global Transaction ID with the database state. Invoking backups through the state snapshot transfer mechanism has the following benefits:

  • The node initiates the backup at a well-defined point.
  • The node associates a Global Transaction ID with the backup.
  • The node desyncs from the cluster to avoid throttling performance while making the backup, even if the backup process blocks the node.
  • The cluster knows that the node is performing a backup and won’t choose the node as a donor for another node.

In order to use this method for backups, you will need to use a script that implements both your preferred backup procedure and the Galera Arbitrator daemon, triggering it in a manner similar to a state snapshot transfer. You would execute such a script from the command-line like this:

$ garbd --address gcomm:// \
  --group example_cluster --donor example_donor --sst backup

This command triggers the Donor Node to invoke a script with the name, which it looks for in the PATH for the mysqld process. When the donor reaches a well-defined point, a point where no changes are happening to the database, it runs the backup script passing the GTID corresponding to the current database state.


In the command, ‘?gmcast.listen_addr=tcp://’ is an arbitrary listen socket address that Galera Arbitrator opens to communicate with the cluster. You only need to specify this in the event that the default socket address (i.e., is busy).


You may find it useful to create your backup script using a modified version of the standard state snapshot transfer script. For information on scripts of this kind, see Scriptable State Snapshot Transfers.