Отладка и устранение проблем в PostgreSQL Streaming Replication.

Отладка и
устранение проблем
в PostgreSQL
Streaming Replication
Алексей Лесовский

План
Немного теории или как работает постгресовая репликация.
Troubleshooting tools или что есть у PostgreSQL и сообщества.
Troubleshooting cases — симптомы, проблемы, диагностика, решения.
Итоги, вопросы — ответы.

Зачем всё это?
Для лучшего понимания потоковой репликации.
Научиться быстро находить и устранять проблемы.
https://www.slideshare.net/alexeylesovsky/presentations

Немного теории
Write-Ahead Log (XLOG) — история всех изменений в БД.
● Бэкенды синхронно пишут все изменения в XLOG;
● Либо это делает WAL writer асинхронно.
Каталог pg_xlog/ (pg_wal/) в $DATADIR.
Потоковая репликация основана на XLOG.

Write-Ahead Log (XLOG) — история всех изменений в БД. почти;)
● Бэкенды синхронно пишут все изменения в XLOG;
● Либо это делает WAL writer асинхронно.
Каталог pg_xlog/ (pg_wal/) в $DATADIR.
Потоковая репликация основана на XLOG.

WAL Sender process (мастер).
WAL Receiver process (реплика).
Startup process (реплика).

WAL
Buffers
Storage
WAL
Sender
Network
WAL
Receiver
Storage
Startup
Process

План
Немного теории или как работает постгресовая репликация.
Troubleshooting tools или что есть у PostgreSQL и сообщества.
Troubleshooting cases — проблемы, симптомы и диагностика.
Итоги, вопросы — ответы.

Сторонние инструменты
Top (procps).
Iostat (sysstat), iotop.
Nicstat.
pgCenter.
Perf.

Сторонние инструменты
Top (procps) — утилизация CPU , load average, использование mem/swap.
Iostat (sysstat), iotop — утилизация хранилища, per-process ввод/вывод.
Nicstat — утилизация интерфейсов.
pgCenter — статистика по репликации.
Perf — подземные стуки.

Встроенные средства
Системные представления (views).
Вспомогательные функции.
Утилита pg_waldump (pg_xlogdump).

Системные представления
● pg_stat_replication, pg_stat_wal_receiver;
● pg_stat_databases, pg_stat_databases_conflicts;
● pg_stat_activity;
● pg_stat_archiver.

Вспомогательные функции
● pg_current_wal_lsn(), pg_current_xlog_location();
● pg_last_wal_receive_lsn(), pg_last_xlog_receive_location();
● pg_wal_lsn_diff(), pg_xlog_location_diff();
● df *(wal|xlog|lsn|location)* — psql мета-команда

pg_waldump
pg_waldump:
● Декодирует XLOG в человеко-понятный формат;
● Может врать при запущенном постгресе.
● pg_waldump -f -p /wal_10
$(psql -qAtX -c "select pg_walfile_name(pg_current_wal_lsn())")

Проблемы репликации
Лаги репликации.
Распухание pg_wal/.
Долгие запросы и конфликты при восстановлении.
Recovery process: 100% CPU usage.

Лаги репликации
Данные между мастером и репликами отличаются.

Как искать?
● pg_stat_replication, pg_wal_lsn_dif();
● pg_last_xact_replay_timestamp().

# SELECT
(pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) / 1024)::int as pending, <-- сеть?
---------+--------+-------------+-----------+-------+---------+-------+-------+--------+-----------

# SELECT
(pg_wal_lsn_diff(sent_lsn,write_lsn) / 1024)::int as write, <-- диски?
---------+--------+-------------+-----------+-------+---------+-------+-------+--------+-----------

# SELECT
(pg_wal_lsn_diff(write_lsn,flush_lsn) / 1024)::int as flush, <-- диски?
---------+--------+-------------+-----------+-------+---------+-------+-------+--------+-----------

# SELECT
(pg_wal_lsn_diff(flush_lsn,replay_lsn) / 1024)::int as replay, <-- диски/CPU?
---------+--------+-------------+-----------+-------+---------+-------+-------+--------+-----------

