UNDERSTANDING REPLICA SET TOPOLOGIES
Another concept introduced with replicated databases is the replica set topology. This refers to the distribution of replicas and the connections between them, and may be thought of as analogous to the topology of PCs on a LAN. The selection of an appropriate replica set topology is vital for the robust and efficient management of the synchronizations between replicas.
The singly connected list and star and hub topologies are analyzed in the following sections. Using replicas with local or anonymous visibility will enforce a star/hub topology because those replica visibilities can synchronize only with the parent (global) replica.
Singly Connected List
A very simple topology consisting of four replicas (Redmond, Paris, London, and Berlin) connected in a list:
Redmond can synchronize only with Paris
Paris can synchronize with Redmond and London
London can synchronize with Paris and Berlin
Berlin can synchronize only with London
Assume that replicas exchange on a daily schedule and, more importantly, the clocks in each computer at each location aren't synchronized. This means that Paris might exchange with London before exchanging with Redmond. Further, assume that this is also the situation with exchanges between London and Berlin. Therefore, if Redmond made some updates on Monday, these would reach Paris on Tuesday, London on Wednesday, and Berlin on Thursday.
A singly connected list has two potential disadvantages:
Latency (or delay) of update propagation can be significant.
A failure between any two replicas will prevent update propagation to replicas up- or downstream from the point of failure.
Star and Hub Topologies
Consider the same four replicas (Redmond, Paris, London, and Berlin) connected in a star and hub topology (see Figure 23.5).
Figure 23.5. With the star and hub replicas topology here, everything goes through Redmond.
Now, assume that the schedule is initiated at Redmond. Redmond exchanges with Paris, and then London, and then Berlin. Redmond immediately repeats the process, again exchanging with Paris, and then London, and then Berlin. All replicas are now up-to-date and consistent.
In general, a star and hub topology is an excellent choice, balancing robustness and efficiency without the burden of a complex scheduling algorithm and associated management, which is often the source of problems that are difficult to identify. Latency in update propagation can be easily controlled.