Replication Topology 104 - Ring
Tags :Replication
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
the cycle
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
blog comments powered by Disqus
On Monday, October 17th, 2005 by Chris Miller
