В абстрактном представлении работающая Digital Q.DataBase система генерирует бесконечную последовательность записей в журнале WAL. Система физически разделяет эту последовательность на файлы сегментов журналов WAL, размер которых обычно составляет 16 МБ (хотя размер сегмента может быть изменен в ходе выполнения initdb). Файлам сегментов присваиваются числовые имена, отражающие их положение в абстрактной последовательности механизма WAL. Если архивирование журналов WAL не используется, система обычно создает всего несколько файлов сегментов, а затем «повторно использует» их путём переименования файлов сегментов, которые более не требуются, в файлы с бóльшими номерами сегментов. Предполагается, что файлы сегментов, содержимое которых предшествует последней контрольной точке, более не представляют интереса и могут быть использованы повторно.

При архивировании данных журналов WAL необходимо фиксировать содержимое каждого файла сегмента по мере его заполнения и сохранять эти данные до того, как файл сегмента будет переиспользован. В зависимости от типа приложения и доступного оборудования могут существовать различные способы «сохранения данных»: возможна передача файлов сегментов в каталог, смонтированный по протоколу NFS на другом узле, запись на ленточный накопитель (с обеспечением возможности идентификации исходного имени каждого файла), пакетная запись на CD-диски или применение иных методов. Для обеспечения гибкости работы администратора базы данных, Digital Q.DataBase система не делает предположений о конкретном способе реализации процесса архивирования. Вместо этого, Digital Q.DataBase позволяет администратору указать команду оболочки или библиотеку архивирования, которая будет выполнена для копирования заполненного сегмента файла в место назначения. Это может быть как простая команда оболочки, использующая утилиту cp, так и вызов сложной функции на языке C — выбор полностью зависит от пользователя.

Для включения механизма архивирования журналов WAL установите wal_level параметр конфигурации в значение replica или выше, archive_mode в значение on, укажите используемую команду оболочки в archive_command параметре конфигурации или укажите используемую библиотеку в archive_library параметре конфигурации. На практике эти настройки всегда размещаются в файле postgresql.conf file.

В archive_command, %p заменяется путем к файлу для архивации, в то время как %f заменяется только именем файла. (Путь указывается относительно текущего рабочего каталога, т. е. каталога данных кластера.) Используйте параметр %% если требуется включить фактический символ % в команду. Простейшая полезная команда выглядит примерно так:

archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

которая будет копировать подлежащие архивации сегменты WAL в каталог /mnt/server/archivedir. (Данный пример приведен исключительно в ознакомительных целях и может работать не на всех платформах.) После того как %p и %f параметры будут заменены, фактическая исполняемая команда может выглядеть следующим образом:

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

Для каждого нового файла, подлежащего архивированию, будет генерироваться аналогичная команда архивирования.

Данная команда архивирования будет выполняться от имени того же пользователя, под которым Digital Q.DataBase запущен сервер. Поскольку серия архивируемых файлов журналов WAL фактически содержит все данные вашей базы данных, необходимо убедиться, что архивные данные защищены от несанкционированного доступа; например, следует выполнять архивирование в каталог, не имеющий прав доступа на чтение для группы или остальных пользователей.

Важно, чтобы команда архивирования возвращала нулевой код завершения только в случае ее успешного выполнения. При получении нулевого результата Digital Q.DataBase предполагает, что файл был успешно архивирован, после чего удаляет или переиспользует его. При этом ненулевой статус сообщает Digital Q.DataBase о том, что файл не был архивирован; попытки выполнения будут периодически повторяться до успешного завершения.

Другим способом архивирования является использование специализированного модуля архивирования в качестве archive_library. Поскольку подобные модули пишутся на языке программирования C, создание собственного модуля может потребовать значительно больше усилий, чем написание команды оболочки. Однако модули архивирования могут обладать более высокой производительностью по сравнению с архивированием через оболочку, а также иметь доступ ко многим полезным серверным ресурсам. Для получения дополнительных сведений о модулях архивирования см. раздел Глава 5.14.

