Release 10.1B: OpenEdge Replication
User Guide


Step 9: The Replication failback process

You can perform OpenEdge Replication failback production processing to the primary computer by using either of the following methods:

Failback processing using transition failover

When secondary replication is being performed, as shown in Figure 4–13, both databases are up and running and all secondary transactions are being replicated to the primary database.

Figure 4–13: 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.

Figure 4–14 illustrates the scheduling of database downtime.

Figure 4–14: Scheduling downtime to perform failback

To initiate the failback process using transition failover, issue the following command on the second machine:

dsrutil secondary -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 Figure 4–15.

Figure 4–15: Transitioning the primary database

Once the startup synchronization process completes normally, the transition of the primary database is performed as configured, as shown in Figure 4–16.

Figure 4–16: Transitioning 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 Figure 4–17.

Figure 4–17: Databases started in new roles

As shown in Figure 4–18, 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 4–18: Primary replication activity is occurring

Using transition failover to perform failback: advantages and disadvantages

There are both advantages and disadvantages to using transition failover in failback processing.

The advantages are as follows:

The disadvantages are as follows:

A solution to the potentially lengthy downtime in the event of a transition failure involves performing failback by using controlled transition. Note, however, that this process requires a greater level of DBA intervention and access to both the primary and secondary machines.

Failback processing using controlled transition

When secondary replication is being performed, as shown in Figure 4–19, both databases are up and running and all secondary transactions are being replicated to the primary database.

Figure 4–19: Secondary replication continues (before controlled transition)

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.

Figure 4–20 illustrates the scheduling of database downtime.

Figure 4–20: Scheduling downtime to perform failback

When you begin failback processing, it is critical that no users be connected to either the primary or the secondary database. Both databases must be shut down to transition them.

It is recommended that the transition configuration for both the primary and the secondary databases be checked and modified if needed at this time.

Do not restart the databases after transition, so that you can perform special actions in the event of a transition failure. Once you verify that no users are connected to either database, you can start the failback process.

To initiate the failback process using controlled transition:

  1. Shut down and restart both databases. Doing so ensures that all source activity is flushed and, in turn, replicated to the target database.
  2. Verify the synchronization of the databases by either:
    • Examining the database log file.
    • Using the following command:
    • dsrutil source -C status -detail 
      

      When a status of 3049 is returned, both databases are synchronized.

  3. Shut down the databases again.
  4. Issue the following command on the primary machine:
  5. dsrutil primary -C transition 
    

    This command transitions the primary database into a source, as shown:

    If the transition fails, you can restart the secondary database to allow production work to continue. You can then attempt the failback operation again when you can once more schedule downtime.

    After the transition of the primary database to source database completes, transition of the secondary database can begin.

  6. On the secondary machine, issue the following command to transition the secondary database to a target database:
  7. dsrutil secondary -C transition 
    

    If the transition of the secondary database fails, you can start the primary database as the source database. This allows production activity again to proceed normally.

    If a transition failure does occur and you do start the primary database, you must still complete the transition of this secondary database to the role of a target database. You can do this by again executing the command provided earlier in this step.

    After the command completes normally, the transition of the secondary database to target is complete, as shown:

    At this point the roles that both databases had during secondary replication have been reversed:

    • The primary database is again the production database.
    • 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, as shown in Figure 4–21.

Figure 4–21: Primary replication activity resumes

Performing failback with controlled transition: advantages and disadvantages

There are both advantages and disadvantages to this method of failback processing.

The advantages are as follows:

The disadvantages are as follows:


Copyright © 2006 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095