Chapter 4. Peer-to-peer Q replication on z/OS platforms 297
When a server fails, there must be no outage perceived by the user, since the
the remaining server must take over the workload of the failing server
transparently and instantaneously.
Replicated tables on both servers are peers, and updates may occur at either
server—there is no concept of primary or secondary server.
Update conflicts on the two servers must be resolved in favor of the most
Failing server must be resynchronized with the active server after it is
restored to service.
4.3 Rationale for the peer-to-peer solution
Table 2-1 on page 39 lists the evaluation criteria for choosing between
unidirectional, bidirectional, and peer-to-peer replication topologies.
Since Carthage’s business requirement is support for a high-availability peer
environment, the choice is a peer-to-peer replication topology.
The peer-to-peer replication topology is appropriate for Carthage for the following
1. Totally transparent and instantaneous takeover in the event of failure of any
server (in seconds).
2. Expected conflicts
due to simultaneous updates to be resolved in favor of the
most recent update.
3. Adequate computing resources available since either server is meant to pick
up the workload of the failing server.
Carthage’s requirement for a controlled switchback to the failing server from the
active server is handled well by a peer-to-peer replication topology.
4.4 Environment configuration
Figure 4-1 shows the configuration used in the Carthage peer-to-peer replication
During switchback, there is likely to be some data loss and conflicts due to the fact that all the
changes on the failing server at the time of failure fail to get replicated over to the active server.
These conditions are resolved partially by the conflict resolution mechanism during switchback, and
may require manual intervention.