How Replication of Data Occurs
Replication of data is carried out by the sequence of tasks performed by the Change Recorder, Distribution Threads, and Replicator Server.
Whenever a database table registered for replication is manipulated, the replication of that table is executed as shown in the following diagram, starting with #1:
The steps in the previous diagram are as follows:
1. A user updates the local database through the local DBMS Server.
2. The Change Recorder updates the shadow table.
3. The Change Recorder updates the archive table.
4. The Change Recorder adds a row to the input queue.
5. After a commit, the distribution threads read the input queue and the propagation paths table to determine whether and to where the replication needs distributing.
6. The distribution threads update the distribution queue with the replication and its destination information.
7. The distribution threads delete the replication from the input queue.
8. The distribution threads alert an active Replicator Server.
9. Replicator Server reads the distribution queue.
10. Replicator Server updates the remote database using remote SQL or database procedures.
11. If the remote database is a full peer or protected read-only target, the Replicator Server updates the corresponding shadow table.
12. If the remote database is a full peer target, the Replicator Server updates the corresponding archive table.
13. If the remote database is a full per target, a row is added to the remote input queue.
14. The appropriate row is deleted from the local database’s distribution queue.
The Replicator Server deletes the corresponding rows from the local distribution queue.
15. The changes at the remote and local databases are secured using two-phase commit.
How Two-phase Commit Works
Ingres Replicator uses a two-phase commit protocol to ensure the integrity of the distributed, replicated data. The term two-phase commit refers to the two phases required to commit a distributed transaction where two databases are updated. Unlike Ingres Star, Ingres Replicator updates only two databases at a time.
Two-phase commit occurs during the last step in the diagram in How Replication of Data Occurs.
Note: The two-phase commit protocols are not used on the target connection; therefore, the transaction is not left in its installation log file.
Two-phase commit during replication involves the following steps:
1. The Replicator Server sends the replication to a target DBMS server.
2. The Replicator Server prepares to commit the transaction between the local and the target databases.
3. If Step 2 is successful, the Replicator Server completes committing the transaction at the target and local databases.
If an interruption occurs during the two-phase commit (for example, a machine or database shutdown), it is possible that a willing-to-commit transaction can be left on the Transaction Log File of the source database. To clear the willing-to-commit transaction, you can restart the Replicator Servers. If this fails to remove the willing-to-commit transaction from the Transaction Log File, you need to use the lartool utility. For more information, see the Command Reference Guide.
Note: Two-phase commit is not available for installations running the Ingres Cluster Solution. For more information, see the appendix “Cluster Support.”
Last modified date: 11/28/2023