Репликация в Managed Service for PostgreSQL
В кластерах Managed Service for PostgreSQL используется кворумная репликация (quorum-based synchronous replication):
- Среди хостов кластера выбирается мастер, а все остальные хосты становятся репликами.
- Транзакция считается успешной только в том случае, если ее подтвердили хост-мастер и не менее половины реплик кластера.
Если количество реплик нечетное, значение округляется вниз. Например, в кластере с 17 репликами для формирования кворума необходимы 8.
Количество реплик, необходимое для формирования кворума, определяется заново при изменении топологии кластера: добавлении и удалении хостов, выходе их из строя, выводе на техническое обслуживание, возврате в строй и т. д. При этом добавленный в кластер хост сначала синхронизируется с мастером и только потом может участвовать в кворуме.
Реплики, для которых вручную задан источник репликации, не могут становиться мастером или участвовать в кворуме.
Подробнее о том, как организована репликация в PostgreSQL, читайте в документации СУБД.
Управление репликацией
Для обеспечения сохранности данных в кластере используется потоковая репликация. Каждый хост-реплика получает поток репликации от другого хоста (обычно это хост-мастер). Managed Service for PostgreSQL управляет потоками репликации в кластере автоматически, но при необходимости ими можно управлять вручную.
В кластере допустимо комбинировать автоматическое и ручное управление потоками репликации.
Автоматическое управление потоками репликации
После создания кластера PostgreSQL из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.
Особенности автоматической репликации в Managed Service for PostgreSQL:
- При выходе из строя хоста-мастера одна из реплик становится новым мастером.
- При смене мастера источник репликации для всех хостов-реплик автоматически переключается на новый хост-мастер.
Вы можете выключить автоматическое переключение мастера, изменив дополнительные настройки кластера. При этом, если текущий хост-мастер выйдет из строя, запустить выборы нового мастера или назначить эту роль одной из реплик придется вручную.
Ручное управление потоками репликации
При ручном управлении в качестве источника репликации для реплики могут выступать другие хосты в кластере.
При этом вы можете:
- Полностью управлять процессом репликации в кластере и не использовать автоматическую репликацию.
- Настроить репликацию для кластеров PostgreSQL со сложной топологией. При этом часть реплик будет управляться автоматически, а часть — вручную.
Например, таким образом можно настроить каскадную репликацию, когда часть реплик кластера использует другие хосты кластера в качестве источника потока репликации. При этом управление потоком репликации для таких хостов-источников может осуществляться как автоматически средствами Managed Service for PostgreSQL, так и вручную.
Реплики, для которых вручную установлен источник репликации, не могут:
- Становиться мастером при автоматической или ручной смене хоста-мастера.
- Автоматически переключаться на новый источник репликации при выходе из строя текущего источника репликации.
- Участвовать в кворумной репликации.
- Выбираться как наименее отстающие при использовании особого FQDN.
Синхронность записи и консистентность чтения
За синхронизацию записи данных в PostgreSQL отвечает синхронность передачи WAL (Write-Ahead Log) — журнала опережающей записи (параметр synchronous_commit). По умолчанию для этого параметра установлено значение synchronous_commit = on. Оно предполагает, что транзакция подтверждается, только если WAL записан и на диск мастера, и на диск кворумной реплики.
Чтобы гарантировать постоянную консистентность чтения данных между мастером и кворумной репликой, в настройках кластера задайте значение 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.