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
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
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
projects / openldap / commitdiff