Try OpenEdge Now
skip to main content
User Guide
Moving From Failure to Recovery with OpenEdge Replication : OpenEdge Replication from normal activity through failure and recovery : Step 9: The Replication failback process : Failback processing using transition failover
 
Failback processing using transition failover
When secondary replication is being performed, as shown in the following figure, both databases are up and running and all secondary transactions are being replicated to the primary database.
Figure 25. Secondary replication continues (before transition failover)
At this point, the secondary is considered the production database and the primary is considered the replica.
While secondary replication is occurring and the Replication server and agent are actively performing Replication, you must determine when the best time is to fail back production processing to the primary computer. When you begin failback processing, it is critical that no users be connected to either the primary or the secondary database. You can quickly ensure this by shutting down and restarting both databases. Once you verify that no users are connected to either database, you can start the failback process.
The following figure illustrates the scheduling of database downtime.
Figure 26. Scheduling downtime to perform failback
To initiate the failback process using transition failover, issue the following command on the second machine:
dsrutil secondary-db-name -C transition failover
This command instructs the secondary database to begin transition. The failover command modifier instructs OpenEdge Replication that this is a failover transition and causes Replication to transition both the primary and secondary databases.
When the transition process begins, the Replication server informs the Replication agent on the primary machine to begin preparing the primary database for transition. At this point, the secondary database is shut down and then restarted.
Once the startup synchronization process is complete, the actual transition process can begin, as shown in the following figure.
Figure 27. Initiating transition of the primary database
Once the startup synchronization process completes normally, the transition of the primary database is performed as configured, as shown in the following figure.
Figure 28. Continuing transition of the primary database
Once the transition of the primary database reaches a critical point (that is, immediately before the database is to be restarted), the transition of the secondary database is performed. Once the transition of the secondary database completes normally, the completion of the transition of the primary database is started.
Once transition completes normally for both databases, the databases will be restarted in their new roles, as shown in the following figure.
Figure 29. Databases started in new roles
As shown in the following figure, the roles of both databases have been reversed. The primary database is again the production database and the secondary database is again the replica. Primary replication is again being performed as it was before the initial failure occurred. The Replication server is replicating all primary transactions to the secondary database.
Figure 30. Primary replication activity is occurring