10:58 a.m.
Hi List,
I have a question regarding the cfg for a slave replication ldap server:
we have 2 DS cfg as master to master replication with only one acting as write DS at a
given time, now we have a business request to cfg the third ldap server but as slave (
only read).
I need to know if would be sufficient to cfg only one replication agreement from one of
the master DS to this new slave DS host will this be sufficient or need one agreement
for each one of the maste to slave ( 2 separate rep agreements) ?
thank you
Isabella
11:38 a.m.
On Tue, Oct 22, 2019 at 03:58:40PM +0000, Ghiurea, Isabella wrote:
Hi List,
I have a question regarding the cfg for a slave replication ldap
server:
we have 2 DS cfg as master to master replication with only one acting
as write DS at a given time, now we have a business request to cfg
the third ldap server but as slave ( only read).
I need to know if would be sufficient to cfg only one replication
agreement from one of the master DS to this new slave DS host will
this be sufficient or need one agreement for each one of the maste to
slave ( 2 separate rep agreements) ?
Hi Isabella,
It depends on a few factors.
- Connection quality between servers;
- A number of requests that you expect to go through;
Overall it is not required and the replication will work even with one
agreement.
If you'll provide more details about the topology we'll able to say more
about you'll benefit or not from 2 separate replication agreements.
Regards,
Simon
thank you
Isabella
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
noon
New subject: master to master replication cfg Q
On 10/22/19 12:38 PM, Simon Pichugin wrote:
On Tue, Oct 22, 2019 at 03:58:40PM +0000, Ghiurea, Isabella wrote:
> Hi List,
>
> I have a question regarding the cfg for a slave replication ldap
> server:
>
> we have 2 DS cfg as master to master replication with only one acting
> as write DS at a given time, now we have a business request to cfg
> the third ldap server but as slave ( only read).
>
> I need to know if would be sufficient to cfg only one replication
> agreement from one of the master DS to this new slave DS host will
> this be sufficient or need one agreement for each one of the maste to
> slave ( 2 separate rep agreements) ?
Hi Isabella,
It depends on a few factors.
- Connection quality between servers;
- A number of requests that you expect to go through;
Overall it is not required and the replication will work even with one
agreement.
Correct, one agreement will work, but now you have a single point of
failure. With only 3 replicas in your topology there is absolutely no
reason to only do one agreement to the read-only replica - just do two.
HTH,
Mark
If you'll provide more details about the topology we'll able to say more
about you'll benefit or not from 2 separate replication agreements.
Regards,
Simon
> thank you
>
> Isabella
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
--
389 Directory Server Development Team
1 p.m.
New subject: master to master replication cfg Q
Mark, SImon thank you for feedback!
The connections between master to master is good same location but the one from to new
DS slave on different location is poor, so this should imply to have 2agreements , also we
are using memberof pluging , for each master host the memberof is excluded from
replication ( cfg as fractional replication)
and for master to slave ( I assume member off will not be excluded will be full
replication)
Than would make sense to have only one master to slave full replication agreement?
6:17 p.m.
New subject: master to master replication cfg Q
On 23 Oct 2019, at 04:00, I M <isabella.ghiurea(a)nrc-cnrc.gc.ca>
wrote:
Mark, SImon thank you for feedback!
The connections between master to master is good same location but the one from to new
DS slave on different location is poor, so this should imply to have 2agreements , also we
are using memberof pluging , for each master host the memberof is excluded from
replication ( cfg as fractional replication)
and for master to slave ( I assume member off will not be excluded will be full
replication)
Than would make sense to have only one master to slave full replication agreement?
Think of it a different way - I like pictures with this
[ Write A ] <<-- repl -->> [ Write B ]
\
\ link a
\
\----> [ RO C ]
In the first scenario if something happens to Write A, or link a, or the repl link you now
isolate RO C such as:
[ Write A ] [ Write B ]
\
\ link a
\
\----> [ RO C ]
[ Write A ] <<-- repl -->> [ Write B ]
\
[ RO C ]
This way changes to Write B or Write A won't make it to C. And if the link is
"unreliable" then this is more likely to happen.
But if you have multipath:
[ Write A ] <<-- repl -->> [ Write B ]
\ /
\ link a link b /
\ /
\----> [ RO C ] <---/
Issues on repl, link a or link b will shield you from issues because the other path will
be selected to C.
So I'd advise you always try to have at least 2 incoming replication agreements to any
server in any topology
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
10:12 a.m.
New subject: master to master replication cfg Q
William Thank you for all graph details ,
the only left Q I have if there is any chance to have "memberof" pluging
entries collision in RO C host ?( this DS be cfg for 2 incoming replication agreements -
full replication including memberof plugin)
regards,
Isabella
5:47 p.m.
New subject: master to master replication cfg Q
On 24 Oct 2019, at 01:12, I M <isabella.ghiurea(a)nrc-cnrc.gc.ca>
wrote:
William Thank you for all graph details ,
the only left Q I have if there is any chance to have "memberof" pluging
entries collision in RO C host ?( this DS be cfg for 2 incoming replication agreements -
full replication including memberof plugin)
Generally if you have memberof enabled on the two read-write servers, than the RO serverc
will be consistent without member of enabled.
However, you can also avoid this issue buy setting all replication to fractionally exclude
memberof, and enable memberof on all servers so that they generate the content from their
respective datasets.
Does that help?
regards,
Isabella
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
1639
days inactive
1641
days old
389-users@lists.fedoraproject.org
6 comments
5 participants
participants (5)
-
Ghiurea, Isabella -
I M
-
Mark Reynolds -
Simon Pichugin -
William Brown