Proaxima: OpenEdge Replication

OpenEdge Replication (formally Fathom High Availability Replication) is a mechanism that can be used to ensure that all database updates are seamlessly replicated to a secondary database. These updates are processed in order to achieve a very near real-time copy of the primary database.

In earlier versions of Progress the best way to maintain a Hot Standby database or have a secure method of recovery from a disaster was to enable AI. AI is a mechanism that records all the changes, as notes, of what happens to the database. These notes are written a, block at a time, to an AI file.

Previously (before replication) the method of maintaining a Hot Standby database meant periodically copying the AI files generated by the Database Broker to a secondary server and then applying (rolling) each file in turn against a target database.

This type of mechanism has a number of disadvantages.

The target database was always a little behind the source database. The exact time really depends on the frequency at which the AI files were copied over to secondary server and applied to the target database.
The copying of the AI files often places a surge on the network. The AI file would often only be managed somewhere between 15 minutes and 4 hours. Again depending of the size of the file, the impact on the source machine and network would differ from environment to environment.
Failing over to a Target database may mean rolling forward further AI files before the database could be used.
The target database has to remain offline while AI files were to be applied. Opening the database would change the timestamp of the database. After this time no more AI files could be applied. So unless a Read-Only connection was attempted the database would simply remain offline.

OpenEdge replication still uses the tried and tested journaling mechanisms of AI, but the difference is that Replication extends the AI process.

When a database is enabled as a source database for replication the database broker will start a separate process. The process is a replication server. The replication server plugs directly into shared memory. When a AI block is written out to the AI file an internal message is sent to the replication server. This message simply advises the replication server of the next AI block that needs to be sent to the target database. The replication server reads the AI block from the AI file and sends it over the wire to a replication agent.

A replication agent is a separate process that is started by the database broker when a database has been enabled as a target database. The agent receives the AI block that it is sent by the replication server. The block is then broken down in to the individual AI notes and each note is then applied to the database in order.

This approach of maintaining a Hot standby removes all the disadvantages previously found with the standard AI process.

Target database always a little behind. Even with replication there is a slight delay. Usually, if the source and target are synchronised and the network is available the difference between source and target database is a few seconds.
Copying of AI files puts a surge on resources. The data is now streamed to the target database so the sudden requirement to copy an AI file over the network disappears (unless you wish to archive AI files as well).
Failing over to the target database can be triggered an if near real-time replication has been occurring then there will be no further AI files to apply to the target database
The target database has to be served for the replication agent to be started. This means that the target database can be used for reporting purposes. The OpenEdge replication plus component has to be installed to take advantage of a read-only served database.