В случае если выполнение команды архивирования прерывается сигналом (отличным от сигнала SIGTERM который используется в рамках завершения работы сервера) или на ошибку командной оболочки со статусом выхода выше 125 (например, «команда не найдена»), или если функция архивации выдает ERROR или FATAL, процесс архивации аварийно завершается и перезапускается процессом postmaster. В подобных случаях сведения о сбое не фиксируются в pg_stat_archiver.

Как правило, команды архивирования и библиотеки должны проектироваться таким образом, чтобы предотвращать перезапись любых уже существующих файлов архива. Данная функциональность является важной мерой обеспечения безопасности для сохранения целостности архива в случае ошибки администратора (например, при направлении вывода с двух разных серверов в один и тот же каталог архива). Рекомендуется протестировать предлагаемую библиотеку архивирования, чтобы убедиться, что она не перезаписывает уже существующие файлы.

В редких случаях Digital Q.DataBase может быть выполнена попытка повторного архивирования файла журнала WAL, который был архивирован ранее. Например, если в системе произойдет сбой до того, как сервер зафиксирует устойчивую запись об успешном завершении архивирования, утилита предпримет попытку повторно архивировать файл после перезапуска (при условии, что функция архивирования все еще активна). Если команда архивирования или библиотека обнаруживает уже существующий файл, она должна вернуть нулевой код состояния или значение trueсоответственно, при условии, что содержимое файла журнала WAL идентично содержимому существующего архивного файла и данный архив полностью зафиксирован в хранилище. Если же содержимое существующего файла отличается от содержимого архивируемого файла журнала WAL, команда архивирования или библиотека должен возвращать ненулевой код завершения или falseсоответственно.

Приведенный выше пример команды для ОС Unix позволяет избежать перезаписи существующего архива за счет включения отдельного этапа проверки. На некоторых Unix-платформах cp предусмотрены такие флаги, как -i которые позволяют выполнить ту же операцию более лаконично, однако не следует полагаться на них без предварительной проверки корректности возвращаемого кода завершения. (В частности, утилита GNU cp возвращает нулевой код завершения, когда -i используется параметр, а целевой файл уже существует, что не не соответствует требуемому поведению.)

При проектировании схемы архивирования следует учитывать возможные последствия многократных сбоев команды архивирования или библиотеки, вызванных необходимостью вмешательства оператора или отсутствием свободного места в хранилище. Например, подобная ситуация может возникнуть при записи на ленточный накопитель без автозагрузчика; после заполнения ленты дальнейшее архивирование невозможно до момента ее замены. Следует убедиться, что любые сообщения об ошибках или запросы к оператору передаются надлежащим образом для максимально оперативного разрешения ситуации. Утилита pg_wal/ каталог продолжит заполняться файлами сегментов WAL до тех пор, пока ситуация не будет разрешена. (Если файловая система, содержащая pg_wal/ заполнится, Digital Q.DataBase утилита выполнит аварийное завершение типа PANIC. Ни одна из зафиксированных транзакций не будет потеряна, однако база данных будет оставаться в автономном режиме до тех пор, пока не будет освобождено дисковое пространство.)

Скорость, с которой выполняется команда архивирования или библиотека, не имеет критического значения, пока она соответствует средней интенсивности, с которой сервер генерирует данные журналов WAL. Штатная работа продолжается, даже если процесс архивирования немного отстает. Если же отставание процесса архивирования становится значительным, это увеличивает объем данных, которые могут быть потеряны в случае возникновения критического сбоя. Это также будет означать, что pg_wal/ каталог будет содержать большое количество еще не архивированных файлов сегментов, что со временем может привести к исчерпанию доступного дискового пространства. Рекомендуется осуществлять мониторинг процесса архивирования, чтобы убедиться в его корректном функционировании.

