Release 10.1C: OpenEdge Replication:
User Guide


Choosing a hot standby database

If failover processing occurs, the target database is available as a hot standby. A hot standby database is a database that is updated and ready to go immediately. (Replicated databases are hot standby databases.) You can have up to two target databases. Only one of the target databases can be set to transition automatically to a normal OpenEdge database by setting its agent to critical and transition to auto. Only one target database can be critical because you do not want users to be updating two different databases after automatic transition has occurred. The second target database is not transitioned unless you manually transition it. This provides you with options for your hot standby choice.

If you choose the target database that automatically transitions to a normal OpenEdge database as your hot standby, it is possible that transactions could be lost when the failure occurs.

If you are running in synchronous mode and the target database transitions to a normal OpenEdge database, a maximum of one transaction per client is lost. If you are running in asynchronous mode, some number of transactions can be lost per client, depending on how far behind the OpenEdge Replication server was when the connection was lost. It also depends on how far behind your source database and server are.

To assist you in determining the number of transactions lost, OpenEdge Replication provides latency reporting. For more information about latency reporting, see the "Latency reporting" section and the "DSRUTIL utility" section.

The advantage to transitioning is that your users will have full access to an alternate database as a hot standby during a failure condition. If you cannot allow for the chance that a transaction is lost during failure processing, the target database with manual transition set will synchronize with your source database once the connection is re-established, so long as you do not transition it. In this scenario there is no risk to transactions being lost.


Copyright © 2008 Progress Software Corporation
www.progress.com