Вопрос:
Есть ли способ сообщить 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? Если ответ отрицательный, как я могу достичь этой цели?
Спасибо!
. . . что-то подсказывает мне, что ваш администратор баз данных не является парнем из Postgres? :-)
Судя по вашим комментариям, наиболее близким к искомому решению является запуск базы данных (с использованием вашей базовой резервной копии) и выдача CHECKPOINT, затем выключите эту БД и создайте ее резервную копию. Это приведет к сбросу данных WAL в «догоняющих» журналах в основные файлы БД и оставит вас с «пустым» WAL (хотя у вас все еще будет несколько сегментов, которые необходимы для фактического запуска сервера и проверки последовательность).
Единственный другой способ убедиться, что все данные из получаемой резервной копии сброшены в основные файлы БД, - это выключить базу данных для создания резервной копии.
Я бы не советовал делать что-либо из этого для статических резервных копий, как будто вы это делаете. Просто оставьте резервную копию, созданную в соответствии с руководством Postgres, и, если вам нужно активировать ее, запустите сервер, используя ее, как обычно, в соответствии с руководством.
Честно говоря, я не могу придумать вескую причину того, что запрашивает ваш администратор базы данных - короткая задержка запуска, когда Postgres воспроизводит файлы журнала, которые вы собрали после pg_stop_backup() не стоит делать что-то странное и отличное, вместо того, чтобы следовать проверенным процедурам, описанным в руководстве, и объем тестирования, который вам нужно будет провести, чтобы убедиться, что любая новая процедура, которую вы придумали, является такой же надежной, как и стандартная процедуры делает этот вариант непривлекательным ИМХО.
Очевидно, что процедура для подчиненных устройств / потоковой передачи / горячего резервирования немного отличается, опять же согласно руководству.
Если ваш администратор базы данных действительно хочет минимальное количество сегментов WAL, я бы предложил решение, которое я использую:
Восстановление из этой резервной копии по сути то же самое, что активация ведомого устройства - ведомое устройство запускается и создается файл триггера восстановления.
Есть несколько уловок для настройки - ничего, что не описано в руководстве, но, очевидно, вы хотите тщательно протестировать.