In the star topology (see Figure 7.2), a single hub periodically synchronizes with each of its satellite replicas. In this topology, all data is shared among replicas through a single, centralized database. The star topology reduces data latency time among members of the replica set because data has to travel at most two “hops” to synchronize with any other member of the set. If the average quantity of data to exchange during synchronization is relatively small, the star topology can be a fast and efficient solution.
One of the potential disadvantages of the star topology, however, is that the first replica associated with the hub does not receive any new data from the other replicas and the last replica receives all the new data from all the other replicas. To make sure that all satellites are properly synchronized, you must make two synchronization passes around the star.
A second potential disadvantage of the star is that the hub is involved with every synchronization and therefore must be able to handle a greater load than any of the replicas associated with it. As a result, the star topology has a practical limit to the number of satellite replicas it can support because so much activity is centered at the hub. An effective way of handling this is to create additional stars and connect their hubs. Or, you can place the hub on a dedicated high-end computer capable of handling a heavy load. However, if your application exchanges only a small amount of data with each synchronization, the hub might be able to support a relatively large number of workstations.
Another potential disadvantage of the star is that it contains a single point of failure — the hub. If the controlling replica is located at the hub, and the hub fails, synchronization cannot continue among any members of the replica set. This problem can be handled in code by reassigning the controlling replica.
If you use the star topology, consider locating the Design Master on a computer other than the hub. This has several advantages. First, you can better protect the Design Master by making it unavailable to users who have permission to modify the design of database objects. Second, you can modify the Design Master and test these modifications offline. This prevents a set of incomplete changes from being replicated to other workstations during synchronization. When you’ve completed your design modifications, you can synchronize with the hub, which in turn synchronizes with other members of the replica set.
The star topology is a good starting point for many applications. It is reasonably simple to implement and can be designed to be both efficient and reliable. If you’re implementing replication for the first time, the star topology is recommended. For more information, see the “Synchronizing the Star Topology” section later in this chapter.