Q Replication and Event Publishing

Setting up multidirectional Q Replication

With Q Replication, you can replicate data back and forth between tables on two or more servers while applications update the identical copies of a table at all servers while keeping all copies of the table synchronized. This type of replication is known as multidirectional replication.

Bidirectional replication
In bidirectional replication, Changes that are made to one copy of a table are replicated to a second copy of that table, and changes that are made to the second copy are replicated back to the first copy.
Peer-to-peer replication
In peer-to-peer replication (also known as multimaster replication) updates on any one server are replicated to all other associated servers.
Bidirectional replication versus peer-to-peer replication
If you want to replicate data between tables on two servers, you have two choices for multidirectional replication: bidirectional replication or peer-to-peer replication.
Bidirectional replication versus peer-to-peer replication for high-availability scenarios
If you are configuring two servers for a high-availability scenario, then you might want to choose either bidirectional or peer-to-peer replication, depending on your business needs. Both types can be used in such a scenario.
Creating Q subscriptions for bidirectional replication
You can create Q subscriptions that specify what changes to capture from either of two tables, what queues to use for exchanging change messages, and how to process the messages. Changes to either of the two tables replicate to the other table.
Improving performance in bidirectional replication with the IBMQREP_IGNTRAN table
You can use the Q Capture program's ability to ignore specified transactions to improve performance in a pure, two-server bidirectional configuration.
Options for conflict detection (bidirectional replication)
The choices that you make for conflict rules and conflict actions affect the behavior of how rows are applied. The conflict rules determine how much of the data is checked to detect a conflict and the types of conflicts that are detected. When you choose to have more data checked for conflicts, then the Q Capture program must send more data to the Q Apply program to make that data available to be checked, which might influence performance and network traffic.
Creating Q subscriptions for peer-to-peer replication
You can create Q subscriptions to map peer tables to one another so that changes are replicated back and forth from each table. This task is part of the larger task of setting up replication from sources to targets (multidirectional).
Starting bidirectional or peer-to-peer replication with two servers
To start bidirectional or peer-to-peer replication with two servers, you start the Q Capture and Q Apply programs at both servers, and then make sure that Q subscriptions are activated.
Starting peer-to-peer replication with three or more servers
After you create the Q subscriptions for a logical table in peer-to-peer replication with three or more servers, you must start the group of Q subscriptions to start replication.
Stopping bidirectional or peer-to-peer replication with two servers
In bidirectional or peer-to-peer replication with two servers, you can stop replication of a logical table without stopping the Q Capture or Q Apply programs. To do so, you deactivate the Q subscriptions for the logical table. Replication of other logical tables continues between the two servers.
Stopping peer-to-peer replication with three or more servers
In peer-to-peer replication with three or more servers, you can stop replication of a logical table without stopping the Q Capture or Q Apply programs.

Parent topic: Creating Q subscriptions

Send your feedback | Information roadmap | The Q+SQL Replication Forum

Last updated: 2013-10-25