Репликация

В кластерах Managed Service for PostgreSQL используется синхронная репликация: транзакция подтверждается только тогда, когда данные записаны на диск и на хосте-мастере, и на синхронной реплике (это хост-реплика с наивысшим приоритетом). На остальных репликах кластера данные реплицируются асинхронно.

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

Из-за ограниченных ресурсов хосты классов b1.nano, b1.micro, b2.nano и b2.micro не реплицируются.

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

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

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

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

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

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

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

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

Подробнее о процессе выбора синхронной реплики см. в подразделе Выбор синхронной реплики.

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

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

Назначьте для хостов кластера источник репликации, чтобы:

• Полностью управлять процессом репликации в кластере и не использовать автоматическую репликацию.
• Настроить репликацию для кластеров PostgreSQL со сложной топологией, в котором часть реплик будет управляться автоматически, а часть — вручную.

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

Реплики, для которых вручную и явно установлен источник репликации, не могут:

• Становиться синхронными репликами и мастером при автоматической или ручной смене хоста-мастера (вне зависимости от значения приоритета).
• Автоматически переключаться на новый источник репликации при выходе из строя текущего источника репликации.

Выбор синхронной реплики

Чтобы повлиять на процесс выбора синхронной реплики в кластере PostgreSQL, установите нужные значения приоритета для хостов кластера: либо синхронной репликой будет выбран хост с самым высоким заданным приоритетом, либо, если в кластере есть несколько реплик с одинаково высоким приоритетом, будут проведены выборы среди этих реплик.

Если у любой асинхронной реплики в кластере изменяется приоритет так, что он становится выше, чем у текущей синхронной реплики, то такая реплика становится новой синхронной репликой.

Задать приоритет для хоста кластера можно:

• При создании кластера через CLI.
• При изменении настроек хоста в кластере.

Наименьший приоритет — 0 (по умолчанию), наивысший — 100.

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

По умолчанию синхронность реплики и мастера обеспечивается синхронностью передачи WAL — журнала опережающей записи (выставлен параметр synchronous_commit = on). Но между моментом доставки WAL и моментом его применения на синхронной реплике проходит некоторое время, в течение которого на синхронной реплике можно наблюдать данные, уже устаревшие на мастере.

Если вы хотите гарантировать постоянную консистентность чтения данных между мастером и синхронной репликой, укажите в настройках кластера параметр synchronous_commit = remote_apply. С этим значением параметра запись не считается успешной, пока синхронная реплика не применит изменения из доставленного WAL. При таком уровне синхронности операция чтения, выполненная на мастере и на синхронной реплике после подтверждения транзакции, вернет один и тот же результат.

Недостаток этого решения — операции записи в кластер будут занимать больше времени: если мастер и синхронная реплика расположены в разных зонах доступности, то задержка подтверждения транзакции (latency) будет не меньше, чем время передачи данных туда и обратно (Round-Trip Time, RTT) между дата-центрами, которые размещены в этих зонах доступности. Это приводит к тому, что при записи в один поток и включенном режиме AUTOCOMMIT производительность такого кластера может существенно снижаться. Для достижения максимальной производительности рекомендуем, где это возможно, производить запись в несколько потоков, а также отключить AUTOCOMMIT и группировать запросы в транзакции.