Q Replication and Event Publishing Q Replication and Event PublishingWhen you use multiple receive queues to replicate a workload, you can synchronize the apply process across receive queues to ensure that a time-consistent point can be restored, even if data is lost for one of the queues, before switching the workload to a standby site for unplanned outages.
This function is useful only for disaster recovery and only if you use more than one receive queue to replicate the tables that need to be recovered.
At the highest level, synchronizing one or more Q Apply programs across multiple receive queues involves two concepts:
You define a multiple consistency group name and assign the group to a set of queue maps by using the ASNCLP command-line program. When the queue maps share a common multiple consistency group name, you can enable synchronized apply across the receive queues. The synchronization can be dynamically turned on and off.
When you enable synchronized apply, you can:
IBM® GDPS® active/active continuous availability supports multiple consistency groups for a workload and exploits the synchronized apply function that is provided by Q Replication. All GDPS operations on a workload are carried out for each consistency group that is processing the workload. For example, a STOP REPLICATION command for a workload operates on all replication queue maps (consistency groups) that are used for replicating the tables that are modified by the workload.
The following sections provide more detail about synchronized apply processing:
Messages from the Q Capture program that contain replicated data also include the log sequence number (LSN) of the DB2® commit at the source expressed in UTC (Universal Time Coordinate, also referred to as GMT or Greenwich Mean Time). The Q Apply browser thread, which processes messages from a receive queue, reads ahead transactions until its memory fills. The browser thread then reports the maximum DB2 commit LSN that is available in the receive queue to all other Q Apply programs that participate in the multiple consistency group.
The maximum commit point for each consistency group is stored in the ASN.IBMQREP_MCGSYNC control table. One such table exists per data-sharing group. Each Q Apply program in a group then uses the ASN.IBMQREP_MCGSYNC table to determine if data can safely be applied.
Each Q Apply program applies transactions up to the DB2 source commit LSN that is available for all consistency groups. Meanwhile, the Q Apply programs continue to read ahead to find the next maximum commit LSN that is available.
When no changes are available to replicate from the source for the tables in a consistency group, the Q Capture program sends a heartbeat message that contains the last commit LSN that was detected in the DB2 log or the current time if Q Capture reached the end of the log. Heartbeat messages must be enabled in Q Capture to use apply synchronization; otherwise replication would be suspended when there are no transactions to replicate for any of the consistency groups.
By using this method, all Q Apply programs in a multiple consistency group are synchronized on a common source commit LSN sequence. Data is not applied unless timestamps are received on all receive queues for all Q Apply programs. Data is transaction-consistent on a common timestamp across all consistency groups for failover.
When you create a multiple consistency group, you can select between two modes of Q Apply synchronization:
You can set up apply synchronization by using the ASNCLP command-line program. You can use the MODIFY command to start and stop synchronization of the group and to purge messages from a receive queue after a disaster or for cleaning up your environment after testing a new replication configuration.
Defining a multiple consistency group name adds a row to the IBMQREP_MCGPARMS control table, where the synchronization mode and synchronization interval are also stored.
After you define a multiple consistency group, you assign a name to each individual consistency groups (each represented by a replication queue map) by using the ADD TO MCG keywords in the CREATE REPLQMAP command or ALTER REPLQMAP command. Adding a consistency group inserts a row into the IBMQREP_MCGSYNC table, sets the consistency group state to N (new), and adds the value for MCGNAME to the IBMQREP_SENDQUEUES and IBMQREP_RECVQUEUES tables, which store options for replication queue maps.
You can use the mcgsyncoff command to stop synchronization for an individual consistency group.
Another MODIFY subcommand, purgeq, can be used for purging stranded messages from a receive queue after a disaster, or for cleaning up a test environment.
A new control table, IBMQREP_MCGMON, records a history of synchronization delays and status for the individual consistency groups. Each Q Apply program has its own IBMQREP_MCGMON table and updates it at an interval that is specified by the Q Apply monitor_interval parameter (this same parameter controls the update interval for the IBMQREP_APPLYMON table).
In addition, columns are added to the IBMQREP_APPLYMON table to help identify the cause of any delays for a single consistency group. For example, you can determine whether the group is delayed because it is waiting for data from other consistency groups to arrive at the target while running in synchronized mode, or because of DB2 performance issues at the target that might be caused by I/O or CPU delay, lock contention, or other factors.
The new columns help you break down Q Apply latency into multiple elements, which add up to the overall latency statistic, as the following formula shows:
APPLY_LATENCY = DEPENDENCY_DELAY + MCGSYNC_DELAY + WORKQ_WAIT_TIME + RETRY_TIME + DBMS_TIMEYou can use the Q Replication Dashboard to view the breakdown of Q Apply latency from the Queues tab. You can also view performance statistics in IBMQREP_MCGMON and IBMQREP_APPLYMON from the Control Tables and SQL tab, and use the statistics to generate performance graphs.
To use a Q Replication configuration that includes multiple consistency groups with GDPS active/active continuous availability, follow these guidelines:
