Bidirectional replication

Bidirectional replication has the following characteristics:

• Applications on either server can update the same rows in those tables at the same time. However, there is little or no potential for the same data in the replicated tables to be updated simultaneously by both servers. Either the same row is updated by one server at a time, or one server updates only certain columns or rows of your data, and the other server updates different columns or rows.
• You can choose which copy of the table wins if a conflict occurs.

The collection of both copies of a single table is called a logical table. Each server has a copy of the table. The different versions of the table can have different names and schemas.

You can use the replication administration tools to specify which columns from the logical table you want to include or exclude from the Q subscriptions for the table. The columns in each copy of the table that are included in Q subscriptions must have identical names and compatible data types. Source columns that are part of a primary key or unique index should not be excluded and should be part of the key that is used for replication (IS_KEY in the IBMQREP_SRC_COLS and IBMQREP_TRG_COLS control tables).

In this type of replication, you cannot manipulate the data by having the Q Apply program pass the data to a stored procedure. There is at least one Q Capture program and one Q Apply program running on each server that is part of a bidirectional configuration.

Replication objects for bidirectional replication

Figure 1 shows bidirectional replication of one logical table between two servers. For one logical table, you need two Q subscriptions and two replication queue maps.

Figure 1. Q subscriptions between two copies of a table for bidirectional replication. Changes are replicated from each copy of the table to the other copy of that table over WebSphere MQ queues.

Conflict detection in bidirectional replication

In bidirectional replication, it is possible for data that is replicated from the source table in one Q subscription to conflict with changes made to the corresponding target table by an application other than the Q Apply program. Bidirectional replication uses data values to detect and resolve conflicts. You can choose which data values are used to detect conflicts. These data values can be key column values only, changed column values, or all column values.

For example, imagine a scenario in which applications on one system make changes to tables in a server (SERVER_RED) and that server replicates those changes to identical tables in a server (SERVER_GREEN) on a standby system. The first system fails, at which time your applications start using the tables on SERVER_GREEN. When the first system comes back online, you want to replicate changes from SERVER_GREEN to SERVER_RED. However, when the first system shut down, it could have failed to replicate some data to the second system. That data, which is now old, should be replaced by the data replicated from SERVER_GREEN. When you replicate the new data, the Q Apply program for SERVER_RED recognizes the conflicts and forces the changes that come from SERVER_GREEN to SERVER_RED.

You can choose how the Q Apply programs on both servers check for conflicts when they try to apply data to both copies of the table and what actions those programs should take if they detect conflicts. The choices that you make for conflict rules and conflict actions are critical decisions because they affect the behavior of how rows are applied.