Hot Backup

This section provides an overview and describes the implementation of the D3 UNIX Hot Backup utility.

It is often necessary to employ a strategy that significantly limits down-time due to hardware or software failures. A solution, often more affordable than fault tolerance, is to double your hardware resources by maintaining your database on two separate servers. Hot Backup is a D3 UNIX feature that employs a backup server in standby mode, ready to handle the workload should a system failure occur.

The Hot Backup configuration involves two servers:

Server	Description
Master	The main server in operation.
Slave	The backup server. Runs concurrently with the master and maintains a mirror copy of the database on the master server.

These servers are connected via a TCP/IP connection.

During normal operations, some or all updates to the database on the master server can be applied to the slave server, over the network.

If the master server fails, users can be switched to the slave server, and the application restarted. Down-time is limited to the time it takes to switch servers (usually the time required for terminal connectors to establish an Ethernet connection to the slave server). Data loss is limited to any updates that have not been transmitted to the slave server (typically, this is limited to the updates that occurred in the last few seconds before the failure).

Definitions

Term	Description
server	A background process. Hot Backup servers work in pairs: one on each machine.
master	Main server on which users normally work. The server running on the master system is called the master server.
slave	Backup for the master server. The server running on the slave system is called the slave server.
transaction log queue	Updates to the master server are placed in the transaction log queue on the master server, which is emptied regularly to the slave server in a FIFO manner. In normal operation, this queue should remain minimal in size. When a transaction is extracted from the queue, it is assigned a transaction number. Transactions are physically removed from the queue only when the slave server acknowledges them. This ensures that if an error occurs before the item is stored in the remote file, the transaction can be sent again to the slave.
log slave updates	Updates to the slave server itself are not logged in the slave server’s transaction log queue. However, it is possible to set up the system so that a slave server acts as a master server to another slave (to cascade updates). This type of Hot Backup configuration is set up using the Log slave update option in the Setup Server utility.
apply updates	It is possible to instruct a slave server not to modify the database on the slave server. Updates received from the master server are not applied to the slave database. Instead they are stored in a temporary file. The purpose is to have a quiescent database on the slave server without stopping the master server (for example, to allow a full save of the database). Updates can then be applied to the slave database at a later time.
file and account auto-create	Normal operation of Hot Backup is to have an exact image of the master database. Optionally, the slave server attempts to create any nonexistent accounts or files on the slave server.
helper	On the slave server, long operations, such as clearing large files, are not processed by the slave server itself, since it would not be able to process any incoming data. The slave server creates helpers (phantom processes) to perform these operations.
large file creation	Files with modulos larger than 100 are initially created by the slave server with a modulo of 101. A helper process then resizes the file to its actual size. This allows you to instantly create the file, making it available on the slave system without stopping the slave server. The slave server performs periodic checks on the helper to ensure that it completes.
temporary hold files	Slave systems sometimes create temporary files on the slave server to hold data that cannot be transmitted to its destination immediately. For example, when a clear-file command is run, a helper performs the actual clearing and a temporary hold file holds any updates to the file being cleared that are received after the clear command. This ensures that the updates are not deleted.