overlay. The Syncprov overlay works with any number of consumers over a single
database or over arbitrarily many glued databases.
-H3: N-Way Multimaster Replication
+H3: N-Way Multiprovider Replication
As a consequence of the work to support multiple consumer contexts, the syncrepl
-system now supports full N-Way multimaster replication with entry-level conflict
+system now supports full N-Way multiprovider replication with entry-level conflict
resolution. There are some important constraints, of course: In order to maintain
consistent results across all servers, you must maintain tightly synchronized
clocks across all participating servers (e.g., you must use NTP on all servers).
The entryCSNs used for replication now record timestamps with microsecond resolution,
-instead of just seconds. The delta-syncrepl code has not been updated to support
-multimaster usage yet, that will come later in the 2.4 cycle.
+instead of just seconds.
H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
single {{slapd}} installation just doesn't provide the necessary availability
or reliability. For extremely demanding environments where a
single point of failure is not acceptable, {{multi-provider}} replication
-is also available. {{slapd}} includes support for {{LDAP Sync}}-based
+is also available. With {{multi-provider}} replication two or more nodes can
+accept write operations allowing for redundancy at the provider level.
+
+{{slapd}} includes support for {{LDAP Sync}}-based
replication.
{{B:Proxy Cache}}: {{slapd}} can be configured as a caching
accepted directory updates from other clients, and a slave only
accepted updates from a (single) master. The replication structure
was rigidly defined and any particular database could only fulfill
-a single role, either master or slave.
+a single role, either master or slave. Another historic term introduced
+with OpenLDAP 2.4 was multimaster.
As OpenLDAP now supports a wide variety of replication topologies, these
-terms have been deprecated in favor of {{provider}} and
-{{consumer}}: A provider replicates directory updates to consumers;
-consumers receive replication updates from providers. Unlike the
-rigidly defined master/slave relationships, provider/consumer roles
-are quite fluid: replication updates received in a consumer can be
-further propagated by that consumer to other servers, so a consumer
-can also act simultaneously as a provider. Also, a consumer need not
+terms have been deprecated in favor of {{provider}}/{{multi-provider}} and
+{{consumer}}: A provider can accept external write operations and make them
+available for retrieval by consumers; consumers request replication updates from
+providers. Unlike the rigidly defined master/slave relationships,
+provider/consumer roles are quite fluid: replication updates received in a
+consumer can be further propagated by that consumer to other servers, so a
+consumer can also act simultaneously as a provider. Also, a consumer need not
be an actual LDAP server; it may be just an LDAP client.
The following sections will describe the replication technology and
projects / thirdparty / openldap.git / commitdiff
