From: Gavin Henry Date: Mon, 18 Jun 2007 23:01:15 +0000 (+0000) Subject: Saving links to FAQ-O-MATIC content for merging into main docs and work in progress. X-Git-Tag: OPENLDAP_REL_ENG_2_4_MP~378 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=9631c14b3c3674f07cb4ba3b09c9c1638f947246;p=openldap Saving links to FAQ-O-MATIC content for merging into main docs and work in progress. --- diff --git a/doc/guide/admin/intro.sdf b/doc/guide/admin/intro.sdf index 988d4f402c..6ddf96640f 100644 --- a/doc/guide/admin/intro.sdf +++ b/doc/guide/admin/intro.sdf @@ -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? diff --git a/doc/guide/admin/maintenance.sdf b/doc/guide/admin/maintenance.sdf index ad265104fb..9514586526 100644 --- a/doc/guide/admin/maintenance.sdf +++ b/doc/guide/admin/maintenance.sdf @@ -4,6 +4,8 @@ H1: Maintenance +http://www.openldap.org/faq/data/cache/286.html + H2: Directory Backups diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 179bd9df5c..3962fb96e0 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -24,10 +24,66 @@ H4: delta-syncrepl replication H3: Push Based -H4: Working with Firewalls +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. -H4: Replacing Slurpd +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 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 diff --git a/doc/guide/admin/tuning.sdf b/doc/guide/admin/tuning.sdf index af73744755..5e3f9735a1 100644 --- a/doc/guide/admin/tuning.sdf +++ b/doc/guide/admin/tuning.sdf @@ -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