Standard XDCR topology?

Couchbase Server
1

I know that XCDR has a lot of setup/tuning options, and I have read the documentation. But still have a couple questions…

  • If I configure all my clusters (say 5) to all talk to each other, will XDCR just “do the right thing” for efficient document sync? So if I update a doc on Cluster1, that change will flow to 2,3,4,5, and then will NOT flow from 2 to 3, because 3 already has the new data?

  • If I want all my clusters to be in sync, is the above the “standard” topology – just let all clusters talk to each other?

TIA,
Chuck

2

@chuck.connell,
regarding-1 the answer is yes. with XDCR topology set up to take all the writes from 1 to 2,3,4 and 5, XDCR will replicate the correct changes and ignore replication if the data is up to date.

regarding-2 you can either form a ring (1-2-3-4-5-1 and so on) or you can do a star (1-2, 1-3, 1-4, 1-5, 2-1, 2-3, 2-4 and so on) Star can be chatty if you have a lot of updates but will have a lower latency replicating the changes to all clusters and ring can be efficient in replicating but will have a higher latency.
thanks
-cihan

3

#1 – Thanks. That’s what I was hoping for.

#2 – Why not just set up XDCR from every cluster to every other cluster? Wouldn’t that result in minimal latency for a data change to reach all nodes, and also minimum chatter, since there would be no intermediate hops to move data?

4

on #2 yes you are right. it just gets harder to add a remove new clusters. Star topology also would be a very tough one under 10-20 clusters. if you think 5 is your number, you can certainly do star
thanks
-cihan

5

thanks. good point about how this gets harder with many nodes.

6

@cihangirb : when i was talking with Couchbase Solution architect , he recommended ring topology for 3 clusters , but according to you star is best . which one should i consider now ?

7

Chances are, you got more specific advice from the Couchbase Solutions Architect based on your specific context. As laid out above, you can end up in a situation with a star topology where one cluster is very chatty having to talk to all of the others, where ring ensures each cluster is only talking to two others.

Three clusters is a bit of a specific situation where there really isn’t a star yet, so it’s actually the same for whichever cluster is at the center in work as it would be if it were in a ring.

I don’t have the full context, but if it were me I’d probably want to trend things out thinking about the tradeoff between having a lot of resources at the center or having higher latencies. And, the nice thing is if starting with 3 clusters, you can build a ring and remove configured replications later to move to a star topology. Try drawing out a few of the topologies and you’ll see what I mean.

1 Like
8

@ingenthr Hi Matt,

If all clusters talk to each other, it is actually mesh topology (and not star topology). Can you pls confirm if that is supported with Couchbase XDCR?

Also, after 1 replicates to 2 & 3; same change will be replicated from 2 to 3. But, on 3, it will not result in any change since the data is same as received from 1. And hence 3 will not send it to 1. Is the understanding correct?