I was testing the recovery of a slave in a delta-syncrepl configuration after an accesslog purge, and noticed that operations that have been purged from the accesslog that occurred while the slave was down do not get replicated when the initial master database was loaded with "slapadd -w".
If the slave database is empty, it will correctly receive all master entries, but if you shut the slave down (after it has done the initial sync), make a change, wait for the change to be purged from the accesslog, and then bring the slave back up, the slave will not see the change.
The contextCSN of the slave is updated in this case, but nothing else is replicated, and the slave is effectively stale. When the slave is first brought up I do notice that two different contextCSN(s) are written to the auditlog.
When the initial database is loaded without using the -w flag with slapadd or with ldapsearch (on an empty database), the slave receives all changes correctly after the accesslog has been purged.
Is this expected behavior in any way?
I am using the standard delta-syncrepl config from the admin guide with 2.4.11.
--On Wednesday, August 20, 2008 6:57 PM -0400 David Hawes dhawes@vt.edu wrote:
Is this expected behavior in any way?
Yes. How can it know that it needs to replicate a change on the entry if the change is no longer present? You need to restore from a recent backup.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, August 20, 2008 10:50 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, August 20, 2008 6:57 PM -0400 David Hawes dhawes@vt.edu wrote:
Is this expected behavior in any way?
Yes. How can it know that it needs to replicate a change on the entry if the change is no longer present? You need to restore from a recent backup.
Actually, nm, IIRC it is supposed to go into a refresh phase. I remember this being a problem in 2.3 for a while, and then later fixed.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, August 20, 2008 6:57 PM -0400 David Hawesdhawes@vt.edu wrote:
Is this expected behavior in any way?
Yes. How can it know that it needs to replicate a change on the entry if the change is no longer present? You need to restore from a recent backup.
No!!
When the replica's cookie CSN isn't found in the provider's accesslog it's supposed to force a fallback to regular syncrepl. Come on Quanah, you're one of the people who actually tested that functionality...
--On Thursday, August 21, 2008 1:55 AM -0700 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, August 20, 2008 6:57 PM -0400 David Hawesdhawes@vt.edu wrote:
Is this expected behavior in any way?
Yes. How can it know that it needs to replicate a change on the entry if the change is no longer present? You need to restore from a recent backup.
No!!
When the replica's cookie CSN isn't found in the provider's accesslog it's supposed to force a fallback to regular syncrepl. Come on Quanah, you're one of the people who actually tested that functionality...
Hence my follow up. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Wednesday, August 20, 2008 6:57 PM -0400 David Hawes dhawes@vt.edu wrote:
I was testing the recovery of a slave in a delta-syncrepl configuration after an accesslog purge, and noticed that operations that have been purged from the accesslog that occurred while the slave was down do not get replicated when the initial master database was loaded with "slapadd -w".
I can confirm this behavior with the latest RE24 CVS as well. I will file an ITS.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org