Curious what's the rationale of using syncrepl over delta-syncrepl?
We have 40 consumers (5GB data (and using syncrepl) no problems, but was interested in switching.. thought it might be more efficient.
On Sat, Aug 3, 2024, 05:10 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Friday, August 2, 2024 9:15 PM +0000 thomaswilliampritchard@gmail.com wrote:
OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS)
Known issue with OpenLDAP 2.4 series.
We are configured with delta-syncrepl.
I would recommend upgrading to the latest OpenLDAP 2.6 release and switching to standard syncrepl. If you don't want to build OpenLDAP yourself, the Symas packages are what I use in production.
--Quanah
On Sun, Aug 04, 2024 at 09:01:23PM +0200, Erik de Waard wrote:
Curious what's the rationale of using syncrepl over delta-syncrepl?
We have 40 consumers (5GB data (and using syncrepl) no problems, but was interested in switching.. thought it might be more efficient.
Are you talking single-provider or multi-provider (providers are servers that accept write requests)? Single provider is perfectly safe and you can stop reading here. For multi-provider (MPR):
Delta-syncrepl cannot always operate correctly in the face of certain types of conflicting modifications (when you have clients writing incompatible changes to servers A and B at the *same* time). The LDAP data model is just too rich to allow operation-level multi-provider replication in arbitrary circumstances.
You can usually use MPR deltasync if can always guarantee that either: - all writes go to the same provider (until the provider is retired e.g. due to failure), you're back to single-provider, but ensure good monitoring - concurrent writes can be replicated in any order (especially increment, modrdn operations cannot, also see ITS#9341 and related)
Ensuring this in real-life environments turns out more challenging than it seems as people do not seem to have enough control over their clients. The better knowledge of your environment you have (especially through monitoring), the more confidence you'll have whether you can do that.
Regards,
We use Multi Provider Replication however we ensure writes are directed only to one provider at a time.
What is the recommended HA Provider configuration these days? "Mirror Mode" where you just have 2 providers with proxies between clients and consumers? Multi Provider with just proxies in front of clients? Multi provider with no proxies and no delta syncrepl?
It seems there are numerous ways to configure highly available providers, what is recommended for most stability and data consistency?
On Tue, Aug 06, 2024 at 02:37:06PM -0000, thomaswilliampritchard@gmail.com wrote:
We use Multi Provider Replication however we ensure writes are directed only to one provider at a time.
What is the recommended HA Provider configuration these days? "Mirror Mode" where you just have 2 providers with proxies between clients and consumers? Multi Provider with just proxies in front of clients? Multi provider with no proxies and no delta syncrepl?
It seems there are numerous ways to configure highly available providers, what is recommended for most stability and data consistency?
Consumers can follow several providers at the same time so where replication traffic is concerned, that redundancy also gives you HA.
Clients that only ever do writes can be routed to anything, so whatever you go with (lloadd, haproxy, connection pooling,...) will do.
Clients that sometimes want to write need to talk to an arbiter of some sort that consistently points to just one of the providers. That is probably what you were interested in? Depends on where you want to sit between downtime, consistency and complexity: you can use lloadd[0], other proxies with the appropriate configuration or you can go all out and do IP-level clustering so there's no meaningful single point of failure anywhere.
Chaining should also use the same endpoint as write clients.
[0]. To get consistent routing in lloadd, you can rely on reconfiguring olcBkLloadBackendUri when downtime is detected or with a single lloadd you can use a config snippet like this (see man lloadd.conf for details):
---- 8< ---- # we use this one as long as it's reachable *at all* tier roundrobin backen-server uri=primary...
# unless all connections to primary are down, then we use this one tier roundrobin backend-server uri=secondary... ---- 8< ----
openldap-technical@openldap.org
-
Erik de Waard -
Ondřej Kuzník -
thomaswilliampritchard＠gmail.com