Full_Name: Quanah Gibson-Mount Version: 2.3.40 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) If someone is using delta-syncrepl for replication, and does a hot slapcat of a server, and a change occurs during the slapcat, the resulting LDIF file cannot be used on a replica. This is because the replica will try to resume from the CSN in the LDIF file, which is from before the change occurred. Since the change is in the LDIF file, when the replica contacts the master, it tries to re-replicate the change (which obviously fails). At that point, the replica is stuck and unable to progress. The only guaranteed way to get a viable slapcat when using delta-syncrepl is to put the server being dumped into RO mode or to stop it. --Quanah
quanah@OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.40 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > If someone is using delta-syncrepl for replication, and does a hot slapcat of a > server, and a change occurs during the slapcat, the resulting LDIF file cannot > be used on a replica. This is because the replica will try to resume from the > CSN in the LDIF file, which is from before the change occurred. Since the > change is in the LDIF file, when the replica contacts the master, it tries to > re-replicate the change (which obviously fails). At that point, the replica is > stuck and unable to progress. The only guaranteed way to get a viable slapcat > when using delta-syncrepl is to put the server being dumped into RO mode or to > stop it. Another possibility would be to filter out any entries whose entryCSNs are newer than the contextCSN in the LDIF before trying to slapadd it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@OpenLDAP.org wrote: > Another possibility would be to filter out any entries whose entryCSNs are > newer than the contextCSN in the LDIF before trying to slapadd it. Should slapadd take care of it (perhaps if instructed to do so)? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote: > hyc@OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? I guess that would be ok. It seems that doc/devel/toolargs isn't up to date now, dunno what option flag would make sense here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Pierangelo Masarati wrote: > hyc@OpenLDAP.org wrote: > >> Another possibility would be to filter out any entries whose entryCSNs are >> newer than the contextCSN in the LDIF before trying to slapadd it. > > Should slapadd take care of it (perhaps if instructed to do so)? Of course it might be better to change the delta-sync consumer to check the target's entryCSN after a modification fails, to see if it matches the current modification attempt. If so, then the failure can be safely ignored. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On February 14, 2008 12:21:00 PM +0000 hyc@symas.com wrote: > Pierangelo Masarati wrote: >> hyc@OpenLDAP.org wrote: >> >>> Another possibility would be to filter out any entries whose entryCSNs >>> are newer than the contextCSN in the LDIF before trying to slapadd it. >> >> Should slapadd take care of it (perhaps if instructed to do so)? > > Of course it might be better to change the delta-sync consumer to check > the target's entryCSN after a modification fails, to see if it matches > the current modification attempt. If so, then the failure can be safely > ignored. -- Note: It should be if it matches or is greater. For example, if it was the very last entry in the DB, thus the last to be added to the resulting LDIF, it is entirely possible that multiple modifications could be done from the time the dump started and the dump ended, meaning the CSN would be greater than the one encountered in the accesslog DB. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
changed notes changed state Open to Test moved from Incoming to Software Bugs
A fix is in HEAD. delta-syncrepl will now fallback to regular refresh in additional cases - LDAP_ALREADY_EXISTS, which may occur for old Adds, LDAP_NO_SUCH_OBJECT, for cases already covered in ITS#5376, LDAP_NO_SUCH_ATTRIBUTE, for old Modifies, and LDAP_TYPE_OR_VALUE_EXISTS also for old Modifies. Pretty sure that covers all of the possible out-of-sync cases. Please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Test to Release
changed notes
changed state Release to Closed
fixed in HEAD/RE24/RE23