intervalWalSyncArbiterДанный раздел описывает работу катастрофоустойчивого кластера, который обеспечивает более высокий уровень отказоустойчивости.
БД — база данных.
СУБД — система управления базами данных.
ЦОД — центр обработки данных.
ОЦОД – основной центр обработки данных.
РЦОД — резервный центр обработки данных.
ОУК — отказоустойчивый кластер.
КУК — катастрофоустойчивый кластер.
В ОЦОД находятся сегменты ведущего кластера. Сегменты являются отказоустойчивыми кластерами, состоящими из двух узлов экземпляров СУБД Postgres Pro, один из которых ведущий, второй— синхронный резервный. На каждом сегменте запущен демон shardmand, который проверяет экземпляры СУБД Postgres Pro.
Для обеспечения катастрофоустойчивости в РЦОД заказчика размещается кластер с идентичной конфигурацией и набором компонентов. По умолчанию узлы СУБД резервного кластера Shardman выключены. Непрерывная доставка журналов из ОЦОД в РЦОД осуществляется в асинхронном режиме. При этом используется протокол физической репликации с помощью утилиты pg_receivewal из стандартной поставки СУБД Shardman. Она записывает WAL в стандартный каталог экземпляра $PGDATA/pg_wal. Управление утилитой обеспечивается кластерным программным обеспечением. РЦОД взаимодействует с хранилищем ОЦОД, получает информацию об обновлениях конфигурации ОЦОД и применяет их. Точки синхронизации рассчитываются по эвристическому алгоритму, который анализирует WAL pg_receivewal. Это позволяет рассчитать возможные распределённые точки согласованности.
КУК управляется через утилитуh shardmanctl с помощью следующих команд: shardmanctl cluster standby enable, shardmanctl cluster standby disable, shardmanctl cluster standby catchup, shardmanctl config update --from-primary-cluster.
Обратите внимание, что команду shardmanctl probackup restore можно использовать для развёртывания резервного кластера на основании резервной копии ведущего кластера с помощью указания --backup-path для пути резервной копии из центра обработки данных. В таком случае не будет поддерживаться использование параметров путь--schema-only, metadata-only, а также восстановление одного сегмента. Резервный кластер должен находиться в режиме standby на момент выполнения восстановления. По завершении команды при отставании от кластера ОЦОД необходимо запустить команду shardmanctl cluster standby catchup.
intervalWalSyncArbiter #keeper в РЦОД рассчитывает возможные точки синхронизации, после чего процесс intervalWalSyncArbiter выбирает ту, которую можно применить ко всем экземплярам, и запускает синхронизацию до выбранной точки синхронизации.
Потоковая физическая репликация обеспечивается в следующих случаях:
Между узлами сегментов СУБД Postgres Pro в ОЦОД (синхронная)
Между узлами сегментов СУБД Postgres Pro в РЦОД (синхронная)
Между узлами сегментов СУБД Postgres Pro разных ЦОД (асинхронная)
В ОЦОД и РЦОД оборудование должно быть идентичным по системным ресурсам и конфигурации для всех компонентов катастрофоустойчивого кластера.
Связанность сети между ЦОД должна обеспечиваться прямой оптоволоконной линией. Пропускная способность канала должна быть не менее 20 Гбит/с. Также необходимо предусмотреть резервный канал.
Для обеспечения ОУК/КУК Shardmanиспользуется встроенный в Postgres Pro протокол потоковой физической репликации. Репликация на РЦОД асинхронная.
Автоматический восстановление ОУК Shardman после сбоя обеспечивается кластерным программным обеспечением.
Восстановление КУК после сбоя предусмотрено только в ручном полуавтоматическом режиме.
Мониторинг и управление кластером Shardman в рамках ЦОДа обеспечивается с помощью утилиты shardmanctl.
Узнать статус кластера в режиме резерва можно с помощью команды shardmanctl cluster status.
Требуется обеспечить защищённый канал между ЦОДами.
Аутентификация между узлами обеспечивается штатными средствами СУБД Postgres Pro.
Защита от несанкционированного доступа к резервным серверам обеспечивается средствами ОС и сети.
Рекомендуется периодически производить тестовое переключение.
Проверка целостности данных после аварийного переключения обеспечивается утилитой резервного копирования shardmanctl probackup.
При отказе основного ЦОД, администратор убеждается в его недоступности и инициирует процедуру повышения резервных узлов в состояние рабочих. Для этого, резервный кластер переводится из режима standby в режим master. Данная операция осуществляются централизованно с помощью командной утилиты shardmanctl, никаких дополнительных ручных операций не требуется.
Для восстановления географически удалённых узлов в ОЦОД требуется создать резервную копию основного кластера и восстановить её на данные узлы. Резервная копия может быть создана любым способом – холодная РК, РК с использованием репозитория pg_probackup. Каждый из этих способов подразумевает перенос резервной копии в ОЦОД. После восстановления каталога БД из резервной копии, запускается pg_receivewal, который подключается к специально созданному слоту репликации ведущего или резервного сегмента в РЦОД и начинает приём WAL сегментов в асинхронном режиме, записывая их сразу в каталог $PGDATA/pg_wal основного узла.
В кластере РЦОД скрипт создаёт точку синхронизации для каждого заданного периода времени. Она записывается во встроенное хранилище РЦОД и отправляется в хранилище ОЦОД. Когда точка синхронизации туда попадает, узлы резервного кластера ОЦОД проверяют наличие WAL с такой записью. При её получении всеми узлами резервного кластера ОЦОД кластерным ПО инициируется запуск сервера СУБД с синхронизацией WAL до точки синхронизации. По её достижении WAL больше не применяются. Если все узлы успешно применили записи WAL, сервер СУБД останавливается, запускается новый цикл получения WAL, проверки точки синхронизации и режима восстановления.
Чтобы переключиться обратно на ОЦОД, создаётся и переносится резервная копия кластера из РЦОД в ОЦОД, запускаются узлы в режиме резерва, после получения недостающих WAL происходит выключение узлов кластера в РЦОД и повышение узлов кластера в основном ЦОД.
В рамках географически распределённой системы для кластера РЦОД необходимо предусмотреть аналогичное хранилище резервных копий, как и для ОЦОД, а также настроить регулярную синхронизацию основного хранилища в резервное.
Глубина хранения резервных копий определяется политикой резервного копирования.