Re: Help needed: "glued" object.

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>