Высокая доступность с несколькими центрами обработки данных

примечание

Эта страница переведена при помощи нейросети GigaChat.

Высокая доступность кластера PostgreSQL, развернутого в нескольких дата-центрах, основана на репликации, которая может быть синхронной или асинхронной (режимы репликации).

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

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

Синхронная репликация

Чтобы иметь мульти-дата-центровый кластер, способный автоматически выдерживать падение зоны, требуется минимум 3 узла.

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

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

Что касается Postgres, необходимо развернуть как минимум 2 узла в разных дата-центрах. Затем необходимо установить synchronous_mode: true в глобальной динамической конфигурации.

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

Асинхронная репликация

При наличии только двух дата-центров лучше иметь два независимых кластера etcd и запускать Patroni резервный кластер во втором дата-центре. Если первый сайт недоступен, можно ВРУЧНУЮ повысить standby_cluster.

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

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

В этом сценарии не следует использовать pg_ctl promote, нужно «вручную повысить» здоровый кластер, удалив раздел standby_cluster из динамической конфигурации.

warning

Если исходный кластер все еще работает, и был повышен резервный кластер, возникнет ситуация split-brain.

В случае необходимости возврата к «исходному» состоянию, есть только два способа решения:

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

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

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

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