mirror of
https://git.openldap.org/openldap/openldap.git
synced 2025-12-24 16:49:39 -05:00
Saving links to FAQ-O-MATIC content for merging into main docs and work in progress.
This commit is contained in:
Gavin Henry
parent
9ff76148ab
commit
9631c14b3c
4 changed files with 73 additions and 85 deletions
|
|
@ -229,6 +229,10 @@ LDAPv2 is disabled by default.
|
|||
|
||||
H2: LDAP vs RDBMS
|
||||
|
||||
To reference:
|
||||
|
||||
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database
|
||||
http://blogs.sun.com/treydrake/entry/ldap_vs_relational_database_part
|
||||
|
||||
H2: What is slapd and what can it do?
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
H1: Maintenance
|
||||
|
||||
http://www.openldap.org/faq/data/cache/286.html
|
||||
|
||||
|
||||
H2: Directory Backups
|
||||
|
||||
|
|
|
|||
|
|
@ -24,12 +24,68 @@ H4: delta-syncrepl replication
|
|||
H3: Push Based
|
||||
|
||||
|
||||
H5: Replacing Slurpd
|
||||
|
||||
Slurpd replication has been deprecated in favor of Syncrepl replication and
|
||||
has been completely removed from 2.4.
|
||||
|
||||
The slurpd daemon; inherited from UMich's LDAP, operates in
|
||||
push mode: the master pushes changes to the slaves.
|
||||
|
||||
It has been replaced for many reasons, in brief:
|
||||
|
||||
It is not reliable. It is extremely sensitive to the ordering of
|
||||
records in the replog; it can easily go out of sync at which point
|
||||
manual intervention is required to resync the slave database with the
|
||||
master.
|
||||
|
||||
Syncrepl is self-synchronizing; you can start with a database in any
|
||||
state from totally empty to fully sync'd and it will automatically do
|
||||
the right thing to achieve and maintain synchronization.
|
||||
|
||||
Slurpd isn't very tolerant of unavailable servers. If a slave goes down
|
||||
for a long time, the replog may grow to a size that's too large for
|
||||
slurpd to process. Some of these problems are fixable, but there's
|
||||
really no point. Syncrepl covers all the bases slurpd did, plus more.
|
||||
|
||||
* Replication via syncrepl, the LDAP content synchronization operation (LDAP sync, RFC 4533). Introduced in OpenLDAP 2.2, it operates in pull mode: the consumer pulls the updates out of the producer. When used in refreshOnly mode, the producer barely knows it's acting as a master, while the refreshAndPersist mode requires the producer to support persistent searches. Either mode requires the provider and the consumer to support the controls related to the Sync Operation.
|
||||
|
||||
Can you elaborate in a reply to me? I have no
|
||||
> braindead-automatically-attached-policy about e-mail confidentiality :-)
|
||||
|
||||
Sure...
|
||||
|
||||
> I have set up something using slurpd because I understood that using
|
||||
> replsync, the replica would need an access on the master, whereas slurpd
|
||||
> allowed a pure push method, where the replicas have no right to connect to
|
||||
> the master (the master can even be firewalled)
|
||||
|
||||
Syncrepl can operate in either direction. In the pure push/firewall
|
||||
case, just set up a proxy backend as the syncrepl consumer. test045 and
|
||||
test048 in the test suite both demonstrate how to configure this. Those
|
||||
tests are in OpenLDAP 2.4, but you can do something similar in 2.3. You
|
||||
just need to use a separate slapd instance for the consumer in 2.3.
|
||||
|
||||
Just because the protocol was defined a particular way (consumer
|
||||
initiated single master replication) doesn't mean it can't be used in
|
||||
other ways. OpenLDAP is far more flexible than that. We've enhanced the
|
||||
basic syncrepl functionality a number of different ways (delta-syncrepl,
|
||||
proxied syncrepl, mirrormode, and multimaster) all without altering any
|
||||
of the syncrepl protocol definition. All it takes is a little creativity
|
||||
to assemble the pieces in the proper order.
|
||||
|
||||
|
||||
|
||||
|
||||
What was it replaced with?
|
||||
|
||||
Why is Syncrepl better?
|
||||
|
||||
How do I implement a pushed based replication system using Syncrepl?
|
||||
|
||||
H4: Working with Firewalls
|
||||
|
||||
|
||||
H4: Replacing Slurpd
|
||||
|
||||
|
||||
H2: Replication Types
|
||||
|
||||
|
||||
|
|
@ -41,6 +97,10 @@ H3: delta-syncrepl replication
|
|||
|
||||
H3: N-Way Multi-Master
|
||||
|
||||
http://www.connexitor.com/blog/pivot/entry.php?id=105#body
|
||||
http://www.openldap.org/lists/openldap-software/200702/msg00006.html
|
||||
http://www.openldap.org/lists/openldap-software/200602/msg00064.html
|
||||
|
||||
|
||||
H3: MirrorMode
|
||||
|
||||
|
|
|
|||
|
|
@ -4,87 +4,9 @@
|
|||
|
||||
H1: Performance Tuning
|
||||
|
||||
Note: this chapter needs to be updated to discuss BDB tuning.
|
||||
Link for merging content into this chapter:
|
||||
|
||||
There are several things you can do to tune the performance of
|
||||
slapd for your system. Most of them have to do with the LDBM
|
||||
backend. LDBM uses an index mechanism to store and retrieve
|
||||
information in slapd. Each entry is assigned a unique ID, used to
|
||||
refer to the entry in the indexes. A search for entries with a
|
||||
surname of "Jensen", for example, would look up the index entry
|
||||
"=JENSEN" in the surname index. The data returned is a list of
|
||||
IDs of entries having that value for the surname attribute. We
|
||||
have found several things to be useful in improving the
|
||||
performance of this indexing scheme, especially on modify
|
||||
operations.
|
||||
|
||||
|
||||
|
||||
H2: The allIDs threshold
|
||||
|
||||
Some index entries become so large as to be useless. For
|
||||
example, if every entry in your database is a person entry, the
|
||||
"=PERSON" index entry in the objectclass index contains every
|
||||
entry. This returns very little useful information, and can cause
|
||||
significant delays, especially on updates. To alleviate this
|
||||
problem, we have introduced the idea of an allIDs index entry.
|
||||
|
||||
The allIDs entry stands for a real index entry containing the IDs
|
||||
of every entry in the database, but it takes up very little space,
|
||||
never needs updating, and can be manipulated quickly and
|
||||
efficiently. The trade-off is that it does not prune the set of
|
||||
candidate entries at all during a search. This must be done
|
||||
using other, more "high-powered" index entries.
|
||||
|
||||
You can set the minimum number of IDs that an index entry may
|
||||
contain before it turns into an allIDs block by changing the
|
||||
{{EX: SLAPD_LDBM_MIN_MAXIDS}} variable in the
|
||||
{{EX: include/ldapconfig.h}} file. The actual number is determined at
|
||||
runtime by the LDBM backend, depending on the block size of
|
||||
the underlying device (i.e., the number you provide is rounded up
|
||||
to the nearest multiple of a block size).
|
||||
|
||||
|
||||
|
||||
H2: The entry cache
|
||||
|
||||
The LDBM backend can be configured to keep a cache of
|
||||
entries in memory. Since the LDBM database spends much of its
|
||||
time reading entries from the id2entry file into memory, this cache
|
||||
can greatly speed performance. The trade-off is that the cache
|
||||
uses some extra memory. The default cache size is 1000
|
||||
entries. See the discussion of the cachesize option in Section
|
||||
5.2.3 on LDBM configuration.
|
||||
|
||||
|
||||
|
||||
H2: The DB cache
|
||||
|
||||
The LDBM backend uses a number of disk-based index files. If
|
||||
the underlying hash or B-tree package supports in-memory
|
||||
caching of these files, performance can be greatly improved,
|
||||
especially on modifies. The size of this in-memory file cache is
|
||||
given by the dbcachesize option, discussed in more detail in
|
||||
section 5.2.3 on LDBM configuration. The default {{EX: dbcachesize}} is
|
||||
100K.
|
||||
|
||||
|
||||
|
||||
H2: Maintain the right indices
|
||||
|
||||
Finally, one of the best performance tune-ups you can do is to
|
||||
make sure you are maintaining the right indices. Too few indices
|
||||
can lead to poor search performance. Too many indices can
|
||||
lead to poor update performance. For example, the LDBM
|
||||
backend would be perfectly happy to maintain substring and
|
||||
approximate indices for the {{EX: objectclass attribute}}, but this would
|
||||
not be useful and would just slow down update operations. If
|
||||
your database has many entries and is handling queries for
|
||||
substring equality on the surname attribute, you should make
|
||||
sure to maintain a surname substring index so these queries are
|
||||
answered quickly.
|
||||
|
||||
So, take a look at the index lines in your slapd configuration file to
|
||||
ensure that only those indices that make sense and are needed
|
||||
are being maintained.
|
||||
http://www.openldap.org/faq/data/cache/190.html
|
||||
http://www.connexitor.com/blog/pivot/entry.php?id=103#body
|
||||
http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/17c5c0b94ad1fc58/f870758659375718?lnk=gst&q=hyc&rnum=12&hl=en#f870758659375718
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue