Часто встречающиеся проблемы и пути их устранения
Обрыв сети между ЦОД
Проблема связана с обрывом сети между ЦОД.
Решение:
- размещение прокси-сервера маршрутизации соединений за пределами КТС с СУБД;
- дублирование экземпляров прокси-сервера маршрутизации соединений;
- добавление в схему решений, реализующих VRRP или аналоги — BGP.
Split Brain при асинхронной репликации
Если используется асинхронная репликация, то в случае частичного обрыва сети на Active
(запросы от клиентов продолжают поступать на Active
) и срабатывания AutoFailOver
может возникнуть ситуация, называемая Split Brain
. До срабатывания ttl
standalone экземпляр PostgreSQL продолжает обрабатывать клиентские запросы в режиме Active
. Если восстановление сети произойдет после срабатывания ttl
(смена ролей Active/StandBy
), то на «старом» Active
будет выполнена команда pg_rewind
, в результате которой будут отменены все транзакции, примененные в период с момента разрыва до срабатывания ttl
.
Решение:
- использовать режим синхронной репликации;
- реализовать
callback
в скриптахPangolin Manager
для переключенияActive
вStandBy
при разрыве сети (без ожидания срабатыванияttl
);
Несогласованность данных при отключенном pg_rewind
Если в рамках описанного выше сценария отключить использование pg_rewind
, то добавленные до истечения ttl
транзакции не удаляются, но и не реплицируются на «новый» Active
, после восстановления соединения. Аналогичное поведение наблюдается и при синхронной репликации.
Решение:
Перенос данных на новый Active
(возможно, pg_receivewal
), с проработкой вопроса слияния данных в случае конфликтов.
Зависание запросов и откат транзакций при синхронной репликации
Если в рамках описанного выше сценария будет использована синхронная репликация, то запросы на «старом» Active
будут висеть, не завершаясь, при этом транзакции на нем будут применены. После восстановления соединения транзакции откатываются pg_rewind
.
Решение:
- реализовать на стороне клиента защитный механизм с тайм-аутами (в случаях срабатывания тайм-аута откатывать текущую транзакцию);
- не применять транзакцию в случае невозможности репликации.
Зависание запросов при строгой синхронной репликации и недоступности StandBy
При использовании строгой синхронной репликации и недоступности StandBy
запрос на Active
висит, не завершаясь. Запись в базу добавляется после сигнала прерывания, либо при восстановлении связи со StandBy
. Репликация отрабатывает после восстановления связи с StandBy
.
Решение:
- реализовать на стороне клиента защитный механизм с тайм-аутами (в случаях срабатывания тайм-аута — откатывать текущую транзакцию);
- добавить в схему второй
StandBy
, настроенный на асинхронное реплицирование с синхроннымStandBy
; - не применять транзакцию в случае невозможности репликации.
Потеря транзакций при аварийном завершении Pangolin Manager
В случае аварийного завершения сервиса Pangolin Manager
на Active
во всех режимах работы есть вероятность потери транзакций в результате работы pg_rewind
.
Решение:
Использовать схему с автоматическим переключением трафика клиентов на новый Active
(использование Pangolin Pooler).
Потеря данных при недоступности Active во время сетевого разрыва
Во всех режимах работы при разрыве сети между ЦОД и недоступностью Active
велика вероятность потери данных в результате Split Brain
.
Решение:
Добавление в схему нового элемента: Pangolin Pooler.