Репликация
В кластерах 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 и группировать запросы в транзакции.