Hi Quanah,
Thank your very much. Your reply is quite clear. After that I made a
decision to migrate to delta-sync and to increase my session log (I have
800k users and 2.000.000 of entries). Please take a look on my new config
after these changes, and let me know if it's ok:
Node A:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
#####
# primary db config
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 2000000
# 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
# Global section
serverID 1
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://02.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="10 +"
syncdata=accesslog
tls_cacert=/usr/local/etc/openldap/cert/certServerID2.crt
mirrormode on
Node B:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
#####
# primary db config
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 2000000
# 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
# Global section
serverID 2
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://01.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="10 +"
syncdata=accesslog
tls_cacert=/usr/local/etc/openldap/cert/certServerID1.crt
mirrormode on
After that I made a change on Node A and it replicated to node B, then I
made a change on node B and it replicated to A. So seems it's working. My
doubt is how can I make sure it's working with delta-sync mode?
Another question, changing to delta-sync can I use more than 2 nodes, for
instance, 3 servers receiving writing and replicating between them?
Thank you.
On Wed, Apr 3, 2019 at 1:09 PM Quanah Gibson-Mount <[email protected]> wrote:
> --On Wednesday, April 03, 2019 11:14 AM -0300 Alex Hebra
> <[email protected]> wrote:
>
> > Thanks for your answer. Here are the details asked:
> >
> >
> > OpenLDAP version 2.4.46.
> >
> > syncprov-sessionlog 100
> > syncprov-sessionlog 100
>
> Hi Alex,
>
> Your sessionlog value is way too small. It needs to be something a little
> larger than the entire size of your database (so > 800,000 in your case).
> I also see you're using standard syncrepl rather than delta-syncrepl.
>
> Generally, having a "glued" object on a server indicates that at some
> point, the server was in a REFRESH mode (either you populated the server
> using syncrepl instead of slapcat, or it had some reason to fall back to
> REFRESH at a later date).
>
> In the REFRESH mode, the server may get entries "out of order". In this
> case, a stub (glue) object is created to "hold" the place for tha entry
> until it gets fully replicated. Unfortunately, this doesn't always
> happen,
> and you end up being stuck with the glued object on the server.
>
> You may be able to force replication of the object onto the server where
> it's missing by doing a MOD op against the affected entry on the master
> where it exists. If one master is "complete" (I.e., no glued objects),
> you
> could also slapcat that master and import the database into the othe
> rmaster via slapadd to resolve the problem for now.
>
> Overally, I strongly advise using delta-syncrepl as it largely avoids
> these
> issues (as long as it never has to fall back to standard syncrepl REFRESH
> mode).
>
> I would note that there was a fix in OpenLDAP 2.4.47 specific to
> delta-syncrepl when ppolicy is in use, so if using delta-sync you likely
> want that fix.
>
> --Quanah
>
>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
