Репликация в Managed Service for PostgreSQL
В кластерах Managed Service for PostgreSQL используется кворумная репликация (quorum-based synchronous replication):
-
Среди хостов кластера выбирается мастер, а все остальные хосты становятся репликами.
-
Транзакция считается успешной только в том случае, если ее подтвердили хост-мастер и кворум реплик. Кворум составляет половина всех реплик кластера. Реплики для кворума выбираются случайным образом (кворумные реплики).
Если количество реплик нечетное, значение округляется вниз, кроме случая с одной репликой. Например, в кластере с 17 репликами для формирования кворума необходимы 8, а в кластере с одной репликой — 1.
Важно
Реплики, для которых вручную задан источник репликации, не могут становиться мастером или участвовать в кворуме.
Количество кворумных реплик обновляется при любом изменении количества доступных хостов кластера, например, добавлении и удалении хостов, плановом или внеплановом обслуживании. Добавленный в кластер хост сначала синхронизируется с мастером и только потом может участвовать в кворуме.
Подробнее о том, как организована репликация в PostgreSQL, читайте в документации СУБД.
Управление репликацией
Для обеспечения сохранности данных в кластере реализовано автоматическое управление репликацией — каждый хост-реплика получает поток репликации от хоста-мастера. При необходимости источник репликации можно указать вручную.
В кластере допустимо комбинировать автоматическое и ручное управление потоками репликации.
Автоматическое управление потоками репликации
После создания кластера PostgreSQL из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.
Особенности автоматической репликации в Managed Service for PostgreSQL:
- При выходе из строя хоста-мастера наименее отстающая реплика становится новым мастером.
- При смене мастера источник репликации для всех хостов-реплик автоматически переключается на новый хост-мастер.
Вы можете выключить автоматическое переключение мастера, изменив дополнительные настройки кластера. При этом, если текущий хост-мастер выйдет из строя, запустить выборы нового мастера или назначить эту роль одной из реплик придется вручную.
Ручное управление потоками репликации
При ручном управлении источником репликации для реплики служит не хост-мастер, а другой хост в кластере.
Таким образом, в кластере PostgreSQL со сложной топологией можно настроить каскадную репликацию, при которой часть реплик использует другие хосты кластера в качестве источника потока репликации. Управление потоком репликации для таких хостов-источников может осуществляться как автоматически средствами Managed Service for PostgreSQL, так и вручную.
Важно
Реплики, для которых вручную установлен источник репликации, не могут:
- Становиться мастером при автоматической или ручной смене хоста-мастера.
- Автоматически переключаться на новый источник репликации при выходе из строя текущего источника репликации.
- Участвовать в кворумной репликации.
- Выбираться как наименее отстающие при использовании особого FQDN.
Реплика с заданным вручную источником репликации может не подтвердить запись. Данные на ней будут считаться устаревшими, если запись выполнена на другие реплики и транзакция была подтверждена кворумом. При накоплении отставания реплики ее WAL будет автоматически перезаписан новыми данными с источника репликации.
Синхронность записи и консистентность чтения
За синхронизацию записи данных в PostgreSQL отвечает параметр synchronous_commit, управляющий синхронностью передачи WAL (Write-Ahead Log) — журнала опережающей записи. По умолчанию установлено значение synchronous_commit = on. В этом случае транзакция подтверждается, только если WAL записан и на диск мастера, и на диск каждой кворумной реплики.
В зависимости от количества реплик в кластере возможны следующие варианты поведения:
- В кластере с одной репликой кворум состоит только из нее, а ручное управление потоками репликации недоступно. Если реплика выйдет из строя, транзакции на запись будут ожидать подтверждения до ее возвращения в кластер.
- В кластере с двумя репликами транзакция подтверждается, когда WAL записан на диск кворумной реплики. При выходе ее из строя кворум будет составлен из оставшейся реплики, если у нее не указан источник репликации. В таком случае никаких изменений в результатах запросов к хосту-мастеру не произойдет.
- В кластере с нечетным количеством реплик
N > 1кворум состоит изN-1 / 2реплик. Для остальных реплик можно настроить источник репликации вручную. - В кластере с четным количеством реплик
N > 2кворум состоит изN / 2реплик. Для остальных реплик можно настроить источник репликации вручную.
Чтобы гарантировать постоянную консистентность чтения данных между мастером и кворумной репликой, в настройках кластера задайте значение synchronous_commit = remote_apply. При таком значении запись не считается успешной, пока кворумная реплика не применит изменения из WAL. В этом случае операция чтения, выполненная на мастере и на этой реплике, всегда возвращает один и тот же результат.
Недостаток этого решения — операции записи в кластер будут занимать больше времени. Если мастер и кворумная реплика расположены в разных зонах доступности, то задержка подтверждения транзакции (latency) будет не меньше, чем время передачи данных туда и обратно (Round-Trip Time, RTT) между дата-центрами. Это снизит производительность кластера при записи в один поток и при включенном режиме AUTOCOMMIT.
Для повышения производительности ведите запись в несколько потоков, где это возможно, а также отключите AUTOCOMMIT и группируйте запросы в транзакции.
Логическое декодирование
Кластер Managed Service for PostgreSQL поддерживает логическое декодирование, которое позволяет передавать во внешние сервисы информацию об изменениях в базе данных. В частности, оно используется для захвата изменения данных (CDC).
Информация об изменениях в базе данных в формате WAL передается в слот репликации, который преобразует ее в понятный внешнему сервису формат с помощью выходного плагина.
Managed Service for PostgreSQL поддерживает следующие плагины WAL:
- test_decoding — преобразует данные из WAL в текстовое представление.
- wal2json — преобразует данные из WAL в JSON-представление.
- pgoutput — преобразует данные из WAL в формат протокола логической репликации.
Создавать слоты репликации могут пользователи с ролью mdb_replication.
Примеры использования
- Миграция базы данных из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
- Миграция данных из Yandex Managed Service for MySQL® в Managed Service for PostgreSQL с помощью Yandex Data Transfer
- Миграция данных из Managed Service for PostgreSQL в Yandex Managed Service for MySQL® с помощью Yandex Data Transfer
- Миграция базы данных из Managed Service for PostgreSQL
- Асинхронная репликация данных из PostgreSQL в ClickHouse®