Blog

Replication Topology 102 - Peer to Peer (Meshed) exposed


Tags :


Prerequisite: You must have completed Replication Topology 101 - the basics (which was done in July)  before completing this course.

Sorry for the delay, but other posts were taking precedence. So let's get right to it.

One of the dilemmas when building out the infrastructure is how to start the replication topology after you break away from just one server. Let us not debate why someone does not have a cluster, just live with the fact that plenty of sites out there still have a single server.  When there is two servers, it should be obvious.  One calls the other and it is done.  Add a third to the mix and decision making seems to evaporate faster than spilled drinks in Las Vegas right now.  For some reason, some admins find it necessary to create a replication connection from one to every other server over and over (Please note the spaghetti reference from class 101).  Instead of planning a hub architecture right from that point, the confusion begins.

The good part of this topology is that there is no dependence on a hub server in case of failure.  If you have 3 servers with all these connections, and one fails, 66% are then still in sync waiting for the third to come back on-line.  Awesome idea.  You do not eliminate everyone having current data with a failure.

Yet, most admins want the data to replicate every few minutes all day long.  Amazingly at the same exact start and end times with the same interval in each connection document.  This leads into two things:

  1. Large possibility of replication/save conflicts as data access and updates take place.  If this application needs that much replication, you can bet it is getting updated regularly and by numerous people.
  2. This is like the 1¢ slots, you play those, soon the 5¢, then 25¢, then 1$.  Soon you are betting large on the roulette table that you make document 1 get to server C cleanly and in some timely fashion.

SO what does all this get us.  Peer to peer almost works for two servers, yet calling each other back to back doesn't really make sense.  So start thinking about which should be the hub and plan accordingly.