Репликация
В кластерах Managed Service for PostgreSQL используется кворумная репликация (quorum-based synchronous replication):
- Среди хостов кластера выбирается мастер, а все остальные хосты становятся репликами.
- Из реплик случайным образом формируется кворум. Транзакция считается успешной только в том случае, если ее подтвердили хост-мастер и все входящие в кворум (кворумные) реплики.
Реплики, для которых вручную задан источник репликации, не могут становиться мастером или участвовать в кворуме.
Для формирования кворума необходимо участие не менее половины реплик кластера. Если количество реплик нечетное, значение округляется вниз. Например, в кластере с 17 репликами для формирования кворума необходимы 8.
Кворум формируется заново при изменении топологии кластера: добавлении и удалении хостов, выходе их из строя, выводе на техническое обслуживание, возврате в строй и т. д. При этом добавленный в кластер хост сначала синхронизируется с мастером и только потом может участвовать в кворуме.
Из-за ограниченных ресурсов хосты классов b1.nano, b1.micro, b2.nano и b2.micro не реплицируются.
Подробнее о том, как организована репликация в PostgreSQL, читайте в документации СУБД.
Управление репликацией
Для обеспечения сохранности данных в кластере используется потоковая репликация. Каждый хост-реплика получает поток репликации от другого хоста (обычно это хост-мастер). Managed Service for PostgreSQL управляет потоками репликации в кластере автоматически, но при необходимости ими можно управлять вручную.
В кластере допустимо комбинировать автоматическое и ручное управление потоками репликации.
Автоматическое управление потоками репликации
После создания кластера PostgreSQL из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.
Особенности автоматической репликации в Managed Service for PostgreSQL:
- При выходе из строя хоста-мастера одна из реплик становится новым мастером.
- При смене мастера источник репликации для всех хостов-реплик автоматически переключается на новый хост-мастер.
Подробнее о процессе выбора мастера см. в подразделе Выбор мастера.
Ручное управление потоками репликации
При ручном управлении в качестве источника репликации для реплики могут выступать другие хосты в кластере.
При этом вы можете:
- Полностью управлять процессом репликации в кластере и не использовать автоматическую репликацию.
- Настроить репликацию для кластеров PostgreSQL со сложной топологией. При этом часть реплик будет управляться автоматически, а часть — вручную.
Например, таким образом можно настроить каскадную репликацию, когда часть реплик кластера использует другие хосты кластера в качестве источника потока репликации. При этом управление потоком репликации для таких хостов-источников может осуществляться как автоматически средствами Managed Service for PostgreSQL, так и вручную.
Реплики, для которых вручную установлен источник репликации, не могут:
- Становиться мастером при автоматической или ручной смене хоста-мастера (вне зависимости от значения приоритета).
- Автоматически переключаться на новый источник репликации при выходе из строя текущего источника репликации.
- Участвовать в кворумной репликации.
Выбор мастера
Чтобы повлиять на процесс выбора мастера в кластере PostgreSQL, установите нужные значения приоритета для хостов кластера: либо мастером будет выбран хост с самым высоким заданным приоритетом, либо, если в кластере есть несколько реплик с одинаково высоким приоритетом, будут проведены выборы среди этих реплик.
Задать приоритет хоста можно:
- при создании кластера с помощью YC CLI, API или Terraform;
- при изменении настроек хоста.
Наименьший приоритет — 0 (по умолчанию), наивысший — 100.
Вы можете выключить автоматическое переключение мастера, изменив дополнительные настройки кластера. При этом если текущий хост-мастер выйдет из строя, запустить выборы нового мастера или назначить эту роль одной из реплик придется вручную.
Синхронность записи и консистентность чтения
За синхронизацию записи данных в PostgreSQL отвечает синхронность передачи WAL (Write-Ahead Log) — журнала опережающей записи (параметр synchronous_commit). По умолчанию для этого параметра установлено значение synchronous_commit = on. Оно предполагает, что транзакция подтверждается, только если WAL записан и на диск мастера, и на диск кворумной реплики.
Чтобы гарантировать постоянную консистентность чтения данных между мастером и кворумной репликой, в настройках кластера задайте значение synchronous_commit = remote_apply. При таком значении запись не считается успешной, пока кворумная реплика не применит изменения из WAL. В этом случае операция чтения, выполненная на мастере и на кворумной реплике, всегда возвращает один и тот же результат.
Недостаток этого решения — операции записи в кластер будут занимать больше времени. Если мастер и кворумная реплика расположены в разных зонах доступности, то задержка подтверждения транзакции (latency) будет не меньше, чем время передачи данных туда и обратно (Round-Trip Time, RTT) между дата-центрами. Это снизит производительность кластера при записи в один поток и при включенном режиме AUTOCOMMIT.
Для повышения производительности ведите запись в несколько потоков, где это возможно, а также отключите AUTOCOMMIT и группируйте запросы в транзакции.