Hi Just wanted to double check; We have not created replication agreements between all masters and in some instances it might take 2 hops for a change to be replicated everywhere. We are happy with this trade-off in delay for simplicity. Are we breaking some cardinal rule regarding multi-master or is this acceptable? The idea is to have edge servers in each DC that speaks to other DC edge servers and internally things are more verbal.
A simplified attempt at a diagram. changes in dc1master02 will take two replications before it reaches dc2master02
dc1 dc2 master02 <-> master01 <-> master01 <-> master02
This question pertains both to a shared NetscapeRootDB and userDB databases.
Best Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
Gerrard Geldenhuis wrote:
Hi Just wanted to double check; We have not created replication agreements between all masters and in some instances it might take 2 hops for a change to be replicated everywhere. We are happy with this trade-off in delay for simplicity. Are we breaking some cardinal rule regarding multi-master or is this acceptable? The idea is to have edge servers in each DC that speaks to other DC edge servers and internally things are more verbal.
A simplified attempt at a diagram. changes in dc1master02 will take two replications before it reaches dc2master02
dc1 dc2 master02 <-> master01 <-> master01 <-> master02
This question pertains both to a shared NetscapeRootDB and userDB databases.
This is fine. You don't have to have all masters connected directly to all other masters. Daisy chain, hub-n-spoke, and other topologies are acceptable.
Best Regards
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org