Как я могу принудительно объединить все файлы WAL из pg_xlog обратно в мой базовый каталог "data"?
Вопрос:
Есть ли способ сказать Postgres (9.2) "объединить все файлы WAL в pg_xlog обратно в файлы данных не-WAL, а затем удалить все файлы WAL, успешно объединенные?"
Я хотел бы иметь возможность "форсировать" эту операцию; т.е. checkpoint_segments или настройки архивирования следует игнорировать. Буфер WAL файловой системы (pg_xlog) каталог должен быть опустошен или почти опустошен. Это нормально, если часть или все пространство, занимаемое pg_xlog каталог затем используется каталогом данных; наш администратор БД запросил резервное копирование файловой базы данных (т. е. каталога данных, а не sql) без каких-либо бэкапов WAL, но использование пространства не является проблемой.
Наличие почти нулевой активности WAL во время этой операции является тонким ограничением. Я могу убедиться, что сервер базы данных либо отключен, либо не подключен (нулевая нагрузка транзакции, сгенерированная пользователем) во время этого процесса.
По сути, я бы хотел, чтобы Postgres временно игнорировал политики архивирования / хранения контрольных точек и сбрасывал всю активность WAL в файлы основной базы данных, оставляя pg_xlog в том же состоянии, как если бы база данных была недавно создана - с очень небольшим количеством файлов WAL.
Что я пробовал:
Я знаю что pg_basebackup Утилита выполняет что-то вроде этого (генерирует почти все-слитые в WAL копии каталога данных экземпляра Postgres), но мы пока не готовы использовать его на всех наших системах, так как мы все еще тестируем настройки репликации; Я надеюсь на более краткосрочное решение.
Я пробовал выдавать CHECKPOINT команды, но они просто перерабатывают один файл WAL и заменяют его другим (то есть, если они вообще что-то делают; если я их выдаю во время простоя базы данных, они ничего не делают). pg_switch_xlog() аналогично просто принудительно переключается на следующий сегмент журнала; он не сбрасывает все сегменты в очереди / буфере.
Я также играл с pg_resetxlog полезность. Эта утилита делает то, что я хочу, но все ее документы об использовании, кажется, указывают, что она уничтожает (а не выкидывает из журнала транзакций в основные файлы данных) некоторые или все данные WAL. Это впечатление точное? Если нет, могу ли я использовать pg_resetxlog во время периода нулевой активности WAL для принудительного сброса всех данных WAL, поставленных в очередь, в данные, не относящиеся к WAL? Если ответ на этот вопрос отрицательный, как я могу достичь этой цели?
Спасибо!
1 ответ
,,, что-то говорит мне, что ваш администратор не парень из Postgres?:-)
Судя по вашим комментариям, похоже, что наиболее близким к искомому решению является запуск базы данных (с использованием вашей базовой резервной копии) и выдача CHECKPOINTзатем отключите эту БД и сохраните ее. Это приведет к сбросу данных WAL в журналах "догоняющего" в первичные файлы БД и оставит вас с "пустым" WAL (хотя у вас все еще будет несколько сегментов, необходимых для фактического запуска сервера и проверки консистенция).
Единственный другой способ убедиться, что в резервной копии, которую вы собираете, все данные, сброшенные в основные файлы БД, - это закрыть базу данных, чтобы сделать резервную копию.
Я бы не советовал делать что-либо из этого для статических резервных копий, как кажется, что вы делаете. Просто держитесь за резервную копию, созданную в соответствии с руководством Postgres, и, если вам нужно активировать ее, запустите сервер, используя его, как вы это обычно делаете в руководстве.
Я, честно говоря, не могу придумать вескую причину того, что запрашивает ваш администратор баз данных - небольшая задержка запуска, пока Postgres воспроизводит файлы журнала, которые вы собрали после pg_stop_backup() Команда не стоит делать что-то странное и отличное, вместо того, чтобы следовать проверенным процедурам, описанным в руководстве, и количество тестов, которое вам нужно будет сделать, чтобы убедиться, что любая новая процедура, которую вы придумали, так же надежна, как стандарт процедуры делают это непривлекательным вариантом ИМХО.
Очевидно, что процедура для рабов / потоковой передачи / горячего резервирования немного отличается, опять же в соответствии с руководством.
Если вашему администратору БД действительно нужно минимальное количество сегментов WAL, я бы предложил решение, которое я использую:
- Ведомый назначается в качестве резервного узла.
- Когда приходит время резервного копирования, мы выключаем подчиненное устройство и делаем резервную копию файловой системы.
- Раб запускается, когда мы закончили с резервным копированием, и обычно перехватывается в течение 15 минут.
Восстановление из этой резервной копии по сути аналогично активации ведомого устройства - ведомое устройство запускается и создается файл триггера восстановления.
Есть несколько хитростей, чтобы настроить это - ничего, что не описано в руководстве, но очевидно, что вы хотите тщательно протестировать.