Once the database is running, it is the administrator's role to keep it running. This chapter explains how to perform common maintenance and upgrade tasks, including:
Schema and stored procedure updates
Software and hardware upgrades
It is a common safety precaution to backup all data associated with computer systems and store copies off-site in case of system failure or other unexpected events. Backups are usually done on a scheduled basis (every day, every week, or whatever period is deemed sufficient).
VoltDB provides several options for backing up the database contents. The easiest option is to save a native snapshot then backup the resulting snapshot files to removable media for archiving. The advantage of this approach is that native snapshots contain both a complete copy of the data and the schema. So in case of failure the snapshot can be restored to the current or another cluster using a single voltadmin restore command.
The key thing to remember when using native snapshots for backup is that each server saves its portion of the database locally. So you must fetch the snapshot files for all of the servers to ensure you have a complete set of files. The following example performs a manual snapshot on a five node cluster then uses scp to remotely copy the files from each server to a single location for archiving.
$ voltadmin save --blocking --host=voltsvr3 \ /tmp/voltdb backup $ scp -l 100 'voltsvr1:/tmp/voltdb/backup*' /tmp/archive/ $ scp -l 100 'voltsvr2:/tmp/voltdb/backup*' /tmp/archive/ $ scp -l 100 'voltsvr3:/tmp/voltdb/backup*' /tmp/archive/ $ scp -l 100 'voltsvr4:/tmp/voltdb/backup*' /tmp/archive/ $ scp -l 100 'voltsvr5:/tmp/voltdb/backup*' /tmp/archive/
Note that if you are using automated snapshots or command logging (which also creates snapshots), you can use the automated snapshots as the source of the backup. However, the automated snapshots use a programmatically generated file prefix, so your backup script will need some additional intelligence to identify the most recent snapshot and its prefix.
The preceding example also uses the scp limit flag (
-l 100) to constrain the bandwidth used by the
copy command to 100kbits/second. Use of the -l flag is recommended to avoid the copy operation blocking the VoltDB server
process and impacting database performance.
Finally, if you wish to backup the data in a non-proprietary format, you can use the voltadmin save --format=csv command to create a snapshot of the data as comma-separated value (CSV) formatted text files. The advantage is that the resulting files are usable by more systems than just VoltDB. The disadvantage is that the CSV files only contain the data, not the schema. These files cannot be read directly into VoltDB, like a native snapshot can. Instead, you will need to initialize and start a new database, load the schema, then use the csvloader utility to load individual files into each table to restore the database completely.