We have multimaster replication in place, and sync replication is working. However, we have noticed some glue values for certain entries. What could be the reason for these glue entries, and how can we avoid them?
This is a sample entry wit glue values for objectClass and structuralObjectClass attribtues. Please suggest how to avoid these glue values.
dn: cn=organizational users,o=test,cn=test,cn=acd,o=in.bbn.ac entryUUID: 2acd5574-47fb-4414-b930-65d3fefc40cb creatorsName: cn=Directory Manager,o=in.bbn.ac createTimestamp: 20240730130003Z entryCSN: 20240730130003.412795Z#000000#001#000000 modifiersName: cn=Directory Manager,o=in.bbn.ac modifyTimestamp: 20240730130003Z objectClass: top objectClass: glue structuralObjectClass: glue
Hi!
So your claim is that replication adds those "glue" object classes? Or do you want to filter out that object class? Do you replicate the complete tree, also giving proper permissions to do so?
Kind regards, Ulrich Windl
-----Original Message----- From: mbalakri@opentext.com mbalakri@opentext.com Sent: Sunday, February 16, 2025 4:45 PM To: openldap-technical@openldap.org Subject: [EXT] Attribute value as glue
We have multimaster replication in place, and sync replication is working. However, we have noticed some glue values for certain entries. What could be the reason for these glue entries, and how can we avoid them?
This is a sample entry wit glue values for objectClass and structuralObjectClass attribtues. Please suggest how to avoid these glue values.
dn: cn=organizational users,o=test,cn=test,cn=acd,o=in.bbn.ac entryUUID: 2acd5574-47fb-4414-b930-65d3fefc40cb creatorsName: cn=Directory Manager,o=in.bbn.ac createTimestamp: 20240730130003Z entryCSN: 20240730130003.412795Z#000000#001#000000 modifiersName: cn=Directory Manager,o=in.bbn.ac modifyTimestamp: 20240730130003Z objectClass: top objectClass: glue structuralObjectClass: glue
Hi, Thank you for the response.
Yes, the glue value is added by replication. The issue occurs only when multi-master replication is configured. The full tree is replicated with the proper permissions, and all other entries are replicated correctly.
However, our application does not work when the objectClass value is set to glue. We want to ensure replication always includes the correct value and never results in a glue entry.
To achieve this, we need to understand the scenarios where replication adds glue values and find ways to eliminate such cases. With the glue attribute value, we are unable to read the entry properly. Even if we do read the entry, the application requires the actual value instead of glue for it to function correctly.
Hello,
I have add glue record in the following situation : single master replication, but partial replication.
I was replicating something like ou=people,dc=my,dc=domain
But I was not replicating the dc=my,dc=domain object
So the replication created this object with a glue objectClass
f.g.
Le 17 févr. 2025 à 10:52, mbalakri@opentext.com a écrit :
Hi, Thank you for the response.
Yes, the glue value is added by replication. The issue occurs only when multi-master replication is configured. The full tree is replicated with the proper permissions, and all other entries are replicated correctly.
However, our application does not work when the objectClass value is set to glue. We want to ensure replication always includes the correct value and never results in a glue entry.
To achieve this, we need to understand the scenarios where replication adds glue values and find ways to eliminate such cases. With the glue attribute value, we are unable to read the entry properly. Even if we do read the entry, the application requires the actual value instead of glue for it to function correctly.
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
In this case, we are definitely replicating the full tree. However, the glue value is added to one of the entries in the middle of the hierarchy.
On Sun, Feb 16, 2025 at 03:44:47PM -0000, mbalakri@opentext.com wrote:
We have multimaster replication in place, and sync replication is working. However, we have noticed some glue values for certain entries. What could be the reason for these glue entries, and how can we avoid them?
This is a sample entry wit glue values for objectClass and structuralObjectClass attribtues. Please suggest how to avoid these glue values.
dn: cn=organizational users,o=test,cn=test,cn=acd,o=in.bbn.ac objectClass: glue
Hi, either replication is not configured as intended (are you sure the ACLs allow full read access to the DIT between the providers?) or the entry doesn't exist but the DB contains its children so a "fake" (glue) entry had to be created to connect the children to the tree.
Regards,
Hi, If replication is not configured as intended, it would affect other entries as well. However, all other entries are replicating properly.
The entry itself does not exist, but its children are present in the database. Could this scenario occur even when the full tree is configured for replication?
Regards, Mini
On Mon, Feb 17, 2025 at 10:37:02AM -0000, mbalakri@opentext.com wrote:
Hi, If replication is not configured as intended, it would affect other entries as well. However, all other entries are replicating properly.
The entry itself does not exist, but its children are present in the database. Could this scenario occur even when the full tree is configured for replication?
Hi Mini, so you're saying the entry doesn't exist on the other provider(s)? Then yes, the replica that you're looking at had no chance but to synthesize a glue entry to store these children under. In a sense we're talking about a similar scenario as Frédéric is describing.
Regards,
Hi, Initially, all entries are present in both providers in a 2-node multi-master setup. We export the data from node1 and import it into node2 as part of the replication configuration, ensuring that both nodes have identical data at the start.
Most updates occur on node1, but there are scenarios where updates also happen on node2. At some point, we observe that a glue value appears.
On Mon, Feb 17, 2025 at 10:58:08AM -0000, mbalakri@opentext.com wrote:
Hi, Initially, all entries are present in both providers in a 2-node multi-master setup. We export the data from node1 and import it into node2 as part of the replication configuration, ensuring that both nodes have identical data at the start.
Most updates occur on node1, but there are scenarios where updates also happen on node2. At some point, we observe that a glue value appears.
Check your serverids are distinct and that your ACLs really allow full read access to the database for the replication identity, *especially* for this entry.
If in doubt, try reading the entry with ldapsearch (using the replication identity). If you really can read it, you'll have to review the logs (enable loglevel sync) to check why it is being "removed" (turned into a glue entry).
Regards,
In case you do not sync the cn=config, too: Are the ACLs on all nodes really the same? We run a multi.master replication here, too, and I never notices such a problem. I suggest to enable sync logging temporarily; if you have rare changes you could even leave it enabled.
Kind regards, Ulrich Windl
-----Original Message----- From: mbalakri@opentext.com mbalakri@opentext.com Sent: Monday, February 17, 2025 11:58 AM To: openldap-technical@openldap.org Subject: [EXT] Re: Attribute value as glue
Hi, Initially, all entries are present in both providers in a 2-node multi-master setup. We export the data from node1 and import it into node2 as part of the replication configuration, ensuring that both nodes have identical data at the start.
Most updates occur on node1, but there are scenarios where updates also happen on node2. At some point, we observe that a glue value appears.
Ok, i think enable logging is the way forward.
openldap-technical@openldap.org
-
Frédéric Goudal -
mbalakri＠opentext.com -
Ondřej Kuzník -
Windl, Ulrich