Queued replication

AVEVA Historian uses queued replication in certain cases when streaming replication is not appropriate, such as when:

• The data stream is interrupted.
  For example, the remote IDAS configured for store-and-forward cannot communicate with the tier-1 Historian for a long time. When the connection is restored, the store-and-forward data finally arrives at the tier-1 Historian. But by that time, it may already be streaming newer data.

• Lower-tier Historian gets new data.
  For example, an insert, update, or CSV file import operation is performed for lower-tier tag values. This means the summaries should be recalculated for that time period, and then re-replicated to the next-tier Historian(s).

• The lower-tier Historian is stopped or restarted.
  For example, if the lower-tier Historian is restarted and there are some summaries spanning across the startup/shutdown time, they must be recalculated and re-replicated to the next-tier Historian(s).

When such cases occur, the Replication subsystem receives notifications from the manual data storage service. The notifications contain information about what kind of lower-tier tag data (original or latest) has changed for a particular time interval. The Replication subsystem places that notification record into the replication queue stored in the Runtime database of the lower-tier Historian. Later, when the connection to the next-tier Historian is restored, the Replication subsystem processes that queue by querying the lower-tier data and replicating it to the next-tier Historian(s). When the queue item is successfully processed, it is removed from the replication queue.

Although the Replication subsystem optimizes the queue by combining adjacent records, queued replication is slower and requires more system resources as compared to streamed replication, because it involves querying lower-tier data already stored on disk.

Queued replication does not support data values with timestamps before the year 1970.