При написании команды архивирования или библиотеки следует исходить из того, что длина имен архивируемых файлов может составлять до 64 символов, а сами имена могут содержать любые комбинации букв ASCII, цифр и точек. Сохранять исходный относительный путь необязательно (%p), но необходимо сохранить имя файла (%f).

Следует учитывать, что хотя архивирование журналов WAL позволяет восстановить любые изменения данных в Digital Q.DataBase базе данных, оно не восстанавливает изменения в конфигурационных файлах (таких как postgresql.conf, pg_hba.conf и pg_ident.conf), поскольку они редактируются вручную, а не с помощью операций на языке SQL. Рекомендуется размещать конфигурационные файлы в каталогах, для которых настроено регулярное резервное копирование на уровне файловой системы. См. Раздел 3.4.2 инструкции по перемещению конфигурационных файлов.

Команда архивирования или функция вызывается только для завершенных сегментов WAL. Следовательно, если сервер генерирует лишь небольшой объем трафика механизма WAL (или имеет периоды низкой активности), между завершением транзакции и ее безопасной записью в архивном хранилище может возникнуть значительная задержка. Для установки ограничения на максимальный возраст неархивированных данных можно настроить параметр archive_timeout для принудительного переключения сервера на новый файл сегмента WAL с заданной периодичностью. Обратите внимание, что архивные файлы, заархивированные досрочно из-за принудительного переключения, имеют тот же размер, что и полностью заполненные файлы. По этой причине не рекомендуется устанавливать слишком короткий интервал archive_timeout — это приведет к избыточному росту объема архивного хранилища. archive_timeout значения порядка одной минуты обычно являются оптимальными.

Кроме того, можно принудительно инициировать переключение сегмента вручную с помощью функции pg_switch_wal если необходимо обеспечить архивирование только что завершенной транзакции в кратчайшие сроки. Другие служебные функции, связанные с управлением механизмом WAL, перечислены в Таблица 2.6.95.

Когда параметр wal_level принимает значение minimal выполнение некоторых команд на языке SQL оптимизируется для исключения записи в журнал WAL, как описано в Раздел 2.11.4.7. Если во время выполнения одной из таких команд включено архивирование или потоковая репликация, журнал WAL не будет содержать достаточно информации для восстановления из архива. (На восстановление после сбоя это не влияет.) По этой причине wal_level может быть изменен только при запуске сервера. Однако archive_command и archive_library можно изменить путем перезагрузки файла конфигурации. Если архивирование выполняется через командную оболочку и требуется временно его остановить, одним из способов является установка параметра archive_command в значение пустой строки (''). Это приведет к накоплению файлов журналов WAL в pg_wal/ до тех пор, пока не будет восстановлена рабочая archive_command настройка.

Самым простым способом создания базовой резервной копии является использование утилиты pg_basebackup tool. Она позволяет создавать базовую резервную копию как в виде обычных файлов, так и в виде tar-архива. Если требуется большая гибкость, чем та, которую pg_basebackup может обеспечить утилита, базовую резервную копию также можно создать с помощью низкоуровневого API (см. Раздел 3.10.3.4).

О продолжительности времени, необходимого для создания базовой резервной копии, беспокоиться не следует. Однако, если сервер обычно работает с установленным параметром full_page_writes отключена, возможно снижение производительности в процессе выполнения резервного копирования, поскольку full_page_writes фактически принудительно активируется в режиме резервного копирования.

