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

Проблема:

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

Решение:

• размещение прокси-сервера маршрутизации соединений за пределами КТС с СУБД;
• дублирование экземпляров прокси-сервера маршрутизации соединений;
• добавление в схему решений, реализующих VRRP или аналоги — BGP.

Проблема:

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

Решение:

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

Проблема:

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

Решение:

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

Проблема:

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

Решение:

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

Проблема:

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

Решение:

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

Проблема:

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

Решение:

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

Проблема:

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

Решение:

• добавление в схему новых элементов: pgbouncer и confd.

Проблема:

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

Решение:

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