-
Notifications
You must be signed in to change notification settings - Fork 86
pg_probackup 2.4.10: Problem in receivexlog #346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Добрый день! |
|
Похоже что дело в этом:
Какие-то сетевые проблемы. |
Это локальный бэкап - сервер и pg_probackup на одном хосте. |
Хм, странно |
Нужен выхлоп уровня VERBOSE |
Повторный запуск на standby:
|
Все ещё нужен verbose: |
Файрволл? |
|
А можете показать метаданные этого бэкапа и содержимое его директории pg_wal? |
У меня есть подозрение, что мы тут просто не уложились в 600 секунд застримить все нужные сегменты. |
backup.control:
pg_wal пустой.
Локальный бэкап на standby, с которым никто кроме pg_probackup не работает. Что ему могло помешать? До этого мастер бэкапился без проблем. Сейчас картина выглядит следующим образом:
Все до QQ6FC2 включительно и QQ9N58 были сделаны на мастере. |
Заметил у себя в скрипте бэкапа ошибку: при локальном бэкапе на standby pg_probackup получал параметр -h с адресом мастера. |
Вот это номер.
Очень странные симптомы, если стриминг не может ничего застримить (например, мастер уже отротировал нужный сегмент), то мы должны были упасть с ошибкой. Если не отротировал, то хоть что-то должно было быть застримлено. |
#346 (comment) |
Это, кстати, серьезная проблема - можно получить неконсистентный бэкап и эту неконсистентность не факт, что получится обнаружить. Хорошо, что бэкап зафейлился (я, правда, пока не понимаю почему). |
https://cloud.oblteh.ru/s/XfGKQgSt8sifq6Z |
Вижу как минимум одну проблему:
Несмотря на явную ошибку, бэкап продолжил выполняться. Это залет |
Как Вы смотрите на то, что я соберу Вам кастомный пакет с фиксом и мы посмотрим на новое поведение? |
Положительно.
|
Пакеты в аттаче |
Но этот фикс не решает эту проблему:
Опять же нужно посмотреть на лог постгреса в этот момент. |
Даа, а если бы логирование в файл работало, то сколько бы времени сэкономили. |
Не, это я об ошибке, когда бэкап завершился через 3-4 секунды после старта, о конкретном бэкапе. |
А сейчас какие-то проблемы еще остались? |
Оставлю на выходные бэкапы в распоряжении crond, а на следующей неделе посмотрим статистику. В случае удачи стои таймауты стриминга уменьшать или на 240 пусть живет? |
240 - норм |
Может это как-то связано с этим значением?
И параметры выше должны быть больше значения archive_timeout? |
Пока работает. Был только один странный сбой:
У постгреса на это событие вот такие строчки в логе:
|
Выглядит как закрытие коннекта со стороны клиента. |
Почти не связано, |
Тогда что ему помешало?
WALы ротейтятся каждые 150 секунд. И то не удалённый бэкап, а локальный. Что могло помешать в пределах одного хоста? |
Нехватка ресурсов, например, медленное I/O. |
4 ядра и 32ГБ памяти для standby и pg_probackup - должно хватить.
https://cloud.oblteh.ru/s/q2ffA2wtSpeJBpY |
I have the same problem. Only happens from time to time with a full backup. OS
pg_probackup version
PostgreSQL version
wal_sender_timeout
wal_receiver_timeout
pg_probackup logs
pg_probackup logs from cron
|
Hello, @ccppprogrammer ! |
@gsmol you're right. In the PostgreSQL log I have:
|
Great! |
2.4.10 работал с этими настройками без проблем. Обновил до 2.4.15, поскольку наткнулся на проблему с пустым backup.control. 2.4.15 во время трех дней активных попыток так и не смог завершить ни одного бэкапа. Сваливался с этой же ошибкой:
В postgres.log в это время
Откатил до 2.4.10 |
Сейчас выпустим виндовые инсталлеры для 2.5.2 и можно будет попробовать его. |
Под Windows новее 2.4.15 так и нет инсталлеров? |
@ykurenkov, к сожалению, пока не делаю их. но в планах. |
CentOS 7, PostgreSQL 11.11. Бэкап производится мастера локально на NFS ресурс.
The text was updated successfully, but these errors were encountered: