WebSphere Information Integrator Q Replication: Fast Track Implementation Scenarios

Chapter 5. Bidirectional Q replication on AIX platforms 421

the hot site available for read-only access for reporting purposes to offload

processing from the primary server.

These requirements may be summarized as follows:

򐂰 Maintain a non-dedicated hot site backup. This means that the hot site

backup server has actively updated application tables unrelated to the

financial data application.

򐂰 Replicated tables on the second server must be available for switchover

within 30 minutes.

򐂰 Replicated tables on the second server must be available for read-only

access while the primary server is available.

򐂰 The primary server is to be resynchronized with the secondary after it is

restored to service.

򐂰 Limited resources allowed for replication-only purposes.

5.3 Rationale for the bidirectional solution

Table 2-1 on page 39 lists the evaluation criteria for choosing between

unidirectional, bidirectional, and peer-to-peer replication topologies.

Since Corona’s business requirement is support for a single backup site, the

choice is between a bidirectional and peer-to-peer replication topology.

The bidirectional replication topology is appropriate for Corona for the following

reasons:

򐂰 Less stringent requirements for switchover time (within 30 minutes instead of

an instantaneous requirement, which would tilt in favor of peer-to-peer).

򐂰 Non-dedicated backup server requirement.

򐂰 Absence of conflicts

1

due to the lack of simultaneous updates—only one

server is updated at a given time.

򐂰 Limited computing resources available.

򐂰 As discussed in 2.3, “Choosing a particular Q replication topology” on

page 39, when multiple topologies can address a business requirement, it

would probably be appropriate to choose the topology that is least expensive

and has the minimal impact on existing data. Bidirectional is the lower cost

1

During switchback, there is likely to be some data loss and conflicts due to the fact that all the

changes on the primary server at the time of failure fail to get replicated over to the secondary server.

These conditions are resolved partially by the conflict resolution mechanism during switchback, and

may require manual intervention.