Для использования резервной копии необходимо сохранить все файлы сегментов WAL, созданные во время и после завершения резервного копирования на уровне файловой системы. Для обеспечения этой возможности процедура создания базовой резервной копии формирует файл истории резервного копирования который незамедлительно размещается в области архивации механизма WAL. Данный файл именуется по первому файлу сегмента WAL, необходимому для резервного копирования на уровне файловой системы. Например, если начальным файлом журнала WAL является 0000000100001234000055CD то файл истории резервного копирования будет иметь имя, подобное 0000000100001234000055CD.007C9330.backup. (Вторая часть имени файла указывает на точную позицию внутри файла журнала WAL и обычно может быть проигнорирована.) После успешной архивации резервной копии на уровне файловой системы и файлов сегментов WAL, задействованных при резервном копировании (согласно файлу истории резервного копирования), все архивные сегменты WAL с меньшими числовыми значениями в именах более не требуются для восстановления данной резервной копии на уровне файловой системы и могут быть удалены. Тем не менее, следует рассмотреть возможность хранения нескольких наборов резервных копий, чтобы гарантировать возможность успешного восстановления данных.

Файл истории резервного копирования представляет собой небольшой текстовый файл. Он содержит строку метки, заданную для утилиты pg_basebackup, а также время начала и завершения копирования и задействованные сегменты WAL. Если метка использовалась для идентификации соответствующего файла дампа, то архивного файла истории будет достаточно для определения того, какой файл дампа подлежит восстановлению.

Поскольку требуется обеспечивать хранение всех архивных файлов журналов WAL, начиная с момента создания последней базовой резервной копии, интервал между созданиями базовых резервных копий обычно выбирается на основании доступного объема дискового пространства для размещения архивных файлов журналов WAL. Также необходимо учитывать время, требуемое на восстановление, если таковое станет необходимым — системе потребуется выполнить воспроизведение всех этих сегментов WAL, что может занять продолжительное время, если с момента создания последней базовой резервной копии прошел значительный период.

Для работы можно использовать pg_basebackup с целью создания инкрементальной резервной копии путем указания --incremental параметра. В качестве аргумента для необходимо передать --incremental, файл манифеста резервной копии, относящийся к более ранней резервной копии, созданной на том же сервере. В результирующей резервной копии файлы, не относящиеся к отношениям, будут включены полностью, однако некоторые файлы отношений могут быть заменены инкрементальными файлами меньшего размера. Последние содержат только блоки, измененные с момента создания предыдущей резервной копии, и объем метаданных, достаточный для реконструкции текущей версии файла.

Для определения блоков, которые необходимо включить в резервную копию, сервер использует сводные данные механизма WAL, хранящиеся в каталоге данных, внутри подкаталога pg_wal/summaries. При отсутствии необходимых сводных файлов попытка создания инкрементальной резервной копии завершится ошибкой. Сводные данные в этом каталоге должны охватывать все значения LSN в интервале от начального LSN предыдущей резервной копии до начального LSN текущей резервной копии. Поскольку сервер выполняет поиск сводных данных механизма WAL сразу после определения начального значения LSN текущей резервной копии, необходимые файлы сводных данных могут отсутствовать на диске в данный момент, однако сервером будет инициировано ожидание появления любых недостающих файлов. Данный механизм также эффективен в случаях, когда процесс суммирования данных механизма WAL выполняется с задержкой. Тем не менее, если необходимые файлы уже были удалены или если процесс суммирования данных механизма WAL не завершится вовремя, создание инкрементальной резервной копии завершится ошибкой.

При восстановлении инкрементальной резервной копии потребуется наличие не только самой инкрементальной копии, но и всех предыдущих резервных копий, необходимых для предоставления блоков, пропущенных в данной инкрементальной резервной копии. См. pg_combinebackup для получения более подробных сведений об этом требовании. Следует учитывать наличие ограничений на использование утилиты pg_combinebackup , если состояние контрольных сумм кластера было изменено; см. ограничения утилиты pg_combinebackup.

