Commit 278eadd9 authored by Quanah Gibson-Mount's avatar Quanah Gibson-Mount
Browse files

More for ITS#9275 and term cleanup

parent ad85956d
......@@ -79,17 +79,16 @@ of the database may in turn be provided to other consumers using the Syncprov
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}})
......
......@@ -441,7 +441,10 @@ replication scheme is vital in high-volume environments where a
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
......
......@@ -13,16 +13,17 @@ a {{master}} server and some number of {{slave}} servers. A master
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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment