9:25 a.m.
Currently have a provider / consumer setup in one datacenter. Looking to expand to other
datacentre and would like better redundancy.
Running version 2.4.28.
What's the best way to change from provider / consumer to n-way master? Down time is
an option.
Can the current replication be stopped, reconfigured and then started again?
----
Peter
9:45 a.m.
--On Thursday, October 24, 2013 4:25 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
Currently have a provider / consumer setup in one datacenter. Looking to
expand to other datacentre and would like better redundancy.
Running version 2.4.28.
Do not move to multi-master until you upgrade to a current OpenLDAP
release. I also strongly advise using delta-syncrepl based MMR.
What's the best way to change from provider / consumer to n-way
master?
Down time is an option.
Can the current replication be stopped, reconfigured and then started
again?
You can do it with zero downtime.
<https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/Zimbr...
is a script I wrote to promote Zimbra replicas to be part of a MMR node.
You would of course have to adapt it to your environment.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9:14 a.m.
--On Friday, October 25, 2013 3:57 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> Do not move to multi-master until you upgrade to a current
OpenLDAP
> release. I also strongly advise using delta-syncrepl based MMR.
After some digging on the current setup we have here, going to rebuild a
new setup using 2.4.36.
Any good howto's on MMR using delta-syncrepl ?
It's not much different than deploying standard syncrepl, and then adding
in server IDs...
Personally, I just scripted it:
<https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/Zimbr...
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9:28 a.m.
It's not much different than deploying standard syncrepl, and then
adding in server IDs...
Personally, I just scripted it:
The script is great but I'm trying to understand the process of it all, so that I can
troubleshoot it as thing happen or as I add more masters to group.
9:32 a.m.
--On Friday, October 25, 2013 4:28 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> It's not much different than deploying standard syncrepl, and
then
> adding in server IDs...
> Personally, I just scripted it:
> <https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/Zim
> braServer/src/libexec/zmldapenable-mmr>
The script is great but I'm trying to understand the process of it all,
so that I can troubleshoot it as thing happen or as I add more masters to
group.
As Christopher Wood noted, the admin guide details delta-syncrepl
configuration and how it works.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9:26 a.m.
On Fri, Oct 25, 2013 at 03:57:23PM +0000, Peter Sprokkelenburg wrote:
>Do not move to multi-master until you upgrade to a current
OpenLDAP release. I also strongly advise using delta-syncrepl based MMR.
After some digging on the current setup we have here, going to rebuild a new setup using
2.4.36.
Any good howto's on MMR using delta-syncrepl ?
I favour the admin guide, given the prevalence of misinformation out there:
http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl
It also discusses which man pages cover this.
9:33 a.m.
I favour the admin guide, given the prevalence of misinformation out
there:
It also discusses which man pages cover this.
Thank you for that, I've already looked at that and I'm a little confused on the
process.
What's the best order? MultiMaster then Delta-syncrepl? Or is there a way to combine
them both as you setup each master?
As we grow, I know I'm going to need to add more masters to each datacentre.
9:38 a.m.
--On Friday, October 25, 2013 4:33 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> I favour the admin guide, given the prevalence of misinformation out
> there:
> http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl
> It also discusses which man pages cover this.
Thank you for that, I've already looked at that and I'm a little confused
on the process.
What's the best order? MultiMaster then Delta-syncrepl? Or is there a way
to combine them both as you setup each master?
Hi Peter,
They are not separate concepts. You can either set up multi-master using
standard syncrepl, or multi-master using delta-syncrepl. Just as you can
set up a master as using syncrepl, or a master as using delta-syncrepl.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:14 a.m.
They are not separate concepts. You can either set up multi-master
using standard syncrepl, or multi-master using delta-syncrepl. Just as you can set up a
master as
using syncrepl, or a master as using delta-syncrepl.
Maybe it's that fact that it is Friday or that I've been starring at this all day,
I'm just not seeing it.
Back to reading the Manual.
10:18 a.m.
--On Friday, October 25, 2013 5:14 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> They are not separate concepts. You can either set up
multi-master
> using standard syncrepl, or multi-master using delta-syncrepl. Just as
> you can set up a master as using syncrepl, or a master as using
> delta-syncrepl.
Maybe it's that fact that it is Friday or that I've been starring at this
all day, I'm just not seeing it.
When you set up your ldap servers, you choose how you want them to be
configured. You can either configure the master to keep an accesslog DB
that any replicas (including additional MMR nodes) will use for their
primary method of doing replication, or you don't do that. If you do do
that, then you are using delta-syncrepl. If you don't, then you aren't.
Does that help? ;)
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:28 a.m.
When you set up your ldap servers, you choose how you want them to be
configured. You can either configure the master to keep an accesslog DB that any replicas
>(including additional MMR nodes) will use for their primary method of doing
replication, or you don't do that. If you do do that, then you are using
delta-syncrepl. If >you don't, then you aren't.
Does that help? ;)
I think so.
So then based on the examples here :
http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl
It would be a combination of provider AND consumer on each each server with the N-Way
config.
Correct ?
10:35 a.m.
--On Friday, October 25, 2013 5:28 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
I think so.
So then based on the examples here :
http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl
It would be a combination of provider AND consumer on each each server
with the N-Way config.
Correct ?
Conceptually for MMR, every node is both a provider and consumer, so it is
configured both to be a master and a replica at the same time. ServerIDs
are used to distinguish which changes occurred on which master, and to
avoid replication loops. That is independent of which replication
mechanism you choose to use between the nodes (i.e., this has to be done
regardless of syncrepl or delta-syncrepl).
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
4:03 p.m.
Conceptually for MMR, every node is both a provider and consumer, so
it is configured both to be a master and a replica at the same time. ServerIDs are used
to >distinguish which changes occurred on which master, and to avoid replication loops.
That is independent of which replication mechanism you choose to use between >the
nodes (i.e., this has to be done regardless of syncrepl or delta-syncrepl).
Okay I think I'm getting it.
So I have a working config on two lab vm.
It is syncing the acesslog changes, but when I fired up the second server, it didn't
do a full sync.
I need multiple RID's for each item I want to sync?
I'm doing this all in slapd.conf
4:51 p.m.
--On Friday, October 25, 2013 11:03 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> Conceptually for MMR, every node is both a provider and consumer, so it
> is configured both to be a master and a replica at the same time.
> ServerIDs are used to >distinguish which changes occurred on which
> master, and to avoid replication loops. That is independent of which
> replication mechanism you choose to use between >the nodes (i.e., this
> has to be done regardless of syncrepl or delta-syncrepl).
Okay I think I'm getting it.
So I have a working config on two lab vm.
It is syncing the acesslog changes, but when I fired up the second
server, it didn't do a full sync.
I need multiple RID's for each item I want to sync?
I'm doing this all in slapd.conf
Your question doesn't make any sense as asked. I would suggest you
pastebin your configuration minus passwords.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8:30 a.m.
Your question doesn't make any sense as asked. I would suggest
you pastebin your configuration minus passwords.
Here is the config :
# Schema's
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/misc.schema
# Global
serverID 1 ldap://ldap1
serverID 2 ldap://ldap2
password-hash {SSHA}
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
moduleload back_bdb
moduleload back_hdb
moduleload syncprov
moduleload accesslog
# Max entries returned for searches
sizelimit 10000
# CPU Indexing threads
tool-threads 1
# ACL's
access to *
by dn.base="cn=thegiver,dc=cas-aci,dc=ca" read
by * break
access to dn.children="ou=People,dc=cas-aci,dc=ca"
attrs=userPassword
by self write
by * auth
access to *
by * read
# Accesslog database definitions
database hdb
suffix cn=accesslog
directory /var/db/openldap-accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
# Let the replica DN have limitless searches
limits dn.exact="cn=admin,dc=cas-aci,dc=ca" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# Main DB
database bdb
suffix "dc=cas-aci,dc=ca"
rootdn "cn=admin,dc=cas-aci,dc=ca"
rootpw $PASSWORD
directory /var/db/openldap-data
# syncrepl Provider for primary db
overlay syncprov
syncprov-checkpoint 20 10
# Save modify times
lastmod on
# Indexing
index default eq
index objectclass,entryCSN,entryUUID
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
# Let the replica DN have limitless searches
limits dn.exact="cn=admin,dc=cas-aci,dc=ca" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# AccessLog syncrepl directives
syncrepl rid=001
provider=ldap://ldap1:389
bindmethod=simple
binddn="cn=thegiver,dc=cas-aci,dc=ca"
searchbase="dc=cas-aci,dc=ca"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="5 5 300 5"
syncdata=accesslog
interval=00:00:02:00
syncrepl rid=002
provider=ldap://ldap2:389
bindmethod=simple
binddn="cn=thegiver,dc=cas-aci,dc=ca"
searchbase="dc=cas-aci,dc=ca"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="5 5 300 5"
syncdata=accesslog
interval=00:00:02:00
# Data Replication
mirrormode on
# Logging
loglevel 256 128 64
10:16 a.m.
--On Monday, October 28, 2013 3:30 PM +0000 Peter Sprokkelenburg
<peters(a)dsl4u.ca> wrote:
> Your question doesn't make any sense as asked. I would
suggest you
> pastebin your configuration minus passwords.
Here is the config :
# Schema's
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/misc.schema
# Global
serverID 1 ldap://ldap1
serverID 2 ldap://ldap2
Since you aren't using cn=config, there is no point in providing the URI.
I would advise:
serverID 1
on one server and
serverID 2
on the other server.
Those also aren't fully formed URIs, so it may well not be matching,
causing serverID confusion.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
3692
days inactive
3696
days old
openldap-technical@openldap.org
16 comments
3 participants
participants (3)
-
Christopher Wood -
Peter Sprokkelenburg -
Quanah Gibson-Mount