Репликация в Managed Service for PostgreSQL

В кластерах Managed Service for PostgreSQL используется кворумная репликация (quorum-based synchronous replication):

1. Среди хостов кластера выбирается мастер, а все остальные хосты становятся репликами.

2. Транзакция считается успешной только в том случае, если ее подтвердили хост-мастер и кворум реплик. Кворум составляет половина всех реплик кластера. Реплики для кворума выбираются случайным образом (кворумные реплики).

   Если количество реплик нечетное, значение округляется вниз, кроме случая с одной репликой. Например, в кластере с 17 репликами для формирования кворума необходимы 8, а в кластере с одной репликой — 1.

Количество кворумных реплик обновляется при любом изменении количества доступных хостов кластера, например, добавлении и удалении хостов, плановом или внеплановом обслуживании. Добавленный в кластер хост сначала синхронизируется с мастером и только потом может участвовать в кворуме.

Подробнее о том, как организована репликация в PostgreSQL, читайте в документации СУБД.

Управление репликациейУправление репликацией

Для обеспечения сохранности данных в кластере реализовано автоматическое управление репликацией — каждый хост-реплика получает поток репликации от хоста-мастера. При необходимости источник репликации можно указать вручную.

В кластере допустимо комбинировать автоматическое и ручное управление потоками репликации.

Автоматическое управление потоками репликацииАвтоматическое управление потоками репликации

После создания кластера PostgreSQL из нескольких хостов в нем находятся один хост-мастер и реплики. Реплики используют хост-мастер в качестве источника репликации.

Особенности автоматической репликации в Managed Service for PostgreSQL:

• При выходе из строя хоста-мастера наименее отстающая реплика становится новым мастером.
• При смене мастера источник репликации для всех хостов-реплик автоматически переключается на новый хост-мастер.

Ручное управление потоками репликацииРучное управление потоками репликации

При ручном управлении источником репликации для реплики служит не хост-мастер, а другой хост в кластере.

Таким образом, в кластере PostgreSQL со сложной топологией можно настроить каскадную репликацию, при которой часть реплик использует другие хосты кластера в качестве источника потока репликации. Управление потоком репликации для таких хостов-источников может осуществляться как автоматически средствами Managed Service for PostgreSQL, так и вручную.

Синхронность записи и консистентность чтенияСинхронность записи и консистентность чтения

За синхронизацию записи данных в 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®