PostgreSQL feature highlight: быстрое превращение старого мастера в stand-by с pg_rewind

[le0pard]

Спасибо за интересную утилиту.

Как я понял на видео, вы переключаетесь на slave (через триггер файл), делаете изменение на новом мастере (кем стал slave) и начатываете изменения на старый мастер из нового через pg_rewind. И вот в перед запуском старого мастера как slave, я заметил, что вы чистите определенные файлы в (6:03 минута на видео), например backup_label. Этот файл создается при использовании

SELECT pg_start_backup('label')

Но должен сам и чистится через

SELECT pg_stop_backup()

Тоесть pg_rewind не говорит остановить бэкап для мастера (дифф подчитается с wal логов, это ясно). Вопрос: почему так?

P.S. pg_rewind очень напомнил как работает восстановление в wal-e

[lesovsky]

backup_label.old остается от запуска pg после копирования pg_basebackup'ом (внутри у него так и написано LABEL: pg_basebackup base backup). А вот новый backup_label создается pg_rewind'ом (BACKUP METHOD: rewound with pg_rewind) и только потом при запуске postgres'а он переименовывается в backup_label.old. Увы, не умею читать сорцы но вполне подразумеваю что там какой-то отличный от pg_start/stop_backup механизм копирования.

Вообще у них там еще много работы, на прошлой неделе постил им тикет типа «перемотка не работает если после файловера в новом мастере удалить базу». И второй пример, на прошлой недели при сборке требовался один набор зависимостей, а на этой неделе к зависимостям уже добавились еще три пакета (devel пакеты для openssl, libxslt, pam). Так что можно не удивляться всяким странностям.

[le0pard]

Благодарю за ответ.

[ddv]

Известные ограничения: Еще одно существенное ограничение, мастер должен быть выключен штатно.

никакого ограничения здесь нет.

порядок действий таков.
1. выдергиваем мастер из розетки
2. переводим слейв в мастер
3. старый мастер втыкаем в розетку
4. запускаем старый мастер, он делает recovery
5. останавливаем старый мастер корректно
6. делаем на старом мастере recovery.conf
7. запускаем pg_rewind и он успешно перематывает
8. запускаем старый мастер(он же новый слейв) и он накатывает изменения с нового мастера

[lesovsky]

куку)) обратите внимание на дату публикации поста, уже почти полтора года прошло, неудивительно что многое могло поменяться.

[ddv]

согласен. просто это единственный пост на русском где разобран пример. и он меня ввёл в заблуждение, я уже было расстроился посчитав что из-за такого ограничения pg_rewind не годится для задачи быстрого восстановления мастера после падения. однако мне таки удалось его завести описанным выше способом.

на текущий момент pg_rewind также не перематывает если postgres остановлен аварийно. полтора года назад тоже ничего не мешало сделать так чтобы аварийно упавший postgres был остановлен штатно.