From cebe3b3e9d4658e6e7fb30192be0c4ac1dab37ae Mon Sep 17 00:00:00 2001 From: Gavin Henry Date: Mon, 18 Aug 2008 15:09:00 +0000 Subject: [PATCH] To do list review: small typo quick fix. --- doc/guide/admin/replication.sdf | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) 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