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

Проблема:

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

Решение:

  • размещение прокси-сервера маршрутизации соединений за пределами КТС с СУБД;

  • дублирование экземпляров прокси-сервера маршрутизации соединений;

  • добавление в схему решений, реализующих VRRP или аналоги — BGP.

Проблема:

Если используется асинхронная репликация, то в случае частичного обрыва сети на Active (запросы от клиентов продолжают поступать на Active) и срабатывания AutoFailOver может возникнуть ситуация, называемая Split Brain. До срабатывания ttl односерверный экземпляр PostgreSQL продолжает обрабатывать клиентские запросы в режиме Active. Если восстановление сети произойдет после срабатывания ttl (смена ролей Active/StandBy), то на «старом» Active будет выполнена команда pg_rewind, в результате которой будут отменены все транзакции, примененные в период с момента разрыва до срабатывания ttl.

Решение:

  • использовать режим синхронной репликации;

  • реализовать callback в скриптах Pangolin Manager для переключения Active в StandBy при разрыве сети (без ожидания срабатывания ttl);

Проблема:

Если в рамках описанного выше сценария отключить использование pg_rewind, то добавленные до истечения ttl транзакции не удаляются, но и не реплицируются на «новый» Active, после восстановления соединения. Аналогичное поведение наблюдается и при синхронной репликации.

Решение:

  • перенос данных на новый Active (возможно, pg_receivewal), с проработкой вопроса слияния данных в случае конфликтов.

Проблема:

Если в рамках описанного выше сценария будет использована синхронная репликация, то запросы на «старом» Active будут висеть, не завершаясь, при этом транзакции на нем будут применены. После восстановления соединения транзакции откатываются pg_rewind.

Решение:

  • реализовать на стороне клиента защитный механизм с таймаутами (в случаях срабатывания таймаута откатывать текущую транзакцию);

  • не применять транзакцию в случае невозможности репликации.

Проблема:

При использовании строгой синхронной репликации и недоступности StandBy запрос на Active висит, не завершаясь. Запись в базу добавляется после сигнала прерывания, либо при восстановлении связи со StandBy. Репликация отрабатывает после восстановления связи с StandBy.

Решение:

  • реализовать на стороне клиента защитный механизм с таймаутами (в случаях срабатывания таймаута — откатывать текущую транзакцию);

  • добавить в схему второй StandBy, настроенный на асинхронное реплицирование с синхронным StandBy;

  • не применять транзакцию в случае невозможности репликации.

Проблема:

В случае аварийного завершения сервиса Pangolin Manager на Active во всех режимах работы есть вероятность потери транзакций в результате работы pg_rewind.

Решение:

  • использовать схему с автоматическим переключением трафика клиентов на новый Active (использование Pangolin Pooler).

Проблема:

Во всех режимах работы при разрыве сети между ЦОД и недоступностью Active велика вероятность потери данных в результате Split Brain.

Решение:

  • добавление в схему нового элемента: Pangolin Pooler.

Проблема:

Если включено расширение pg_pathman, pg_repack входит в бесконечный цикл при обработке его таблиц, что приводит к реорганизации не отдельной таблицы, а всей базы.

Решение:

Явно исключить pg_pathman из обработки с помощью ключа: -C pg_pathman.