This section provides an overview and describes the implementation of the D3 FSI 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 Windows 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:
|
Primary |
The main server in operation. Only one primary server can be defined. This server is identified with the item-ID psc. |
|
Secondary |
The backup server. Runs concurrently with the primary and maintains a mirror copy of the database on the primary server. Only one secondary server can be defined. This server is identified with the item-ID ssc. |
During normal operations, some or all updates to the database on the primary server can be applied to the secondary server, over the network.
|
NOTE |
Normal operation of Hot Backup is to have the secondary server maintain an exact image of the database on the primary server. However, if an update occurs on a file on the primary server (which did not exist on the secondary), the secondary server will attempt to auto-create that file. In such cases, the file is created as case insensitive with a modulo of 47. |
If the primary server fails, users can be switched to the secondary 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 secondary server). Data loss is limited to any updates that have not been transmitted to the secondary server (typically, this is limited to the updates that occurred in the last few seconds before the failure).
There are 3 queues involved in a Hot backup setup:
|
Primary Queue |
Updates to the primary server are placed in the primary queue on the primary server, which is emptied regularly to the secondary server in a FIFO manner. In normal operation, this queue should remain minimal in size. Operations are physically removed from the queue only when the secondary server acknowledges them. This ensures that if an error occurs before the item is stored in the secondary queue, the operation can be re-transmitted. WARNING— The primary queue can hold up to 2,147,483,646 entries. If the queue grows larger than this (for example, if the secondary queue is down for an extended period of time), entries will be overwritten in a FIFO manner. |
|
Secondary Queue |
Updates are moved from the primary queue on the primary server to the secondary queue on the secondary server in a FIFO manner. |
|
Subqueues |
On the secondary server, operations are distributed across the specified number of subqueues and then processed by helpers (phantom processes) to achieve greater performance. |
These topics are discussed:
See Also
D3 Windows System Administration Guide Overview