2.10. Требования к катастрофоустойчивому кластеру
- 2.10.1. Основные понятия и сокращения
- 2.10.2. Общее описание решения
- 2.10.3. Управление
- 2.10.4. Ключи etcd
- 2.10.5.
WAL-sync monitor
- 2.10.6. Топология репликации
- 2.10.7. Требования к оборудованию и сети
- 2.10.8. Механизмы репликации
- 2.10.9. Мониторинг и управление
- 2.10.10. Безопасность
- 2.10.11. Тестирование и откат
- 2.10.12. Резервное копирование в рамках георезервирования
- 2.10.13. Документация и регламенты
- 2.10.2. Общее описание решения
Описываемая функциональность находится в разработке. Для внедрения в промышленную эксплуатацию обратитесь в поддержку.
2.10.1. Основные понятия и сокращения
БД – база данных.
СУБД – система управления базами данных
ЦОД – центр обработки данных.
ОЦОД – основной центр обработки данных.
РЦОД – резервный центр обработки данных.
ОУК – отказоустойчивый кластер.
КУК — катастрофоустойчивый кластер.
2.10.2. Общее описание решения
В ОЦОД заказчика размещаются основные сегменты кластера и кластер etcd. Сегмент представляет собой отказоустойчивый кластер из двух узлов с экземплярами СУБД Postgres Pro, один из которых в режиме ведущего, а другой в режиме синхронного резервного. На каждом узле сегмента запущена служба shardmand, которая проверяет экземпляры СУБД Postgres Pro и обменивается информацией с кластером etcd, обеспечивая кластеризацию Shardman. Кластер etcd состоит из трёх узлов, тем самым обеспечивая кворум.
Для обеспечения катастрофоустойчивости в РЦОД заказчика размещается кластер с идентичной конфигурацией и набором компонентов. По умолчанию узлы СУБД резервного кластера Shardman выключены. Непрерывная доставка журналов из ОЦОД в РЦОД осуществляется в асинхронном режиме. При этом используется протокол физической репликации с помощью утилиты pg_receivewal из стандартной поставки СУБД Shardman. Она записывает WAL в стандартный каталог экземпляра $PGDATA/pg_wal
. Управление утилитой обеспечивается кластерным программным обеспечением. Узлы СУБД резервного кластера Shardman запускаются службой shardmand, когда обнаруживается точка синхронизации в резервном etcd кластере, в результате чего осуществляется синхронизация изменений WAL до LSN, полученного из точки синхронизации. Кластеры etcd в разных ЦОД изолированы друг от друга, в связи с этим передача информации о появлении новой точки синхронизации осуществляется скриптом периодически на стороне ОЦОД в etcd РЦОД.
Обратите внимание, что для ведущего кластера параметр syncPointMonitorEnabled
должен иметь значение true
.
2.10.3. Управление
КУК управляется через утилиту shardmanctl с помощью следующих команд: shardmanctl cluster standby enable, shardmanctl cluster standby disable, shardmanctl cluster standby catchup, shardmanctl config update --from-primary-cluster.
2.10.4. Ключи etcd
Ключ shardman/<cluster_name>/data/lsns/<shard_name>/<node_address>
etcd содержит список LSN для контрольной точки экземпляра кластера.
[ "0/60085F0", "0/8E67C98", "0/8E59148", "0/8E49CF8", "0/8E3AC50" ]
Ключ shardman/<cluster_name>/data/syncpoints
etcd содержит список точек синхронизации. Для резервных кластеров его необходимо скопировать с ведущего кластера.
[ { "time": "2025-07-25T10:52:45.548891626Z", "CSN": 1753440765536815000, "LSNs": { "1": "0/8E3AC50", "2": "0/E96FC60" } }, { "time": "2025-07-25T10:51:45.560671484Z", "CSN": 1753440705541502000, "LSNs": { "1": "0/60085F0", "2": "0/6009268" } } ]
Ключ shardman/<cluster_name>/data/wal-sync-state
etcd выводит последнюю точку синхронизации, содержащую все сегменты WAL со всеми необходимыми LSN.
{ "lastUpdated": "2025-07-25T10:55:11.644732497Z", "targetSyncpoint": { "time": "2025-07-25T10:51:45.560671484Z", "CSN": 1753440705541502000, "LSNs": { "1": "0/60085F0", "2": "0/6009268" } } }
Ключ shardman/<cluster_name>/data/last-replay-lsn/<shard_name>/<node_address>
etcd выводит последний применённый LSN и соответствующий ему CSN точки синхронизации.
{ "LSN": "0/6008648", "SyncpointCSN": "1753440705541502000", "UpdatedTime": "2025-07-25T10:54:15.40782001Z" }
2.10.5. WAL-sync monitor
На резервном кластере есть специальный WAL-sync monitor
, который собирает информацию о входящих с ведущего кластера точках синхронизации. Он также проверяет наличие всех LSN в полученных сегментах WAL. Если всё в порядке, он создаёт запись в etcd о новой успешной точке синхронизации для резервного кластера.
2.10.6. Топология репликации
Потоковая физическая репликация обеспечивается в следующих случаях:
Между узлами СУБД Postgres Pro сегменты в ОЦОД обеспечивается синхронная потоковая физическая репликация
Между узлами сегментов СУБД Postgres Pro в РЦОД обеспечивается синхронная потоковая физическая репликация
Между узлами сегментов СУБД Postgres Pro разных ЦОД обеспечивается асинхронная потоковая физическая репликация
2.10.7. Требования к оборудованию и сети
В ОЦОД и РЦОД оборудование должно быть идентичным по системным ресурсам и конфигурации для всех компонентов катастрофоустойчивого кластера.
Связанность сети между ЦОД должна обеспечиваться прямой оптоволоконной линией. Пропускная способность канала должна быть не менее 20 Гбит/с. Также необходимо предусмотреть резервный канал.
2.10.8. Механизмы репликации
Для обеспечения работы ОУК/КУК Shardman используется встроенный в Postgres Pro протокол потоковой физической репликации. Репликация на РЦОД асинхронная.
Автоматическое восстановление ОУК Shardman после сбоя обеспечивается кластерным программным обеспечением.
Восстановление КУК после сбоя предусмотрено только в ручном полуавтоматическом режиме.
2.10.9. Мониторинг и управление
Мониторинг и управление кластером Shardman в рамках ЦОДа обеспечивается с помощью утилиты shardmanctl.
Для получения статуса кластера, работающего в режиме резерва, выполните команду shardmanctl status.
2.10.10. Безопасность
2.10.10.1. Шифрование данных при передаче (TLS/SSL)
Требуется обеспечить защищённый канал между ЦОДами.
2.10.10.2. Аутентификация и авторизация между узлами
Аутентификация между узлами обеспечивается штатными средствами СУБД Postgres Pro.
2.10.10.3. Защита от несанкционированного доступа к резервным серверам
Защита от несанкционированного доступа к резервным серверам обеспечивается средствами ОС и сети.
2.10.11. Тестирование и откат
Рекомендуется периодически производить тестовое переключение.
2.10.11.1. Проверка целостности данных после аварийного переключения
Проверка целостности данных после аварийного переключения обеспечивается утилитой резервного копирования shardmanctl probackup
.
2.10.11.2. Переключение на РЦОД
При отказе основного ЦОД, администратор убеждается в его недоступности и инициирует процедуру повышения резервных узлов до состояния рабочих. Для этого резервный кластер переводится из режима standby
в режим master
. Данная операция осуществляются централизованно с помощью командной утилиты shardmanctl, никаких дополнительных ручных операций не требуется.
2.10.11.3. Восстановление ОЦОД
Для восстановления географически удалённых узлов в ОЦОД требуется создать резервную копию основного кластера и восстановить её на данные узлы. Резервная копия может быть создана любым способом – холодная РК, РК с использованием репозитория pg_probackup. Каждый из этих способов подразумевает перенос резервной копии в ОЦОД. После восстановления каталога БД из резервной копии, запускается pg_receivewal, который подключается к специально созданному слоту репликации ведущего или резервного сегмента в РЦОД и начинает приём WAL сегментов в асинхронном режиме, записывая их сразу в каталог $PGDATA/pg_wal
основного узла.
На кластере РЦОД раз в заданный интервал времени скриптом создаётся точка синхронизации, которая записывается в etcd РЦОД, а также отправляется в etcd ОЦОД. Узлы резервного кластера в ОЦОД при появлении записи о точке синхронизации в etcd проверяют, получен ли WAL, содержащий данную запись. При наличии записи в WAL на всех узлах резервного кластера в ОЦОД кластерным ПО выполняется запуск сервера СУБД в режиме восстановления с проигрыванием журналов до точки синхронизации. По достижении резервным узлом точки синхронизации применение WAL останавливается, производится проверка, что все узлы успешно применили записи, после чего сервер СУБД останавливается и повторяются цикл получения WAL, проверки наличия точки синхронизации, запуск СУБД в режиме восстановления.
2.10.11.4. Переключение обратно на ОЦОД
Чтобы переключиться обратно на ОЦОД, создаётся и переносится резервная копия кластера из РЦОД в ОЦОД, запускаются узлы в режиме резерва, после получения недостающих WAL происходит выключение узлов кластера в РЦОД и повышение узлов кластера в основном ЦОД.
2.10.12. Резервное копирование в рамках георезервирования
В рамках географически распределённой системы для кластера РЦОД необходимо предусмотреть аналогичное хранилище резервных копий, как и для ОЦОД, а также настроить регулярную синхронизацию основного хранилища в резервное.
2.10.12.1. Хранение резервных копий в географически распределенных хранилищах
Глубина хранения резервных копий определяется политикой резервного копирования.
2.10.13. Документация и регламенты
За более подробной информацией по аварийному переключению и инструкциями по штатному переключению обратитесь в поддержку Prostres Pro.