Q replication is a high-volume, low-latency replication solution that uses WebSphere® MQ message queues to transmit transactions between source and target databases or subsystems.
This type of replication offers several advantages, as follows:
- Minimum latency
Changes are sent as soon as they are committed at the source and read from the log.
- High-volume throughput
The Q Capture program can keep up with rapid changes at the source, and the multi-threaded Q Apply program can keep up with the speed of the communication channel.
- Minimum network traffic
Messages are sent using a compact format, and data-sending options allow one to transmit the minimum amount of data.
The use of message queues allows the Q Apply program to receive transactions without having to connect to the source database or subsystem. Both the Q Capture and Q Apply programs operate independently of each other—neither one requires the other to be operating. Of course, changes cannot be replicated unless they are captured by the Q Capture program and written to the message queues and retrieved and applied to the target by the Q Apply program. If either of the replication programs is stopped, messages remain on queues to be processed whenever the program is ready. Because the messages are persistent, the source and target remain synchronized even in the event of a system or device failure.
Q replication supports three types of replication configurations that are characterized by how conflicts are detected and resolved:
- Unidirectional replication: Key value detection; no automatic conflict resolution.
- Bidirectional replication: Value detection (key value, all values in the row, or only changed values); resolution by designed winner. This configuration allows tree topologies (two or more nodes) and "hub-and-spokes" for data distribution to tens of servers.
- Peer-to-peer replication: Version detection (time and origin of change); resolution by latest-change-wins, regardless of origin and arrival time of the change. This topology requires each server to be connected to all other servers (2 to 5 servers is a maximum practical number of servers).
You can find more information in the Q Replication Information Roadmap: