When designing a replication topology, you’ll need to decide how synchronization is initiated and which replica set member initiates it. In simple applications, a single replica might be selected as the member that initiates and controls synchronization. This replica is called the controlling replica. For example, in a simple star topology, the replica on the hub workstation might control all synchronization that occurs between members of the replica set. It is possible for a single replica to control all synchronization because the two databases specified in the DAO Synchronize method can be any two replicable databases in the same replica set.
Having a single controlling replica has the primary advantage of simplicity and ease of programming. However, if you are using a single controlling replica and that replica is damaged or unavailable, synchronization cannot occur. This design is suitable for applications where the reliability of replication is not a critical element of the application’s operation.
In some applications, the reliability of replication is critical. To increase reliability in these cases, you might want to design your replication topology so that more than one replica can control synchronization. There are several ways to do this. For example, your replication code could run on more than one replica, each of which periodically verifies whether the “default” controlling replica is available. One way to do this is to have a replica use the OpenDatabase method to see if the controlling replica and its computer are available. If the default controlling replica is unavailable, one of the other replicas could assume control.
A second way of determining if the controlling replica is available is to have the controlling replica maintain a log of all synchronizations that occur. Periodically, other replicas check the log to verify that a scheduled synchronization has occurred. If a synchronization does not appear in the log, one of the replicas temporarily promotes itself to the status of controlling replica and initiates the synchronization process. For safety, you should replicate the log so you have a backup in case the log for the controlling replica becomes unusable.
Another way to provide redundancy is to always have more than one controlling replica that performs synchronizations. This is the case with the fully connected topology, in which every replica is by definition a controlling replica. Although this can produce significant overhead, it is more reliable.
Note Because so many different factors are involved, it is difficult to predict which topology will be the best solution for a specific application. You might want to experiment with a few different topologies in your replication scheme to determine which one produces the best results.