Перейти к основному содержимому

Часто встречающиеся проблемы и пути их устранения

Обрыв сети между ЦОД

Проблема связана с обрывом сети между ЦОД.

Решение:

  • размещение прокси-сервера маршрутизации соединений за пределами КТС с СУБД;
  • дублирование экземпляров прокси-сервера маршрутизации соединений;
  • добавление в схему решений, реализующих 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.