[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-directory-users
Subject:    =?utf-8?q?=5B389-users=5D?= Re: Complex MMR scenarios
From:       thierry bordaz <tbordaz () redhat ! com>
Date:       2020-10-05 8:52:02
Message-ID: 70066b94-5c80-ae3b-79b9-1adf27c3a5fa () redhat ! com
[Download RAW message or body]



On 10/2/20 12:11 AM, William Brown wrote:
> 
> > On 1 Oct 2020, at 20:27, Eugen Lamers <eugen.lamers@br-automation.com> wrote:
> > 
> > Hi,
> > we want to setup a Multi Master Replication that represents a scenario with \
> > several mobile environments which need to replicate with some immobile server \
> > from time to time. Is it possible - and reasonable - to group the servers of a \
> > mobile environment together to a kind of sub-level MMR which replicates with the \
> > higher level MMR of the immobile environment. This replication between the \
> > different "levels" would be triggered somehow externally, because there would not \
> > always be a (sufficient) connection between them. This would represent some kind \
> > of combination of MMR and cascading replication. Is there someone with experience \
> > with such kind of scenarios? 
> I haven't heard of such a scenario but I'd ask "what are you trying to achieve" \
> rather than commenting on the design too much. 
> An early issue you will hit is that replication is *push* based, so the "immobile" \
> servers need to be continually updated to know where the "mobile" server is in \
> order to know how to contact it. It's not "pull" based where the moving server \
> could always access the static server. 
> Additionally, because it's "push" based, the sending server sets the schedule of \
> when to replicate. Certainly, there is a window of validity where a server can be \
> "caugh up" (the changelog max age parameter is how long a server can be \
> disconnected and still replicated to later to "update" it). Again, if this were \
> "pull" based, the mobile server could "choose" when to recieve it's update. 
> 
> But saying this, I think you have a problem space in mind, and while this may be a \
> solution, knowing more about the challenge you want to solve may help us give \
> better advice about how to configure your topology and potentially the integrating \
> applications. 
> Thanks,

My understanding is that some hosts may get temporary offline (mobile) 
while others are always online (immobile). Replication can manage with 
hosts being online-offline. With limitations how long the hosts are 
offline (by default a host should not be offline more than 7 days) and 
on the update rate if a host an not the capacity (#received updates) to 
catch up.

regards
theirry
> —
> Sincerely,
> 
> William Brown
> 
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: \
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: \
> https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: \
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org



[prev in list] [next in list] [prev in thread] [next in thread]