From 3b32982c7c7823af5ad960f61b572915ecb65f4d Mon Sep 17 00:00:00 2001 From: Titouan Teyssier Date: Mon, 15 Jun 2026 15:56:29 +0200 Subject: [PATCH] Add back negation that was lost in rewrite 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. --- 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 7d1b1b55717..3855e05a716 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 7d1b1b55717..3855e05a716 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 7d1b1b55717..3855e05a716 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 7d1b1b55717..3855e05a716 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.