The IceGrid registry and node both store information in the data directories specified by the IceGrid.Registry.Data and IceGrid.Node.Data properties, respectively. This section describes what the registry and node are storing and discusses backup and recovery techniques.
On this page:
The contents of the registry's data directory depends on the registry's database configuration. By default, the data directory contains a Freeze database environment. If the registry is configured to use SQL, the data directory might contain an SQLite database, or it might be empty if the registry is using a remote SQL server. Regardless of the storage mechanism, the registry stores the following information:
addApplication operation on the IceGrid::Admin interface (which includes the IceGrid GUI and command-line administrative clients). Applications specify servers, well-known objects, object adapters, replica groups, and allocatable objects. Applications can be removed with the removeApplication operation.addObject and addObjectWithType operations on the IceGrid::Admin interface. Well-known objects added by these operations can be removed using the removeObject operation.Ice::LocatorRegistry interface. The property IceGrid.Registry.DynamicRegistration must be set to a value larger than zero to allow the dynamic registration of object adapters. These adapters can be removed using the removeAdapter operation.Client session and administrative sessions established with the IceGrid registry are not persistent. If the registry is restarted, these sessions must be recreated. For client sessions in particular, this implies that objects allocated using the allocation mechanism will no longer be allocated once the IceGrid registry restarts.
If the registry's database is corrupted or lost, you must recover the deployed applications, the well-known objects, and the adapter endpoints. You do not need to worry about the internal proxies stored by the registry, as the nodes and registry replicas will eventually contact the registry again.
Depending on your deployed applications and your use of the registry, you should consider backing up the registry's database, especially if you cannot easily recover the persistent information.
For example, if you rely on dynamically-registered adapters, or on well-known objects registered programmatically via the IceGrid::Admin interface, you should back up the registry database because recovering this information may be difficult. On the other hand, if you only deploy a few applications from XML files, you can easily recover the applications by redeploying their XML files, and therefore backing up the database may be unnecessary.
Be aware that restarting the registry with an empty database may cause the server information stored by the nodes to be deleted. This can be an issue if the deployed servers have databases stored in the node data directory. The next section provides more information on this subject.
The IceGrid node stores information for servers deployed by IceGrid applications. This information is stored in the servers subdirectory of the node's data directory. There is one subdirectory per server; the name of the subdirectory is the server's ID. Each server directory contains configuration files, and may also contain database environments and the distribution data of the server. The node's data directory also contains a distrib directory to store per-application distribution data. This directory contains a subdirectory for each application that specifies a distribution and has a server deployed on the node.
If a server directory is deleted, the node recreates it at startup. The node will also recreate the server configuration files and the database environment directories. However, the node cannot restore the prior contents of a server's database environment. It is your responsibility to back up these database environments and restore them when necessary. If the server or application distribution data is deleted from the node's data directory, you can easily recover the deleted information by patching these distributions again using the IceGrid administrative tools.
If you store your server database environments outside the node's data directory (such as in a directory that is regularly backed up), or if you do not have any database environments inside the node's data directory, you do not need to back up the contents of the node's data directory.
By default, the IceGrid registry uses a Freeze database to store its persistent state. You can configure IceGrid to use an SQL database instead by setting several properties.
When using an SQL database, IceGrid stores its persistent state in four tables:
<instance-name>_<replica-name>_Applications<instance-name>_<replica-name>_Adapters<instance-name>_<replica-name>_Objects<instance-name>_<replica-name>_InternalObjectsIn these table names, instance-name is the value of IceGrid.InstanceName and replica-name is the value of IceGrid.Registry.ReplicaName.
A number of properties control how IceGrid accesses an SQL database:
Ice.Plugin.DBIceGridSqlDB:createSqlDB.IceGrid.SQL.DatabaseTypeIceGrid.SQL.DatabaseNameIceGrid.SQL.HostNameIceGrid.SQL.PortIceGrid.SQL.UserNameIceGrid.SQL.Password