This is an automated email from the ASF dual-hosted git repository.
mimaison pushed a commit to branch markdown
in repository https://gitbox.apache.org/repos/asf/kafka-site.git
The following commit(s) were added to refs/heads/markdown by this push:
new 533a73b348 Add back negation that was lost in rewrite (#879)
533a73b348 is described below
commit 533a73b34819abed2b03499ba10343fb2f766261
Author: Titouan Teyssier <[email protected]>
AuthorDate: Wed Jun 24 10:37:22 2026 +0200
Add back negation that was lost in rewrite (#879)
Before version 40 the text was:
```
It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency both for Kafka writes and ZooKeeper writes, and neither
Kafka nor ZooKeeper will remain available in all locations if the network
between locations is unavailable.
```
The negation got lost when removing Zookeeper from that paragraph.
Co-authored-by: Titouan Teyssier <[email protected]>
Reviewers: Mickael Maison <[email protected]>
---
content/en/40/operations/datacenters.md | 2 +-
content/en/41/operations/datacenters.md | 2 +-
content/en/42/operations/datacenters.md | 2 +-
content/en/43/operations/datacenters.md | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/content/en/40/operations/datacenters.md
b/content/en/40/operations/datacenters.md
index 7d1b1b5571..3855e05a71 100644
--- a/content/en/40/operations/datacenters.md
+++ b/content/en/40/operations/datacenters.md
@@ -36,4 +36,4 @@ This is not the only possible deployment pattern. It is
possible to read from or
Kafka naturally batches data in both the producer and consumer so it can
achieve high-throughput even over a high-latency connection. To allow this
though it may be necessary to increase the TCP socket buffer sizes for the
producer, consumer, and broker using the `socket.send.buffer.bytes` and
`socket.receive.buffer.bytes` configurations. The appropriate way to set this
is documented [here](https://en.wikipedia.org/wiki/Bandwidth-delay_product).
-It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will remain available in all
locations if the network between locations is unavailable.
+It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will not remain available in
all locations if the network between locations is unavailable.
diff --git a/content/en/41/operations/datacenters.md
b/content/en/41/operations/datacenters.md
index 7d1b1b5571..3855e05a71 100644
--- a/content/en/41/operations/datacenters.md
+++ b/content/en/41/operations/datacenters.md
@@ -36,4 +36,4 @@ This is not the only possible deployment pattern. It is
possible to read from or
Kafka naturally batches data in both the producer and consumer so it can
achieve high-throughput even over a high-latency connection. To allow this
though it may be necessary to increase the TCP socket buffer sizes for the
producer, consumer, and broker using the `socket.send.buffer.bytes` and
`socket.receive.buffer.bytes` configurations. The appropriate way to set this
is documented [here](https://en.wikipedia.org/wiki/Bandwidth-delay_product).
-It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will remain available in all
locations if the network between locations is unavailable.
+It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will not remain available in
all locations if the network between locations is unavailable.
diff --git a/content/en/42/operations/datacenters.md
b/content/en/42/operations/datacenters.md
index 7d1b1b5571..3855e05a71 100644
--- a/content/en/42/operations/datacenters.md
+++ b/content/en/42/operations/datacenters.md
@@ -36,4 +36,4 @@ This is not the only possible deployment pattern. It is
possible to read from or
Kafka naturally batches data in both the producer and consumer so it can
achieve high-throughput even over a high-latency connection. To allow this
though it may be necessary to increase the TCP socket buffer sizes for the
producer, consumer, and broker using the `socket.send.buffer.bytes` and
`socket.receive.buffer.bytes` configurations. The appropriate way to set this
is documented [here](https://en.wikipedia.org/wiki/Bandwidth-delay_product).
-It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will remain available in all
locations if the network between locations is unavailable.
+It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will not remain available in
all locations if the network between locations is unavailable.
diff --git a/content/en/43/operations/datacenters.md
b/content/en/43/operations/datacenters.md
index 7d1b1b5571..3855e05a71 100644
--- a/content/en/43/operations/datacenters.md
+++ b/content/en/43/operations/datacenters.md
@@ -36,4 +36,4 @@ This is not the only possible deployment pattern. It is
possible to read from or
Kafka naturally batches data in both the producer and consumer so it can
achieve high-throughput even over a high-latency connection. To allow this
though it may be necessary to increase the TCP socket buffer sizes for the
producer, consumer, and broker using the `socket.send.buffer.bytes` and
`socket.receive.buffer.bytes` configurations. The appropriate way to set this
is documented [here](https://en.wikipedia.org/wiki/Bandwidth-delay_product).
-It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will remain available in all
locations if the network between locations is unavailable.
+It is generally _not_ advisable to run a _single_ Kafka cluster that spans
multiple datacenters over a high-latency link. This will incur very high
replication latency for Kafka writes, and Kafka will not remain available in
all locations if the network between locations is unavailable.
