Hi Quanah
Thank you for the response. If the consumer is several days behind and the accesslog does not have the data then fresh reload from the provider will happen automatically?
Thanks Rahul
On Tue, Jul 14, 2020 at 11:28 AM Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, July 10, 2020 11:04 AM -0400 kumar rahul rahul2002mit@gmail.com wrote:
- What is the recommended value for olcSpCheckpoint?
As per your blog value is olcSpCheckpoint: 20 10
I prefer to have it checkpoint fairly frequently, which is why I chose those values.
- What is the recommended value of olcAccessLogPurge?
As per your blog value is olcAccessLogPurge: 01+00:00 00+04:00
So this depends specifically on the environment in question. The more data retained, the further back a replica can "catch up" to the provider(s) by using delta-syncrepl. However, the more data retained, the larger the database will be. Whether or not one wants a replica to be able to "catch up" to a provider if it is several days behind vs reloading it with a fresh copy of the db from the provider is the real question.
Regardless of the data retention period, I always suggest a frequent purge interval. This is because slapd essentially pauses while a purge is ongoing. For most environments, a 4 hour purge interval is not noticable. I've gone to as frequent as every 2 hours for extremely active sites.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, July 15, 2020 10:39 AM -0400 kumar rahul rahul2002mit@gmail.com wrote:
Hi Quanah
Thank you for the response.
If the consumer is several days behind and the accesslog does not have the data then fresh reload from the provider will happen automatically?
It will fall back to REFRESH mode which has various bugs and the resulting DB may be deficient. If you have a consumer that is that far behind, the only safe solution is to slapcat the provider and import on the consumer.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 15.07.2020 um 17:23 in
Nachricht <A4DE305A89AF6639323BB90D@[192.168.0.156]>:
--On Wednesday, July 15, 2020 10:39 AM -0400 kumar rahul rahul2002mit@gmail.com wrote:
Hi Quanah
Thank you for the response.
If the consumer is several days behind and the accesslog does not have the data then fresh reload from the provider will happen automatically?
It will fall back to REFRESH mode which has various bugs and the resulting DB may be deficient. If you have a consumer that is that far behind, the
Hi!
Could you give more details on that? Is it a bug by design, or is it a bug in the implementation?
Regards, Ulrich
only safe solution is to slapcat the provider and import on the consumer.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, July 16, 2020 8:58 AM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Could you give more details on that? Is it a bug by design, or is it a bug in the implementation?
I've referenced the underlying bug for years. ITS#8125.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 16.07.2020 um 17:01 in
Nachricht <33146DC712C0F6197C97C784@[192.168.0.156]>:
‑‑On Thursday, July 16, 2020 8:58 AM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
Could you give more details on that? Is it a bug by design, or is it a bug in the implementation?
I've referenced the underlying bug for years. ITS#8125.
I read the bug, but it's not quite clear what the true reason is. for me I got: modrdn operations, multi-valued attributes with more than one change per second, possibly non-persistent sessionlog. This combination leads to unreliable synchronization. And it seems the bug isn't fixed yet.
Couldn't there be a warning at least saying something like "unsafe sync configuration detected. Expüect inconsistent replica"?
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Mon, Jul 20, 2020 at 08:49:51AM +0200, Ulrich Windl wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 16.07.2020 um 17:01 in Nachricht <33146DC712C0F6197C97C784@[192.168.0.156]>:
I've referenced the underlying bug for years. ITS#8125.
I read the bug, but it's not quite clear what the true reason is. for me I got: modrdn operations, multi-valued attributes with more than one change per second, possibly non-persistent sessionlog. This combination leads to unreliable synchronization.
The situation is when several providers try and do a complete resync with each other at the same time. That situation is not handled well.
Usually you have several layers before that (deltasync, sessionlog, yet more stuff in 2.5) that are well tested.
And it seems the bug isn't fixed yet.
No and there is no way to fix this in 2.4. We're aiming to fix this in 2.5 but aren't there yet.
Couldn't there be a warning at least saying something like "unsafe sync configuration detected. Expüect inconsistent replica"?
The problem only surfaces when two servers get into the same situation at the same time, hard to detect. With multiple providers, you want to use deltasync at this point.
Regards,
openldap-technical@openldap.org
-
kumar rahul -
Ondřej Kuzník -
Quanah Gibson-Mount -
Ulrich Windl