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

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