|
|
|
This section provides an overview of how Ingres Replicator components work together to process a replication from one database to another. This description is intended to provide the background necessary to maintain and troubleshoot Ingres Replicator. It discusses full peer to full peer or full peer to protected read-only configurations, and assumes that there are no collisions.
Ingres Replicator consists of three distinct components that participate in the actual replication of data:
The Change Recorder is a DBMS Server component that captures information about each update to a replicated table as part of the user transaction. The Change Recorder inserts a row in the shadow table and, if necessary, in the archive table, for each base table row manipulated by the user. It also adds an entry to the input queue for each such row.
When the user commits the transaction, a distribution thread in the DBMS Server reads the input queue and for each input row and destination, it inserts an entry into the distribution queue. The input rows are deleted and the Replicator Server is alerted.
The Replicator Server is a separate process that reads the distribution queue and propagates each distribution queue row to the corresponding target. At the end of each set of rows comprising a user transaction, the distribution rows are deleted and two phase commit is used to secure the transmitted transaction.
In addition, Ingres Replicator includes a management component—either Visual DBA or the Replicator Manager, plus additional utilities that provide operational support.
|
|
|
The Change Recorder is responsible for recording all changes made to base tables registered for replication. The recording process is accomplished internally in the DBMS, which automatically performs work on behalf of the user. The DBMS manipulates support tables to maintain a history of replicated transactions and a queue of transactions that need to be distributed by the distribution threads. This queue is known as the input queue. The data contained in the support tables is also used for collision resolution.
|
|
|
When a user makes a change in a table that has been registered for replication, the Change Recorder function is activated and the following process begins:
If the change is an insert, the shadow record for this new replicated transaction key contains zeros for the previous replicated transaction key. If the change is an update or delete, the shadow record for this new replicated transaction key contains the replicated transaction key for the previous replication transaction for this row.
In this way the shadow and archive tables provide the sequential history of every replicated row.
The input queue contains the information necessary to complete the replication, except the destinations.
The following figure illustrates the tasks of the Change Recorder:
|
|
|
The distribution threads put the destination address on the replication that needs to be propagated. The distribution threads work in parallel to clear the input queue.
The distribution threads work within the DBMS Server to take the information from the input queue and expand it to fully specify what data needs to be replicated to which targets. The expanded information is stored in the distribution queue. The distribution threads do not perform any replication; they merely prepare data for replication by the Replicator Server. However, no data is expanded to the distribution queue if the threads are not configured. There can be a number of threads in each DBMS Server.
|
|
|
The distribution thread performs the following tasks:
The number of rows a distribution thread inserts into the distribution queue per replication is equal to the number of targets that you have defined for that replication's Consistent Distributed Data Set (CDDS). Each row contains the information from the input queue plus the destination information.
The following figure illustrates the tasks of the distribution thread:
|
|
|
The Replicator Server is a stand-alone process that sends changes prepared by the distribution threads to their respective targets. Once the transaction has been transmitted, the replications are secured on the target database and are removed from the distribution queue. The Replicator Server also detects and resolves collisions.
|
|
|
After the distribution threads alert it, the Replicator Server completes the following tasks:
The Replicator Server also performs tasks such as checking the status of its Ingres Net connections. The following figure illustrates the tasks of the Replicator Server:
|
|
|
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:
The Replicator Server deletes the corresponding rows from the local distribution queue.
|
|
|
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 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:
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."
|
|
|
Management and configuration tasks for Ingres Replicator can be performed using either Visual DBA or the Replicator Manager.
Monitoring tasks for Ingres Replicator can be performed using either Visual DBA or Visual Performance Monitor. As the smaller and simpler tool, Visual Performance Monitor is preferred.
Windows and UNIX:
Visual DBA provides a visual user interface for performing most Ingres Replicator management functions, including creating system catalogs and configuring a replication scheme—defining the replication scenario, registering tables for replication, and moving the replication configuration to the target databases. Visual DBA provides several reports about your replication scheme, and it allows you to monitor and control server activity.
Visual Performance Monitor provides a visual user interface for monitoring most replication aspects including replication activity, Replicator Server status, raising database events for all Replicator Servers or an individual server, replication collisions, table integrity and replication configuration consistency between databases. 
The Replicator Manager is a forms-based management tool used to configure your replication scheme, monitor replication activity, and report on the replication configuration. Configuring a replication scheme includes defining the replication scenario, registering tables for replication, and moving the replication configuration to the target databases. Replicator Manager provides several reports that can assist you to monitor and control server activity.
Ingres Replicator provides additional utilities that assist in the management of the replicated databases. These utilities are described in the Command Reference Guide.