How OpenEdge Replication works with a replication set

Adding a Replication Set, to an OpenEdge Replication configuration, changes the failover activity. The biggest benefit of a Replication Set is the ability to transition all available databases together. The goal of the Replication Set is to minimize the risk of a single point of failure and the need to rebase.

With a Replication Set, if a Replication agent loses communication contact with the Replication server (for example, if the primary machine were to shut down unexpectedly), you can move all database update activity from the source database one of the target databases, and the other target becomes an agent to the new source.

Once the primary machine becomes available again, you can move all the database update activity to the primary database or machine. To minimize downtime to your application, you can schedule the failback process to run when you want.

An additional benefit of the Replication Set, is continued replication during planned downtime. For example, you can manually transition your Replication Set with the dsrutil transition failover command, and perform maintenance on the primary machine. The activities are moved to the secondary machine (formerly a target, but now the source). At this point, the primary machine can be shut down for maintenance, and later brought back online. When back online, the database on the primary machine can be synchronized with the new source. At the same time, replication is still running to the other target, preventing replication from a single point of failure.

The overall steps in the OpenEdge Replication process are as follows:

1. During primary (normal) replication, the primary database has the role of source database and the secondary database has the role of target database. The Replication server exists on the source database and the Replication agent exists on the target database.

2. If there is a failure on the machine hosting the primary database, the Replication agent on the target database loses communication contact with the source database's Replication server.

4. Transition then occurs (automatically or manually, depending on how you set the transition properties), making the secondary database (formerly a target) a source database.

5. All database activity is moved to the secondary database, which is now functioning as a source database. The secondary database now becomes the production database.