Comments 6
Спасибо за интересную утилиту.
Как я понял на видео, вы переключаетесь на slave (через триггер файл), делаете изменение на новом мастере (кем стал slave) и начатываете изменения на старый мастер из нового через pg_rewind. И вот в перед запуском старого мастера как slave, я заметил, что вы чистите определенные файлы в (6:03 минута на видео), например backup_label. Этот файл создается при использовании
Но должен сам и чистится через
Тоесть pg_rewind не говорит остановить бэкап для мастера (дифф подчитается с wal логов, это ясно). Вопрос: почему так?
P.S. pg_rewind очень напомнил как работает восстановление в wal-e
Как я понял на видео, вы переключаетесь на 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
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). Так что можно не удивляться всяким странностям.
Вообще у них там еще много работы, на прошлой неделе постил им тикет типа «перемотка не работает если после файловера в новом мастере удалить базу». И второй пример, на прошлой недели при сборке требовался один набор зависимостей, а на этой неделе к зависимостям уже добавились еще три пакета (devel пакеты для openssl, libxslt, pam). Так что можно не удивляться всяким странностям.
Известные ограничения: Еще одно существенное ограничение, мастер должен быть выключен штатно.
никакого ограничения здесь нет.
порядок действий таков.
1. выдергиваем мастер из розетки
2. переводим слейв в мастер
3. старый мастер втыкаем в розетку
4. запускаем старый мастер, он делает recovery
5. останавливаем старый мастер корректно
6. делаем на старом мастере recovery.conf
7. запускаем pg_rewind и он успешно перематывает
8. запускаем старый мастер(он же новый слейв) и он накатывает изменения с нового мастера
куку)) обратите внимание на дату публикации поста, уже почти полтора года прошло, неудивительно что многое могло поменяться.
согласен. просто это единственный пост на русском где разобран пример. и он меня ввёл в заблуждение, я уже было расстроился посчитав что из-за такого ограничения pg_rewind не годится для задачи быстрого восстановления мастера после падения. однако мне таки удалось его завести описанным выше способом.
на текущий момент pg_rewind также не перематывает если postgres остановлен аварийно. полтора года назад тоже ничего не мешало сделать так чтобы аварийно упавший postgres был остановлен штатно.
на текущий момент pg_rewind также не перематывает если postgres остановлен аварийно. полтора года назад тоже ничего не мешало сделать так чтобы аварийно упавший postgres был остановлен штатно.
Sign up to leave a comment.
PostgreSQL feature highlight: быстрое превращение старого мастера в stand-by с pg_rewind