Comments 4
Справедливости ради замечу: коллеги DBA подсказывают, что длинная транзакция не может блокировать работу checkpointer'а. Так что в данном случае проблема в чем-то другом, но в чем именно по метрикам пока не понятно.
Если разберётесь, будет интересно узнать.
Один из возможных вариантов — повреждение данных, приводящее к сбою чекпоинта,
надо мониторить логи на предмет ошибок. Там запросто может быть видна причина, почему не проходят чекпоинты.
И вообще, логи Постгреса мониторить больше — было бы круто (как мы неоднократно обсуждали). Начать хотя бы с FATAL-ов. Да хотя бы даже сегфолты отлавливать и алёртить про них.
надо мониторить логи на предмет ошибок. Там запросто может быть видна причина, почему не проходят чекпоинты.
И вообще, логи Постгреса мониторить больше — было бы круто (как мы неоднократно обсуждали). Начать хотя бы с FATAL-ов. Да хотя бы даже сегфолты отлавливать и алёртить про них.
Если по каким-то причинам реплика отстала и не проиграла какое-то количество сегментов, мастер будет хранить для нее pg_settings.wal_keep_segments сегментов. Если реплика отстанет на бОльшее количество сегментов, она больше не сможет подключиться к мастеру (придется наливать заново).
Не совсем так, если сегменты закончатся, то реплика будет восстанавливать wal из архива, если он конечно настроен. Слотовая репликация конечно хороша, но как уже говорилось при больших миграциях — может закончится место, если про нее забыли. У нас например настроена архивация wal логов за 2 дня и сегментов на 12Гб, что позволяет более точно контролировать место на диске, при распухании wal.
Sign up to leave a comment.
PostgreSQL: как и почему пухнет WAL