This one caused some head-scratching recently so just in case anyone else comes across it...
I was updating the OpenLDAP installation for a customer, and part of the work involved converting from a single server to a mirrormode pair with some read-only slaves. The sequence of events was:
1) Dump old server to LDIF 2) Update software from 2.3.x to 2.4.23 3) Clear out and reload database from LDIF 4) Many entries added, deleted, modified 5) Second server introduced, mirrormode configured This involved adding 'serverID 1' to the original server config and restarting it. 6) Read-only slave configured, pre-loaded from the same LDIF 7) Slave started
The new servers updated using refreshAndPersist mode: they got all the adds and changes but did not process any of the deletes.
The problem was introduced at stage 5: by changing from serverID 000 to serverID 001 I had broken an assumption in the code. I am still not clear on exactly what went wrong, as I would expect the server to simply regard all its current entries to have come from some other master server. The effect was reproducable though: no deletes were processed by the consuming server.
The correct thing would be to set the serverID before loading the initial data, but if that gets missed it seems to be OK to take a new LDIF dump after changing the ID, and to use that to pre-load replica servers.
Andrew
--On Tuesday, September 14, 2010 6:25 PM +0100 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
The correct thing would be to set the serverID before loading the initial data, but if that gets missed it seems to be OK to take a new LDIF dump after changing the ID, and to use that to pre-load replica servers.
File a (documentation at least) ITS for this?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Tue, Sep 14, 2010 at 01:11:00PM -0700, Quanah Gibson-Mount wrote:
The correct thing would be to set the serverID before loading the initial data, but if that gets missed it seems to be OK to take a new LDIF dump after changing the ID, and to use that to pre-load replica servers.
File a (documentation at least) ITS for this?
Having done some more tests, I have found a case where an apparently-valid mirrormode configuration falls into the same trap (without changing serverIDs at inopportune times). I have therefore submitted this as a software problem:
http://www.OpenLDAP.org/its/index.cgi?findid=6648
It affects new consumer servers that need to process deletions in the initial refresh phase, and those deletions originated on multiple master servers.
Andrew
openldap-technical@openldap.org