Note Check the solidDB Release Notes for any limitations that are associated with using a grid in the current release.
Use the following steps to backup and restore a grid.
Backup
1 Create backups for each individual grid node by using one of the following methods:
▪ Run the command ADMIN COMMAND 'backup'.
▪ Schedule the backup by using the Srv.At parameter in solid.ini.
2 Check that the backup of each node completed successfully by using any of the following methods:
▪ Check solmsg.out file.
▪ Run the command ADMIN COMMAND 'messages'.
▪ Run the command ADMIN COMMAND 'status backup'.
3 Move the database files created by each individual node to a safe location ready for data restoration.
Restore
1 Start a new grid with the required number of nodes. The number of nodes can differ from the number of nodes in the original grid.
2 Create a schema for the data. You can create a schema creation script from one of the backup files by using soldd, see solidDB Data Dictionary (soldd).
3 Start the new grid nodes one at a time and the complete the following steps:
a Export the data from the backup files for a node by using solexp, see solidDB Export (solexp).
Since the backup data for each node contains full datasets, the same individual rows exist in multiple nodes. When loading the new grid, a significant number of uniqueness failures are expected.
Since the data is based on contents of individual nodes and the state of each node at the time of backup, the restored database might not represent the state of the grid at the time of the failure. The discrepancy is based on two main factors:
▪ During the node backup, the grid continues to accept write operations. These write operations might be missed unless the transactions logs are copied to safe location after the backup. Keeping a copy of the transaction logs should reduce the amount of lost data but does not fully resolve the problem.
▪ Since individual node backups are independent processes that are not synchronized, the backup of each grid node might have slightly different content. When data from multiple nodes is loaded into a new grid (step 3b), there is no mechanism to guarantee that the latest write operations have been captured.