Query on the hub & spoke model

Couchbase Server
1

Hello,

We are planning for a hub & spoke model.

Application will connect to the hub and make changes. Those changes will be propagated to the spokes by way of uni-directional XDCR. To have HA for the hubs, we are planning to have 2 hubs with bi-directional XDCR between the 2 hubs. Now what is perplexing me is: should both hubs send changes to the spokes?

If yes, then there is duplicate replication from hub to spoke and that is sub-optimal.

If no, i.e. only one hub replicates to the spokes, then the challenge is that when that hub is down, it will need manual intervention to configure XDCR from the other hub to the spokes.

Is there a way to inform/configure XDCR such that if a hub receives changes from other hub then those should not replicate to the spokes but if it receives changes from the application then those should be replicated to the spokes. If yes, then we can configure uni-directional replication from both hubs to the spokes and the hub that receives changes from the application will replicate those changes to the other hub as well to the spokes whereas the other hub will not replicate those changes to the spokes. If the hub receiving changes from application goes down, other hub starts receiving changes from the application and it starts replicating those to the spokes as well to the other hub.

Thanks

2

It may be duplicate replication from a second hub to the spokes, but XDCR conflict resolution detection for documents above the optimistic threshold size that will save bandwidth of actually replicating the document if it’s necessary.

XDCR has no way to detect whether or not a change comes from a hub or an application.

So in your case, having both hubs replicating to the spokes may be a good option if you don’t want to have downtime if a hub goes down as the other hub will become the sole source for all the spokes in that case without needing manual intervention. In the meantime, all normal mutations will take place between the hubs, and one of the hubs will win when writing to the spokes.

3

Yes, am aware of the replication threshold but was thinking if there was a way to avoid even that (256 bytes) of unnecessary chattering and the cpu usage.

Thanks