В современных инсталляциях Postgresql под высокие нагрузки я неоднократно видел печаль, когда заканчивается место на диске, отведенное для логов Postgresql. Смертельного с СУБД Postgresql ничего не произойдет, СУБД Postgresql не остановиться, однако такой важной сущности, как логов для конкретного момента может и не быть.
Что бы исключить любую возможность потери информации в логах Postgresql можно задействовать Logrotate.
Для работу буду использовать уже готовую и описанную раннее виртуальную машину с отдельными дисками /data; /wal; /log и диск с ОС.
1. Подготовка директорий на диске с ОС:
mkdir -p /log/llog # сервисная директория записи логов скрипта logclean.sh
mkdir -p /postgres/scripts/logrotate/ # сервисная директория для logrotate
chown -R postgres:postgres /log
chown -R postgres:postgres /postgres
2. Подготовка logrotate:
cp /usr/sbin/logrotate /postgres/scripts/logrotate/
vim /postgres/scripts/logrotate/logrotate.conf
/log/pg_log/*.log -rt|head -n -1|sed 's/^/\/log\/pg_log\//'
{
rotate 99
size 500M
missingok
ifempty
compress
maxage 1
postrotate
/postgres/scripts/logrotate/logclean.sh
endscript
}
3. Правка postgresql.auto.conf
ALTER SYSTEM SET log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log';
ALTER SYSTEM SET log_rotation_size = '500MB';
ALTER SYSTEM set log_rotation_age = '0';
ALTER SYSTEM SET log_truncate_on_rotation = 'on';
ALTER SYSTEM SET log_directory = '/log/pg_log';
ALTER SYSTEM SET log_statement = 'all';
select pg_reload_conf();
Важно: включение ротации логов по размеру и отключение ротации по времени. Определяемся, что уровень логирования "all"
4. Создание /postgres/scripts/logrotate/logclean.sh
vim /postgres/scripts/logrotate/logclean.sh
chmod +x /postgres/scripts/logrotate/logclean.sh
logclean.sh - магический bash-скрипт. Его задача контролировать размер диска /log и по достижении % занятости производить архивирование логов в директории /log/pg_log. Порог срабатывания я задал 75%. Т.е. свободное место для записи логов должно оставаться.
5. Настройка планировщика
# Rotation log
*/5 * * * * /postgres/scripts/logrotate/logrotate postgres/scripts/logrotate/logrotate.conf --state /postgres/scripts/logrotate/logrotate-state
Запуск logrotate будет из-под postgres из отдельной сервисной директории:
6. Проверка работы
Работу logrotate можно проверить нагрузив Postgresql с помощью pgbench в тестовую БД otus. Для ускорения тестирования заполним диск /log данными:
fallocate -l 500MB /log/pg_log/file1.gz
fallocate -l 500MB /log/pg_log/file2.gz
fallocate -l 500MB /log/pg_log/file3.gz
ls -lh /log/pg_log
Нагружаем СУБД:
pgbench -c 80 -j 1 -P 10 -T 5000 -U postgres otus
Содержимое директории после старта нагрузки:
Содержимое директории после окончания нагрузки:
Видно, что все файлы логов Postgresql , кроме текущего находятся в архиве.
А что покажет самая лучшая система мониторинга СУБД Postgresql ZABBIX?
Из мониторинга ZABBIX видно, как ротируемый лог перемещается в архив с освобождением дискового пространства. Отсюда и пила на графике. Заполнение диска /log находится на уровне 80% (не считая первого пика). Логирование Postgresql не останавливается.
7. Работа СУБД Postgresql без работы logrotate
Для ускорения тестирования заполним диск /log данными:
fallocate -l 500MB /log/pg_log/file1.gz
fallocate -l 500MB /log/pg_log/file2.gz
и поставим под нагрузку командой:
pgbench -c 80 -j 10 -P 10 -T 1000 -U postgres otus
Работа СУБД Postgresql продолжается, но логирования больше нет. Диск /log заполнен под 100%.
8. Заключение
В большинстве современных инсталляциях Postgresql, logrotate может не пригодится и уровень детализации логирования в "all" избыточен. Однако, если разработчики проекта не верно оценили соотношение нагрузки на СУБД Postgresql и дискового пространства для Postgresql, то это чревато, в данном случае, потерей логов. Мое мнение и мнение моих коллег, что наличие логов лучше, чем их отсутствие. Logrotate позволяет свести к минимуму риск отсутствие логирования СУБД Postgresql.