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