WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios

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

recent update.

򐂰 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

reasons:

1. Totally transparent and instantaneous takeover in the event of failure of any

server (in seconds).

2. Expected conflicts

1

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

topology.

1

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.