Database admins need to ensure their disaster recovery systems have the most up-to-date database changes so that in the event of a failure, recovery can occur quicker, and retain as much data as possible. Replication AI Streaming addresses this need.

Without Replication AI Streaming enabled, AI blocks are sent to the targets when they are generated, and are received by the agent and applied on the target databases. If AI data cannot be processed fast enough on the targets, it is queued on the source database machine. In the event of a source crash, this data can be lost and lead to data consistency issues on the targets.

To minimize the data loss caused by AI data queued on the source, Replication AI Streaming streams the AI blocks to the targets as they are generated. The agent on the target is multi-threaded to improve performance. Replication AI Streaming allows the targets to stay as close as possible to the source database because source AI data is hardened on the targets once it is received. Replication AI Streaming is also designed to reduce the latency as AI data is less likely to be queued on the source side (PICA). The following figure demonstrates how AI Streaming works.

Streaming Replication Architecture

The Replication server sends AI data to the target as described in the OpenEdge Replication and After-imaging topic, but the Replication agent caches the incoming AI blocks in the Replication Stream Block (RSB) Cache. The blocks are then read from the RSB cache and applied to the target. Database admins have the ability to observe the Replication AI Streaming operations in the replication log with logging-level set to 3 on the replication agent.

Replication AI Streaming is enabled by default in OpenEdge. The sections that follow contain descriptions of how to configure your Replication Agent property file and how to observe the Replication AI Streaming operations in the Replication Monitor and through VSTs.