Hello,
we recently adjusted our sync from n-way multimaster replication of the tree (searchbase="dc=organization,dc=com") and now included our "cn=config" replication.
Some concerns/questions I have:
Before with only tree replication, it was my understanding that one could NOT add a new schema along with an object unless said schema already existed in the other masters. yes?
Our process was to turn off the sync add the schema to each master then normalize. Probably turning off the sync was unnecessary but just to be safe. Regardless if a new object with new schemas was added then one could ruin all the masters. Correct?
Ok, so now with cn=config synchronized as well. Does this issue, if an issue, go away?
Also, if upgrading one masters openldap software, should the sync be off? Recommendations?
Any input is much appreciated.
Thank you, Dave
--On Wednesday, April 03, 2019 12:40 PM -0400 Dave Macias davama@gmail.com wrote:
we recently adjusted our sync from n-way multimaster replication of the tree (searchbase="dc=organization,dc=com") and now included our "cn=config" replication.
Some concerns/questions I have:
Before with only tree replication, it was my understanding that one could NOT add a new schema along with an object unless said schema already existed in the other masters. yes?
Sort of. If you added the schema and then an object, the other masters should halt replication at that point until they have a matching schema.
Our process was to turn off the sync add the schema to each master then normalize. Probably turning off the sync was unnecessary but just to be safe. Regardless if a new object with new schemas was added then one could ruin all the masters. Correct?
Not really, no. It does depend on the version of OpenLDAP in use, as there were some bugs in older OpenLDAP versions that would allow the object to partially replicate or the object to just get skipped, which could cause headache. But those issues were fixed.
Ok, so now with cn=config synchronized as well. Does this issue, if an issue, go away?
I would say that by doing cn=config replication, you've added a wide surface area for new issues to occur. I generally view cn=config replication as more of a beta feature. There are still ongoing issues being resolved and fixed for it (For example, ITS#8616 in the most recent 2.4.47 release).
Also, if upgrading one masters openldap software, should the sync be off? Recommendations?
Generally, no. It's just a binary in place update to slapd. There was one instance where a schema change to ppolicy was pushed into 2.4 that broke existing installations that used cn=config if the ppolicy schema wasn't also updated at the same time. I don't forsee something like that happening again in the future as the awareness is there now about the problems such a change can cause.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Dave Macias -
Quanah Gibson-Mount