Следует учитывать, что все требования, предъявляемые к использованию полной резервной копии, также распространяются на инкрементальную резервную копию. Например, по-прежнему необходимы все файлы сегментов WAL, сформированные в процессе и после завершения резервного копирования на уровне файловой системы, а также соответствующие файлы истории механизма WAL. Кроме того, по-прежнему требуется создать файл recovery.signal (или файл standby.signal) и выполнить восстановление, как описано в Раздел 3.10.3.5. Требование о доступности более ранних резервных копий в момент выполнения восстановления и об использовании pg_combinebackup является дополнительным условием ко всем остальным требованиям. Следует учитывать, что Digital Q.DataBase не имеет встроенного механизма для определения того, какие резервные копии все еще необходимы в качестве основы для восстановления последующих инкрементальных резервных копий. Необходимо самостоятельно отслеживать взаимосвязи между полными и инкрементальными резервными копиями и обеспечивать сохранность более ранних копий, если они могут потребоваться при восстановлении последующих инкрементальных резервных копий.

Инкрементальные резервные копии обычно целесообразны только для относительно больших баз данных, в которых значительная часть данных не изменяется или изменяется лишь незначительно. Для базы данных небольшого объема проще не учитывать существование инкрементальных резервных копий и выполнять только полные резервные копии, которыми легче управлять. Для базы данных большого объема, данные в которой интенсивно изменяются, инкрементальные резервные копии не будут значительно меньше по размеру, чем полные резервные копии.

Создание инкрементальной резервной копии возможно только в том случае, если процесс воспроизведения начинается с более поздней контрольной точки, чем для предыдущей резервной копии, от которой она зависит. При создании инкрементальной резервной копии на основном сервере это условие всегда выполняется, так как каждое резервное копирование инициирует создание новой контрольной точки. На резервном сервере воспроизведение начинается с самой последней контрольной точки перезапуска. Следовательно, создание инкрементальной резервной копии резервного сервера может завершиться ошибкой, если с момента предыдущего резервного копирования активность была минимальной, из-за чего новая контрольная точка перезапуска могла не быть создана.

Вместо создания полной или инкрементальной базовой резервной копии с помощью pg_basebackup, допускается создание базовой резервной копии с помощью низкоуровневого программного интерфейса API. Данная процедура включает в себя несколько большее количество этапов, чем pg_basebackup методом, однако он является сравнительно простым. Крайне важно выполнять данные шаги последовательно и проверять успешность выполнения каждого этапа перед переходом к следующему.

Допускается параллельное выполнение нескольких процессов резервного копирования (как запущенных через данный API резервного копирования, так и инициированных через pg_basebackup).

В случае возникновения критического сбоя и необходимости восстановления данных из резервной копии следует выполнить следующую процедуру:

Ключевым этапом данной процедуры является определение конфигурации восстановления, которая описывает требуемый метод и глубину процесса восстановления. Параметром, который необходимо обязательно указать, является restore_command, который указывает утилите Digital Q.DataBase способ извлечения архивированных сегментов файлов журналов WAL. Аналогично параметру archive_command, данный параметр представляет собой строку команды оболочки shell. Она может содержать спецификатор %f, который заменяется именем требуемого файла журнала WAL, и спецификатор %p, который заменяется путем для копирования файла журнала WAL. (Путь указывается относительно текущего рабочего каталога, то есть каталога данных кластера.) Укажите %% если требуется включить фактический символ % в команду. Простейшая полезная команда имеет следующий вид:

restore_command = 'cp /mnt/server/archivedir/%f %p'

данная команда копирует ранее архивированные сегменты WAL из указанной директории. /mnt/server/archivedir. Допускается использование и более сложных сценариев, вплоть до скриптов командной оболочки, запрашивающих у оператора установку соответствующей магнитной ленты.

Важно, чтобы при возникновении ошибки команда возвращала ненулевой код завершения. Утилита будет вызываться для запроса файлов, отсутствующих в архиве; при таком запросе она должна возвращать ненулевой статус. Данная ситуация не является критической ошибкой. Исключением являются случаи, когда выполнение команды прерывается сигналом (кроме сигнала SIGTERM, используемого при штатном завершении работы сервера базы данных) или ошибкой командной оболочки (например, «команда не найдена»); в таких ситуациях механизм восстановления прерывает работу, и запуск сервера не производится.

