Hello,
I'm a longtime openldap and syncreplica user. Now I learned about delta replication and the option "strictrefresh". But it doesn't work as promised. Maybe my expectation is simply wrong...
Let's describe my use case: One ore two provider serve data to numerous consumer. Application running on the consumer host are configured to query the local consumer first and fall back to the provider. A typical LDAP-URI looks like "ldap://localhost ldaps://provider1 ldaps://provider2" Application only /read/ data.
Sometimes it happen the consumer go out of sync. Convenient solution: delete the consumer ldap database and restart slapd. Now it take some time to fetch the whole data from provider to consumer server.
Just in this time frame the application may query ldap://localhost and get an answer which is simply wrong because the data transfer is still in progress. That's what I want to avoid.
Is that possible with openldap at all
Thanks, Andreas
A. Schulze wrote:
Hello,
I'm a longtime openldap and syncreplica user. Now I learned about delta replication and the option "strictrefresh". But it doesn't work as promised. Maybe my expectation is simply wrong...
Let's describe my use case: One ore two provider serve data to numerous consumer. Application running on the consumer host are configured to query the local consumer first and fall back to the provider. A typical LDAP-URI looks like "ldap://localhost ldaps://provider1 ldaps://provider2" Application only /read/ data.
Sometimes it happen the consumer go out of sync. Convenient solution: delete the consumer ldap database and restart slapd. Now it take some time to fetch the whole data from provider to consumer server.
Just in this time frame the application may query ldap://localhost and get an answer which is simply wrong because the data transfer is still in progress. That's what I want to avoid.
Is that possible with openldap at all
strict refresh was an experiment, which is also why it remains undocumented. What you describe is the desired effect but as you've found, it doesn't work as intended. It looks to me that one of the refresh scenarios isn't being caught but I haven't looked closely at this feature in quite a while.
Patches welcome.
Howard Chu:
strict refresh was an experiment, which is also why it remains undocumented. What you describe is the desired effect but as you've found, it doesn't work as intended. It looks to me that one of the refresh scenarios isn't being caught but I haven't looked closely at this feature in quite a while.
Howard,
thanks for response. I understand this is not a wrong configuration but not fully implemented feature.
Patches welcome.
no Idea about details how the sync protocol works. But I've some other patched I'll publish for discussion.
Andreas
"A. Schulze" sca@andreasschulze.de schrieb am 08.03.2016 um 21:13 in
Nachricht 20160308211316.Horde.GypvzvjbSnE4DU4U3p33UA1@andreasschulze.de:
Hello,
I'm a longtime openldap and syncreplica user. Now I learned about delta replication and the option "strictrefresh". But it doesn't work as promised. Maybe my expectation is simply wrong...
Let's describe my use case: One ore two provider serve data to numerous consumer. Application running on the consumer host are configured to query the local consumer first and fall back to the provider. A typical LDAP-URI looks like "ldap://localhost ldaps://provider1 ldaps://provider2" Application only /read/ data.
Sometimes it happen the consumer go out of sync. Convenient solution:
What you describe is not a database out of sync, but a corrupted database. You never have to delete a database that is out of sync; you'll just have to refresh it, and that should be automatic if configured and working correctly
delete the consumer ldap database and restart slapd. Now it take some time to fetch the whole data from provider to consumer server.
It would be definitely helpful to have a diff of the databases (between up-to-date, and outdated).
Just in this time frame the application may query ldap://localhost and get an answer which is simply wrong because the data transfer is still in progress. That's what I want to avoid.
What you did not say is who is updating the data, and where.
Is that possible with openldap at all
"time was invented in universe so that not everything would happen at once" (vague memory of som UNIX fortune cookie) ;-)
Regards, Ulrich
--On Wednesday, March 09, 2016 8:46 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Sometimes it happen the consumer go out of sync. Convenient solution:
What you describe is not a database out of sync, but a corrupted database. You never have to delete a database that is out of sync; you'll just have to refresh it, and that should be automatic if configured and working correctly
Except, as is often the case, you're generally wrong. Unfortunately, every release prior to 2.4.44 definitely has cases where DBs can go out of sync. And even worse, resyncing will *not* necessarily get them back in sync. So often you *do* have to delete a database that is out of sync, and load it with a slapcat from the master. As I've often noted, the form of replication *least likely* to run into this is delta-syncrepl. Hopefully with 2.4.44 all known cases of this are addressed, but that still is not guaranteed.
* http://www.openldap.org/its/index.cgi/?findid=8281 * http://www.openldap.org/its/index.cgi/?findid=8365
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
openldap-technical@openldap.org
-
A. Schulze -
Howard Chu -
Quanah Gibson-Mount -
Ulrich Windl