•Concurrent servers
•Callout servers
These are described in the next few paragraphs. You specify server types to your application in RTR API calls.
RTR server types help to provide continuous availability and a secure transactional environment.
The standby server remains idle while the RTR primary backend server performs its work, accepting transactions and updating the database. When the primary server fails, the standby server takes over, recovers any in-progress transactions, updates the database, and communicates with clients until the primary server returns. There can be many instances of a standby server. Activation of the standby server is transparent to the user.
A typical standby configuration is shown in Figure 1–12, Standby Server Configuration. Both physical servers running the RTR backend software are assumed by RTR to connect to the same database. The primary server is typically in use, and the standby server can be either idle or used for other applications, or data partitions, or facilities. When the primary server becomes unavailable, the standby server takes over and completes transactions as shown by the dashed line. Primary server failure could be caused by server process failure or backend (node) failure.
The intended and most common use of a standby server is in a cluster environment. In a non- cluster environment, seamless failover of standbys is not guaranteed.
Standby servers are ``spare'' servers which automatically take over from the main backend if it fails. This takeover is transparent to the application.
Figure 1–15 shows a simple standby configuration. The two backend nodes are members of a cluster environment, and are both able to access the database.
For any one key range, the main or primary server (Server) runs on one node while the standby server (Standby) runs on the other node. The standby server process is running, but RTR does not pass any transactions to it. Should the primary node fail, RTR starts passing transactions to (Standby). Note that