Не все запрашиваемые файлы будут являться файлами сегментов WAL; также следует ожидать запросов на файлы с суффиксом .history. Также следует учитывать, что базовое имя %p пути будет отличаться от %f; не следует считать их взаимозаменяемыми.

Сегменты WAL, которые не найдены в архиве, будут запрашиваться в pg_wal/; это позволяет использовать недавние неархивированные сегменты. Однако сегменты, доступные в архиве, будут использоваться в приоритетном порядке относительно файлов в pg_wal/.

Как правило, процесс восстановления проходит через все доступные сегменты WAL, тем самым восстанавливая базу данных до текущего момента времени (или максимально близкого к нему с учетом доступных сегментов WAL). Следовательно, штатное восстановление завершится сообщением «файл не найден» сообщение; при этом точный текст сообщения об ошибке зависит от выбора параметра restore_command. В начале процесса восстановления также может отображаться сообщение об ошибке для файла с именем вида 00000001.history. Это также является нормальным поведением и не указывает на наличие проблемы в простых ситуациях восстановления; см. Раздел 3.10.3.6 для обсуждения.

При необходимости выполнить восстановление на определенный момент времени (например, непосредственно перед тем, как младший администратор баз данных удалил основную таблицу транзакций), следует указать требуемую точку остановки. Существует возможность указать точку остановки, известную как «целевая точка восстановления», на основании даты и времени, именованной точки восстановления или завершения конкретной транзакции по ее идентификатору (ID). На момент написания документа наиболее удобными являются варианты с использованием даты/времени и именованной точки восстановления, так как отсутствуют инструменты для точного определения требуемого идентификатора транзакции.

Если при восстановлении будут обнаружены поврежденные данные журналов WAL, процесс восстановления остановится в этой точке, и сервер не будет запущен. В таком случае процесс восстановления может быть запущен повторно с самого начала с указанием «целевая точка восстановления» до точки повреждения, чтобы восстановление могло завершиться в штатном режиме. Если выполнение восстановления прерывается по внешней причине, такой как системный сбой или недоступность архива механизма WAL, то процесс восстановления можно просто перезапустить, и он возобновится практически с того момента, на котором произошел сбой. Перезапуск восстановления работает аналогично механизму контрольных точек при штатной эксплуатации: сервер периодически принудительно фиксирует все свое состояние на диске, а затем обновляет pg_control файл, указывая, что уже обработанные данные журналов WAL не требуют повторного сканирования.

Возможность выполнения восстановления базы данных до определенного момента в прошлом привносит определенные сложности, напоминающие сюжеты научно-фантастических произведений о путешествиях во времени и параллельных вселенных. Например, в исходной истории базы данных предположим, что критически важная таблица была удалена во вторник в 17:15, но ошибка была замечена только в среду в полдень. Вы берете резервную копию, выполняете восстановление на момент времени 17:14 вторника и возвращаетесь к работе. В это истории вселенной баз данных, в которой удаление таблицы не производилось. Однако предположим, что позднее будет выявлена ошибочность данного решения и возникнет необходимость возврата к состоянию в исходной истории, например, на утро среды. Это будет невозможно, если во время штатного функционирования базы данных были перезаписаны файлы сегментов WAL, относящиеся к периоду, к которому требуется вернуться. Таким образом, для исключения подобной ситуации необходимо разграничивать последовательности записей в журнале WAL, созданных после выполнения восстановления на момент времени, и записей, сформированных в рамках исходной истории базы данных.

Для решения данной задачи Digital Q.DataBase поддерживает концепцию линии времени. Каждый раз по завершении процедуры восстановления из архива создается новая линия времени для идентификации серий записей в журнале WAL, сгенерированных после данного восстановления. Идентификационный номер (ID) временной шкалы является составной частью имен файлов сегментов WAL, благодаря чему новая временная шкала не перезаписывает данные журналов WAL, сформированные в рамках предыдущих временных шкал. Например, в имени файла журнала WAL 0000000100001234000055CD, ведущий 00000001 представляет собой идентификатор шкалы времени в шестнадцатеричном формате. (Следует отметить, что в других контекстах, таких как сообщения системного журнала сервера, идентификаторы шкал времени обычно выводятся в десятичном формате.)

