Вопрос:
Текущая ситуация
Поэтому у меня есть WAL-архивирование, настроенное на независимый внутренний жесткий диск на компьютере регистрации данных, на котором запущен Postgres. Жесткий диск, содержащий архивы WAL, заполняется, и я хотел бы удалить и архивировать все архивные файлы WAL, включая исходную резервную копию, на внешние резервные диски.
Структура каталогов выглядит так:
D: /WALBACKUP/которая является родительской папкой для всех файлов WAL (00000110000.CA00000004 и т.д.).
D: /WALBACKUP/BASEBACKUP/, который содержит.tar начальной базовой резервной копии
Тогда у меня возникает вопрос:
- Могу ли я безопасно перемещать буквально каждый файл WAL, кроме текущего архива WAL, (000000000001.CA0000.. и т.д.), Включая базовую резервную копию, и переместить их на другой hdd. (Обратите внимание, что база данных активна и принимает данные)
ура!
Ответ №1
Архив WAL
Вы можете использовать команду pg_archivecleanup для удаления WAL из архива (не pg_xlog), который не требуется для данной базовой резервной копии.
В общем, я предлагаю использовать PgBarman или аналогичный инструмент для автоматизации резервного копирования базы и хранения WAL. Это проще и менее подвержено ошибкам.
pg_xlog
Никогда не удаляйте WAL из pg_xlog вручную. Если у вас слишком много WAL, тогда:
- ваш параметр wal_keep_segments поддерживает WAL;
- у вас есть archive_mode on и archive_command но он работает неправильно (проверьте журналы);
- ваши checkpoint_segments являются смехотворно высокими, поэтому вы просто генерируете слишком много WAL; или
- у вас есть слот репликации (см. представление pg_replication_slots), который предотвращает удаление WAL.
Вы должны устранить проблему, которая приведет к сохранению WAL. Если ничего не произошло после изменения настройки, запустите ручную команду CHECKPOINT.
Если у вас есть автономный сервер и вам нужно удалить WAL, чтобы запустить его, вы можете использовать pg_archivecleanup если нужно. Он знает, как удалить только WAL, который не нужен серверу самостоятельно… но он может сломать ваши архивные резервные копии, потоковые реплики и т.д. Поэтому не используйте его, если это необходимо.
Ответ №2
Файлы WAL являются инкрементальными, поэтому простой ответ: вы не можете выбросить файлы. Решение состоит в том, чтобы создать новую базовую резервную копию, а затем все предыдущие WAL можно удалить.
Файлы WAL содержат отдельные инструкции, которые изменяют таблицы, поэтому, если вы выбросите несколько старых WAL, процесс восстановления завершится неудачно (он не будет пропускать пропущенные файлы WAL), поскольку состояние базы данных невозможно восстановить надежно. Вы можете перемещать файлы WAL в другое место, не нарушая процесс WAL, но затем вам нужно будет сделать все файлы WAL доступными снова из одного места, если вам когда-либо понадобится восстановить вашу базу данных с некоторого момента в прошлом; если у вас заканчивается дисковое пространство, это может означать восстановление из какого-либо места, где у вас достаточно места для хранения базовой резервной копии и всех файлов WAL. Основная проблема здесь заключается в том, что вы можете сделать это достаточно быстро, чтобы восстановить полную базу данных после инцидента.
Другая проблема заключается в том, что если вы не можете определить, где/когда возникла проблема, которая должна быть исправлена, единственным вариантом является запуск базовой резервной копии и последующее воспроизведение всех файлов WAL. Эта процедура не сложна, но если у вас есть старая базовая резервная копия и многие файлы WAL для обработки, это просто занимает много времени.
Лучший подход для вашего дела, в общем, состоит в том, чтобы каждый раз создавать новую базовую резервную копию и собирать WAL с этой базовой резервной копией. После каждой новой базовой резервной копии вы можете удалить старую базовую резервную копию и ее последующие WAL или переместить их в дешевое автономное хранилище (DVD, лента и т.д.). В случае крупного инцидента вы можете быстро восстановить базу данных в известное правильное состояние из недавней базовой резервной копии и относительно немного файлов WAL, собранных с тех пор.
Ответ №3
Решение, в которое мы пошли, выполняет pg_basebackup каждую ночь. Это создаст базовую резервную копию, и позже мы сможем использовать pg_archivecleanup для очистки всех “старых” файлов WAL до этой базы, используя что-то вроде
«%POSTGRES_INSTALLDIR%binpg_archivecleanup» -d %WAL_backup_dir% %newestBaseFile%
К счастью, нам так и не пришлось восстанавливаться, но он должен работать теоретически.