Replica synchronization in a family

Because information in a replicated Rational® ClearQuest® database is modified concurrently at different replicas, the contents of each replica in a family tend to differ. The contents of a particular replica may never be identical to the contents of any other replica. To keep the replicas from differing too much, each replica sends updates to one or more other replicas.

Information is exported from a replica in packets. A logical packet includes all the information required to create a new replica (replica-creation packet) or to update one or more existing replicas (update packet). For flexibility, and to accommodate limitations of data-transport facilities, each logical packet can be created as a set of physical packets.

After a logical packet is created with a mkreplica or syncreplica command invoked with the –export option and sent to a replica, it is processed at that replica by a mkreplica or syncreplica command invoked with the –import option. The changes that occurred originally at the sending replica (and perhaps at some other replicas, too) are added to the user database and schema repository of the importing replica. Updating a user database replica may change both its database and its schema repository to reflect the activity that has taken place in one or more other replicas. If the logical packet includes several physical packets, the import commands always process the physical packets in the correct order. No error occurs if the same packet is imported two or more times at a replica, unless the imports occur simultaneously.

The following figure illustrates the three phases of synchronization: export, transport, and import. At Site 1, a syncreplica –export command places records of operations from R1 into a packet. The packet is sent to Site 2. At Site 2, a syncreplica –import command imports the contents of the packet into R2. Each synchronization is one-way. If two replicas update each other, two synchronizations are required.

Figure 1. Replica synchronization

You can match the synchronization strategy for each family to its particular use patterns, your organization’s needs, and the level of connectivity among the host machines. For one family, you can update replicas every hour, using a high-speed network; for another family, you can send updates only once or twice a month, using electronic mail or disk files as the delivery mechanism.