Синхронная репликация

Синхронную репликацию обычно используют, чтобы избежать потери некоторых транзакций. В Stolon она реализована таким образом, чтобы исключить возможность выбора несинхронизированных резервных серверов в качестве новых главных серверов.

Когда включена синхронная репликация, Stolon всегда обеспечивает наличие у главного сервера N синхронных резервных серверов (где N будет между значениями MinSynchronousStandbys и MaxSynchronousStandbys, определёнными в спецификации кластера). Если доступных резервных серверов недостаточно, он также добавит поддельный резервный сервер в synchronous_standby_names. Добавление несуществующего резервного сервера гарантирует, что главный сервер всегда будет блокироваться в ожидании удалённых коммитов.

Включить или отключить синхронную репликацию можно в любое время, и хранители переконфигурируют себя с помощью команды stolonctl update, чтобы обновить спецификацию кластера.

Минимальное и максимальное количество синхронных резервных копий

В спецификации кластера можно установить значения MinSynchronousStandbys и MaxSynchronousStandbys (по умолчанию оба равны 1). Наличие нескольких синхронных резервных серверов — это функция, предоставляемая начиная с PostgreSQL 9.6. Значения, отличные от 1 для версий PostgreSQL ниже 9.6, будут игнорироваться.

Включение синхронной репликации

Предполагая, что имя вашего кластера — mycluster и вы используете etcd (v3 api), прослушивающий порт localhost:2379:

stolonctl --cluster-name=mycluster --store-backend=etcdv3 update --patch '{ "synchronousReplication" : true }'

Отключение синхронной репликации

stolonctl --cluster-name=mycluster --store-backend=etcdv3 update --patch '{ "synchronousReplication" : false }'

Установка минимального и максимального количества синхронных резервных копий

Установите значения MinSynchronousStandbys/MaxSynchronousStandbys больше 1 (только при использовании PostgreSQL >= 9.6)

stolonctl --cluster-name=mycluster --store-backend=etcdv3 update --patch '{ "synchronousReplication" : true, "minSynchronousStandbys": 2, "maxSynchronousStandbys": 3 }'

Обработка ограничений синхронной репликации postgresql в таких обстоятельствах

У синхронной репликации PostgreSQL есть недостаток, описанный в документации:

Если первичный сервер перезапускается во время ожидания подтверждения коммитов, эти ожидающие транзакции будут помечены как полностью зафиксированные после восстановления первичной базы данных. Невозможно быть уверенным, что все резервные серверы получили все выдающиеся данные WAL на момент сбоя первичного сервера. Некоторые транзакции могут не отображаться как зафиксированные на резервном сервере, даже если они отображаются как зафиксированные на первичном сервере. Гарантия, которую мы предлагаем, заключается в том, что приложение не получит явного подтверждения успешной фиксации транзакции до тех пор, пока данные WAL не будут надёжно получены всеми синхронными резервными серверами.

При некоторых событиях это может привести к потере транзакций. Например:

• Синхронный резервный сервер выходит из строя.
• Клиент фиксирует транзакцию, она блокируется в ожидании подтверждения.
• Первичный сервер перезапускается, он помечает вышеуказанную транзакцию как полностью зафиксированную. Все клиенты теперь увидят эту транзакцию.
• Основной сервер умирает.
• Резервный сервер возвращается в работу.
• Sentinel выберет резервный сервер в качестве нового главного, поскольку он находится в списке synchronous_standby_names.
• Вышеупомянутая транзакция будет потеряна, несмотря на то, что синхронная репликация была включена.

Таким образом, могут возникнуть некоторые условия, при которых синхронизированный резервный сервер может быть выбран, даже если он пропустил последние транзакции, если он был недоступен во время фиксации.

Эту проблему нелегко решить, поскольку эти события не могут быть разрешены sentinel, поскольку невозможно узнать, действительно ли синхронизированный резервный сервер синхронизирован, когда основной сервер не работает (поскольку мы не можем запросить его последнюю позицию WAL, а отчёт от хранителя является асинхронным).

Но с Stolon у нас есть возможность преодолеть эту проблему, замечая, когда первичный сервер перезапускается (поскольку он контролируется нами), и разрешая только «внутренние» соединения до тех пор, пока все определённые синхронные резервные сервера не синхронизируются.

Разрешение только «внутренних» соединений означает запрет на... Добавление стандартных правил или пользовательских правил pgHBA, но только тех, которые необходимы для репликации (и локального взаимодействия с keeper).

Поскольку «внутренние» правила принимают определённого суперпользователя и пользователей репликации, клиент не должен использовать эти роли для нормальной работы, иначе вышеуказанное решение не будет работать (но они всё равно не должны этого делать, так как это может привести к исчерпанию зарезервированных соединений суперпользователя, необходимых keeper для проверки экземпляра).