From: Gavin Henry Date: Mon, 18 Aug 2008 15:09:00 +0000 (+0000) Subject: To do list review: small typo quick fix. X-Git-Tag: ACLCHECK_0~1419 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=cebe3b3e9d4658e6e7fb30192be0c4ac1dab37ae;p=openldap To do list review: small typo quick fix. --- diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 3f7690499a..6c7eb6e623 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -544,15 +544,14 @@ H3: Delta-syncrepl replication OpenLDAP's syncrepl replication is an object-based replication mechanism. When any attribute value in a replicated object is changed on the provider, -each consumer fetches and processes the complete changed object {B:both changed and unchanged attribute values} - during replication. This works well, but has drawbacks in some situations. +each consumer fetches and processes the complete changed object {{B:both changed and unchanged attribute values}} during replication. This works well, but has drawbacks in some situations. For example, suppose you have a database consisting of 100,000 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 100,000 objects on the master. Not counting LDAP and TCP/IP protocol overhead, each time you -run this job each consumer will transfer and process {B:1 GB} of data to process -{B:200KB of changes! } +run this job each consumer will transfer and process {{B:1 GB}} of data to process +{{B:200KB of changes!}} 99.98% of the data that is transmitted and processed in a case like this will be redundant, since it represents values that did not change. This is a waste