Комментарии 21
Спасибо за отличный пост, Александр!
Я перевёл staging кластер на pg_probackup (с wal-g), всё работает классно, мне очень нравится. Один нюанс не очень понятен.
Я хочу иметь WAL для PITR за послендие 24 часа, и я настроил "--wal-depth=24", т.к. делаю инкрементальные бэкапы каждый час. Прошло несколько дней, но старые логи так и не удаляются. В документации сказано, что этот параметр определяет "Количество резервных копий на каждой линии времени, которое должно сохраняться для обеспечения возможности восстановления PITR." Но не сказано каких именно копий. Любых вообще или только полных?
Вот мой сетап:
- полный бэкап (FULL) один раз в сутки;
- инкрементальные бэкапы (PAGE) каждый час, для снижения RTO;
- WAL пишется синхронно через потоковый протокол утилитой pg_receivewal;
- полные копии хранятся 7 дней, а файлы небходимые для PITR хранятся 24 часа;
- старые инкрементальные бэкапы объединяются с родительской полной копией.
Ключик конечно есть, но почему-то не срабатывает.
--log-level-console=verbose можете показать?Вывод слишком длинный, не влезает в коммент. Вот гугло-документ с текстом.
По идее инкрементальные копии, не требуемые для PITR, должны автоматически объединяться с полными родительскими. Но этого также не происходит (--merge-expired).
pg_probackup show
pg_probackup show --archive
А вообще можем на гитхаб переместиться и завести issue:
github.com/postgrespro/pg_probackup/issues
LOG: Archive backup QKYSDE to stay consistent protect from purge WAL interval between 000000020000079B000000D5 and 000000020000079B000000D6 on timeline 2
INFO: On timeline 2 WAL segments between 000000020000079B000000D5 and 00000002000007DE000000C0 will be removed
INFO: Logical WAL size to remove on timeline 2 : 268GB
INFO: Resident WAL size to free on timeline 2 : 1312MB
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/000000020000079B000000D5.gz"
Те сегменты WAL, которые подлежат удалению, но при этом нужны для консистентного восстановления ARCHIVE бэкапов, pbk вынужден не удалять.
Этого эффекта можно избежать, если снимать бэкапы в STREAM режиме.
Да вот то то и оно, что непонятно почему он считает что нечего удалять.
Последние 24 бэкапа (любые?) нужны для PITR, остальное можно удалять.
LOG: REDUNDANCY=7
LOG: WINDOW=7
1. Цепочки бэкапов, принадлежащие последним 7 полным(FULL) бэкапам, нельзя трогать.
2. Бэкапы младше 7 дней нельзя трогать.
Если я правильно понимаю, то цепочки трогать действительно нельзя, но файлы журналов транзакций можно удалить.
--retention-redundancy=7
Specifies the number of full backup copies to keep in the data directory.
Тут всё понятно, сколько полных копий храним для возможности восстановления в случае сбоя.
--retention-window=7
Number of days of recoverability.
Примерно то же самое, но задаётся в днях.
--wal-depth=24
Number of latest valid backups on every timeline that must retain the ability to perform PITR.
А вот это не просто восстановление, а Point In Time Recovery. Определяет политику хранения файлов WAL.
Первые два параметра не говорят ничего про WAL, а лишь закрепляют бэкапы. Я могу восстановиться дискретно на момент времени, когда любой из этих бэкапов был снят (зависит от частоты снятия бэкапов).
А третий параметр касается как файлов WAL, так и связанных с ними бэкапов, и позволяет восстановиться на любой момент времени внутри этого диапазона (до милисекунд или txid).
И вот именно эти интервалы delete и не удаляет. Т.е. сейчас ваш архив выглядит как набор отрезков, лежащих на одной прямой:
-- -- -- -- -- -- ----------------->
Семён Семёныч! (facepalm) :-)
Про консистентность я и позабыл, действительно WAL файлы в архиве с дырами.
Спасибо вам огромное за помощь!
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B8000000DC.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B8000000DD.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B8000000DE.gz"
<следующий бэкап>
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B90000007D.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B90000007E.gz"
<следующий бэкап>
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B900000086.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007B900000087.gz"
<следующий бэкап>
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007BA0000007A.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007BA0000007B.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007BA0000007C.gz"
VERBOSE: Retain WAL segment "/scas/backups/data/wal/scas/00000002000007BA0000007D.gz"
...and so on...INFO: Backup QKYSDE, mode: FULL, status: OK. Redundancy: 5/7, Time Window: 5d/7d. Active
Должно пройти еще 2 дня и должно быть создано еще 3 полных бэкапа, прежде чем delete будет пытаться его выпилить/смержить.
Поясните, пожалуйста, резервные копии в режиме STREAM и режиме ARCHIVE предлагается делать одновременно? Не очевидно из статьи.
Вернулся с отпуска, только увидел комментарий :) Смотрите - в тексте есть объяснение - Поскольку в рассматриваемой ситуации мы переходим от автономных резервных копий (сделанных в режиме stream) к архивным (в режиме archive), то может возникнуть ситуация, в которой мы сделали копию, когда архивный режим ещё не был включён, после чего часть сегментов WAL уже оказалась удалена. Это означает, что первая резервная копия после перехода на архивный режим не может быть сделана в режиме PAGE, т.к. отрезок WAL в архиве между прошлой и текущей копией может не является целостным.
То есть в статье я делаю переход между одним типом бэкапов и другим. После того как такая копия будет сделана, уже можно будет переходить только на ARCHIVE режим, без опасения того, что какие-то, нужные для восстановления wal-файлы будут утеряны.
У вас бэкап с реплики не ждет записи текущего вала?
Если я запускаю DELTA бэкап с лидера - все проходит корректно.
Если с реплики - упираюсь в
"WARNING: Could not read WAL record at 5/63000148: invalid record length at 5/63000148: wanted 24, got 0"
Это текущий вал. Если выполнить pg_switch_wal() , то бэкап успешно завершится.
Я конечно понимаю, что на живой базе валы будут быстро заполняться и меняться автоматом, но мало ли какой тип бд, может вообще неделю никто ничего там делать не будет, заданий нет.
Тогда бэкап будет эту неделю висеть и ждать смены номера WAL?
Да, если вы делаете бэкап с реплики, то он будет ждать когда произойдёт переключение журнала. Но на самом деле это не такая уж и большая проблема - вы можете установить archive_timeout в какое-то приемлемое для вас значение. Например, поставьте в archive_timeout значение в 3 минуты. При отсутствии активности вы максимум будете ждать эти самые 3 минуты. Понятно, что если никакой активности нет, то в любом случае за день у вас будет сгенерировано 7,68 Гб пустых wal-файлов, но не думаю, что это большая цена за то, чтобы снимать бэкапы с реплики. На всякий случай подчеркну, что снимать бэкапы с реплики можно только в том случае, если есть мониторинг отставания этой самой реплики. Чтобы не получилось так, что реплика отстала, а вы продолжаете снимать с неё бэкапы.
Бэкап с реплики рассматривался для сильно нагруженных систем.
Есть условный кластер DataWareHouse, 3 узла + стендбай кластер в другом ЦОД.
Получается, что лидера рвут на части: собственно летят огромным потоком данные, плюс он же должен реплику данных отдать аж три раза: синк, асинк и на стендбай лидера, если при этом еще и бэкап с него тянуть, боюсь лопнет.
Знакомство с pg_probackup. Вторая часть