From 53d4a46898e8c91595af0acd9b5e31464c2278cd Mon Sep 17 00:00:00 2001 From: Joyce Fee Date: Thu, 19 Dec 2024 12:57:11 -0500 Subject: [PATCH] Doc-108 Update multi-region section of HA docs --- modules/deploy/partials/high-availability.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/deploy/partials/high-availability.adoc b/modules/deploy/partials/high-availability.adoc index 7cd1ebc4b..a47fc8963 100644 --- a/modules/deploy/partials/high-availability.adoc +++ b/modules/deploy/partials/high-availability.adoc @@ -109,9 +109,9 @@ endif::[] === Multi-region deployment -A multi-region deployment is similar to a multi-AZ deployment, in that it needs at least three regions to counter the loss of a single region. Note that this deployment strategy increases latency due to the physical distance between regions. Consider the following strategies to mitigate this problem: +A multi-region deployment is similar to a multi-AZ deployment, in that it needs at least three regions to counter the loss of a single region. Note that this deployment strategy increases latency due to the physical distance between regions. In addition to higher produce and end-to-end latency and increased costs, multi-region deployments require careful tuning. Redpanda recommends that you work closely with Redpanda’s Customer Success team when implementing a multi-region deployment. Also consider the following strategies to mitigate these challenges: -* Manually configure leadership of each partition to ensure that leaders are congregated in the primary region (closest to the producers and consumers). +* Configure xref:develop:produce-data/leader-pinning.adoc#configure-leader-pinning[leader pinning] to ensure that topic partition leaders are geographically closer to clients. This can help lower network costs and latency by routing produce requests to brokers located in specific AZs. * If your produce latency exceeds your requirements, you can configure producers to have `acks=1` instead of `acks=all`. This reduces latency by only waiting for the leader to acknowledge, rather than waiting for all brokers to respond. However, using this configuration can decrease message durability. If the partition leader goes offline, you may lose any messages that are acknowledged but not yet replicated. === Multi-cluster deployment