RTR Server Types
Figure 1–16 shows a simple shadow configuration. The main (BE) Server at Site 1 and the shadow server (Shadow) at Site
2 both receive every transaction for the data partition they are servicing. Should Site 1 fail, Site 2 continues to operate without interruption. Sites can be geographically remote, for example, available at separate locations in a wide area network (WAN).
Figure 1–16 Shadow Servers
Terminals | Frontends (FE) |
| FE |
Client
FE
Client
FE
Client
Routers (TR)
TR
Backends (BE) | Database (DB) |
BE - SITE 1 |
|
Server | DB |
BE - SITE 2 |
|
Shadow | DB |
|
Concurrent server
Note that each shadow server can also have standby servers.
The concurrent server is an additional instance of a server application running on the same node. RTR delivers transactions to a free server from the pool of concurrent servers. If one server fails, the transaction in process is replayed to another server in the concurrent pool. Concurrent servers are designed primarily to increase throughput and can exploit Symmetric Multiprocessing (SMP) systems. Figure
Concurrent servers allow transactions to be processed in parallel to increase throughput. Concurrent servers deal with the same database partition, and may be implemented as multiple