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 <quanah@symas.com> wrote:
--On Wednesday, April 03, 2019 11:14 AM -0300 Alex Hebra
<hebraalex@gmail.com> 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>