Replication Topology 104 - Ring
Prerequisite: You must have completed Replication Topology 101 - the basics (which was done in July) and 102 and 103 now also before completing this course. :-) I know I have taken my time on these but I find too many other things come up, plus it keeps you waiting for the next one.
Here is what I said about the Ring topology:
Simple enough, servers
call each other in a circle updating, adding and deleting as it goes. The
downside relies on a large ring where it can take some time to get all
the way around. Also, if one server in the ring goes down, so goes
As we do in each entry, we do a good side/bad side of this decision. Then it is up to you to compare and modify yours as we go through each one from class 101
The good: This one is easy to implement and reduces the amount of connection records necessary. Since you only need one record for the next hop, you only have as many replication connection docs as you do servers. Simplicity. If data does not need to be in total synchronization all the time, this is a beginner cycle that small companies embark on sometimes. But what happens when you get too big or need that data more in time? Reducing the cycle time is great, but you are still playing with fire.
The bad: It turns ugly here. Timeliness is the issue on the data. Multiple people possibly working on the same document across multiple servers comes into play for replication and save conflicts. It is more than possible that a database that resides on servers, lets say in 5 offices, has customer information updates. Then as it cycle around, who is right, what data is the newest? Now we have phone calls and emails trying to figure that out.
The loss of a server in the cycle for whatever reason (crash, network outage, backups) causes only servers on the last hop before that server to be in sync. The server before the dead one can never send the updates to the servers on the other side of the chasm. Ouch!
Just picture when you were a kid and you played that game where you whisper in your neighbor's ear, then he passes it on to her and so on around the room until it gets back. The outcome is normally a screwed up story. Domino will keep that data in sync, no fear, but what happens when one of the kids leaves to go to the bathroom and never returns, think they will know where the story is tomorrow? Nope, becaused someone else changed it along the way. Or worse yet, it just stops midway around and never gets back to you.
So strike #3 with this topology design