Проверка гипотезы
Сетевой лаг — nicstat.
Проблемы в хранилище — iostat, iotop.
Задержки восстановления — top, pg_stat_activity.
Большой объем WAL:
● pg_stat_activity, pg_stat_progress_vacuum;
● pg_wal_lsn_diff().

Варианты решения
Проблемы на уровне сети/хранения:
● Проверить workload — запросы, миграции, CRUD.
● upgrade hardware?

Задержки восстановления:
● Стрелять долгие запросы на реплике;
● Либо просто ждать.

Большой объем WAL:
● Уменьшить объем «изменений» в БД в единицу времени;
● Уменьшить объем записи в WAL в целом:
● full_page_writes = of;
● Увеличить интервал между чекпоинтами.

Распухание pg_wal/
Основные симптомы:
● Непредсказуемый рост использования дискового пространства;
● Ненормальный размер pg_wal/ каталога.

Как обнаружить?
● du -csh;
● pg_replication_slots, pg_stat_archiver;
● Ошибки в postgres'овых логах.

Варианты проблем:
● Тяжелый CRUD.
● Забытый или неиспользуемый слот репликации.
● Сломанная archive_command.

Экстренные меры (100% used space)
● Отстрелить долгие CRUD запросы — pg_terminate_backend();
● Уменьшить reserved space ratio (ext filesystems);
● Добавить еще места (LVM, ZFS, etc);

Экстренные меры (100% used space)
● Отстрелить долгие CRUD запросы — pg_terminate_backend();
● Уменьшить reserved space ratio (ext filesystems);
● Добавить еще места (LVM, ZFS, etc);
● НИКОГДА НИЧЕГО НЕ УДАЛЯТЬ РУКАМИ ИЗ pg_xlog/, pg_wal/

Что делать дальше:
● Снова проверить workload — CRUD.
● Состояние репликации.
● Уменьшить checkpoints_segments/max_wal_size, wal_keep_segments;
● Удалить слот репликации или починить подписчика;
● Починить WAL archiving;
checkpoint, checkpoint, cheсkpoint...

Конфликты восстановления
Основные симптомы — ошибки в логах постгреса или приложения.
● User was holding shared bufer pin for too long.
● User query might have needed to see row versions that must be removed.
● User was holding a relation lock for too long.
● User was or might have been using tablespace that must be dropped.
● User transaction caused bufer deadlock with recovery.
● User was connected to a database that must be dropped.

Как обнаружить:
● pg_stat_databases, pg_stat_databases_conflicts;
● postgresql logs.

Когда это действительно становится проблемой:
● Отмена запросов происходит слишком часто;
● Большой лаг репликации.

Решения:
● Увеличить max_standby_streaming_delay (риск лага репликации);
● Включить hot_standby_feedback (риск распухания таблиц/индексов);
● Переписать долгие запросы;
● Настроить выделенную реплику для долгих запросов.

Задержка восстановления
Основные симптомы:
● Значительный «replay» лаг;
● 100% утилизация CPU процессом recovery.

Как обнаружить?
● top — CPU usage;
● pg_stat_replication — replay лаг.

Что и как искать:
● perf top/record/report (требуются debug–пакеты);
● GDB;
● pg_waldump.

Решения:
● Зависят от результатов расследования;
● Устранение проблемного workload (как правило).

Итоги
Проблемы потоковой репликации всегда распределены между хостами
Источниками проблем выступают:
● Недостаток ресурсов, запросы, workload.
Без мониторинга никак.
Встроенные средства нужно знать и уметь.

Links
PostgreSQL official documentation – The Statistics Collector
https://www.postgresql.org/docs/current/static/monitoring-stats.html
PostgreSQL Mailing Lists (general, performance, hackers)
https://www.postgresql.org/list/
PostgreSQL-Consulting company blog
http://blog.postgresql-consulting.com
Эти слайды:
https://www.slideshare.net/alexeylesovsky/presentations

Спасибо за внимание!
dataegret.com alexey.lesovsky@dataegret.com

Отладка и устранение проблем в PostgreSQL Streaming Replication.

More Related Content

What's hot (19)

Similar to Отладка и устранение проблем в PostgreSQL Streaming Replication. (20)

More from Alexey Lesovsky (15)

Отладка и устранение проблем в PostgreSQL Streaming Replication.