# HA-кластер с несколькими центрами обработки данных

> Многоцентровые схемы обеспечения высокой доступности с репликацией Patroni.

---

Индекс LLMS: [llms.txt](/ru/llms.txt)

---

<a id="ha_multi_dc"></a>
Высокая доступность кластера PostgreSQL, развернутого в нескольких центрах обработки данных, основана на репликации, которая может быть синхронной или асинхронной (см. [режимы репликации](/ru/docs/patroni/replication_modes#replication_modes)).

В обоих случаях важно четко понимать следующие понятия:

- PostgreSQL может работать в качестве первичного сервера или резервного сервера-лидера только тогда, когда он владеет ключом лидера и может обновлять этот ключ.
- Рекомендуется запускать нечётное количество узлов etcd, ZooKeeper или Consul: 3 или 5!

--------

## Синхронная репликация {#synchronous-replication}

Для создания кластера с несколькими ЦО, способного автоматически переживать отказ зоны, требуется как минимум 3.

Схема архитектуры будет следующей:

![образ](/img/docs/patroni/multi-dc-synchronous-replication.png)

Необходимо развернуть кластер etcd, ZooKeeper или Consul через разные зоны доступности, с минимальным количеством 3 узлов, по одному в каждой зоне.

Что касается postgres, необходимо развернуть не менее 2 узлов в разных ЦОД. Затем следует задать `synchronous_mode: true` в глобальной [динамической конфигурации](/ru/docs/patroni/config/dynamic#dynamic).

Это включает синхронную репликацию, при этом первичный сервер выберет один из узлов в качестве синхронного.

--------

## Асинхронная репликация {#asynchronous-replication}

При наличии только двух центров обработки данных предпочтительнее иметь два независимых кластера etcd и запускать в втором центре обработки данных резервный сервер Patroni [standby cluster](/ru/docs/patroni/standby_cluster#standby_cluster). Если первый сайт выйдет из строя, вы можете MANUALLY вручную повысить привилегии [standby_cluster](/ru/docs/patroni/standby_cluster#standby_cluster).

Схема архитектуры будет следующей:

![образ](/img/docs/patroni/multi-dc-asynchronous-replication.png)

Автоматическое повышение невозможна, поскольку DC2 никогда не сможет определить состояние DC1.

В этом сценарии следует не использовать `pg_ctl promote`, необходимо вручную повысить приоритет работоспособного кластера, удалив раздел [standby_cluster](/ru/docs/patroni/standby_cluster#standby_cluster) из [динамической конфигурации](/ru/docs/patroni/config/dynamic#dynamic).

> [!WARNING]
> Если исходный кластер по-прежнему работает, а вы повышаете резервный сервер до основного, возникает состояние split-brain.

В случае, если вы хотите вернуться в «исходное» состояние, существует только два способа его устранения:

- Добавьте секцию standby_cluster обратно — это вызовет `pg_rewind`; однако для корректной работы `pg_rewind` кластер должен быть инициализирован с использованием `data page checksums` (опция `--data-checksums` для `initdb`) и/или значение `wal_log_hints` должно быть установлено в `on`, но даже при этом возможны случаи сбоя `pg_rewind` из-за других факторов.
- Перестройте резервный сервер с нуля.

Перед повышением резервного сервера в кластере необходимо вручную убедиться, что исходный кластер выключен (STONITH). Когда DC1 восстановится, кластер должен быть преобразован в резервный сервер.

Перед выполнением этого действия вы можете вручную проанализировать базу данных и извлечь все изменения, произошедшие между моментом, когда сеть между DC1 и DC2 перестала работать, и моментом, когда вы вручную остановили кластер в DC1.

После извлечения вы также можете вручную применить эти изменения к кластеру в DC2.