Фактически имеется возможность архивирования нескольких различных шкал времени. Несмотря на то, что данная функциональность может показаться бесполезной, она часто оказывается незаменимой. Рассмотрим ситуацию, когда отсутствует точная уверенность в том, на какой момент времени следует выполнить восстановление, в результате чего приходится выполнять несколько процедур восстановления на момент времени методом проб и ошибок, пока не будет найдена оптимальная точка ответвления от старой истории. Без использования механизма шкал времени данный процесс быстро привел бы к возникновению неуправляемой путаницы в данных. С использованием шкал времени восстановление можно выполнить до любого предшествующего состояния, включая состояния в ветках шкалы времени, от которых ранее отказались.

При каждом создании новой шкалы времени, Digital Q.DataBase создает «файл истории шкалы времени» в котором указывается, от какой именно шкалы времени и в какой момент произошло ответвление. Данные файлы истории необходимы для того, чтобы система могла выбрать корректные файлы сегментов WAL при выполнении восстановления из архива, содержащего несколько временных линий. В связи с этим они помещаются в область архива механизма WAL аналогично файлам сегментов WAL. Файлы истории представляют собой небольшие текстовые файлы, поэтому их бессрочное хранение является целесообразным и малозатратным (в отличие от файлов сегментов, имеющих большой объем). При необходимости в файл истории можно добавить комментарии, чтобы зафиксировать сведения о том, каким образом и по какой причине была создана данная конкретная временная линия. Такие комментарии будут особенно полезны в ситуациях, когда в результате проведения экспериментов формируется сложная структура из различных временных линий.

По умолчанию процедура восстановления выполняется до последней временной линии, обнаруженной в архиве. Если требуется выполнить восстановление до временной линии, которая была актуальна на момент, когда создавалась базовая резервная копия, или до определенной дочерней временной линии (то есть вернуться к состоянию, которое само было сформировано после попытки восстановления), необходимо указать параметр текущий или идентификатор целевой линии времени (timeline ID) в recovery_target_timeline. Выполнение восстановления с переходом на временные шкалы, ответвившиеся ранее момента создания базовой резервной копии, невозможно.

В данном разделе приведены рекомендации по настройке непрерывного архивирования.

archive_command = 'gzip < %p > /mnt/server/archivedir/%f.gz'

restore_command = 'gunzip < /mnt/server/archivedir/%f.gz > %p'

archive_command = 'local_backup_script.sh "%p" "%f"'

На момент написания данного текста метод непрерывного архивирования имеет несколько ограничений. Вероятно, они будут исправлены в будущих выпусках:

Также следует отметить, что формат по умолчанию механизм WAL является довольно объемным, так как включает в себя множество снимков страниц диска. Данные снимки страниц предназначены для обеспечения восстановления после сбоя, поскольку может возникнуть необходимость исправления частично записанных страниц диска. В зависимости от используемого аппаратного и программного обеспечения риск частичной записи может быть пренебрежимо малым; в таком случае можно существенно сократить общий объем архивируемых файлов журналов WAL, отключив снимки страниц с помощью full_page_writes параметра. (Перед выполнением данного действия ознакомьтесь с примечаниями и предупреждениями в разделе Глава 3.13 .) Отключение снимков страниц не препятствует использованию механизма WAL для операций восстановления на момент времени (PITR). Одним из направлений дальнейшего развития является сжатие архивируемых данных журналов WAL путем удаления избыточных копий страниц, даже когда параметр full_page_writes включен. В настоящее время администраторам рекомендуется сокращать количество снимков страниц, содержащихся в данных журналов WAL, путем максимально возможного увеличения значений параметров интервала контрольных точек.