В абстрактном смысле, работающая система Tantor SE производит бесконечную последовательность записей WAL. Система физически разделяет эту последовательность на файлы WAL сегментов, которые обычно имеют размер 16 МБ (хотя размер сегмента может быть изменен во время initdb). Сегменты файлов получают числовые имена, отражающие их позицию в абстрактной последовательности WAL. Когда не используется архивирование WAL, система обычно создает только несколько сегментных файлов, а затем “переиспользует” их, переименовывая файлы сегментов, которые больше не нужны, в более высокие номера сегментов. Предполагается, что сегментные файлы, содержимое которых предшествует последней контрольной точке, больше не представляют интереса и могут быть переиспользованы.

При архивировании данных WAL нам необходимо захватывать содержимое каждого сегментного файла после его заполнения и сохранять эти данные где-то, прежде чем сегментный файл будет повторно использован. В зависимости от приложения и доступного оборудования может быть множество различных способов "сохранения данных где-то": можно скопировать сегментные файлы в каталог, смонтированный по NFS на другой машине, записать их на магнитную ленту (обеспечивая способ идентификации исходного имени каждого файла), объединить их вместе и записать на CD или что-то еще полностью отличное. Чтобы предоставить администратору базы данных гибкость, Tantor SEне делает никаких предположений о том, как будет выполняться архивирование. Вместо этого Tantor SEпозволяет администратору указать команду оболочки или библиотеку архива, которая будет выполнена для копирования завершенного сегментного файла в нужное место. Это может быть такой простой командой оболочки, как cp, или она может вызывать сложную функцию на языке C - все зависит от вас.

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

В 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

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

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

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

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

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

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

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

При проектировании системы архивирования учтите, что произойдет, если команда архивации или библиотека несколько раз не смогут выполниться из-за требования вмешательства оператора или из-за нехватки места в архиве. Например, это может произойти, если вы записываете на ленту без автоматического сменного устройства; когда лента заполняется, невозможно производить дальнейшую архивацию до тех пор, пока лента не будет заменена. Вы должны обеспечить адекватное сообщение об ошибке или запросе оператору, чтобы ситуация могла быть разрешена достаточно быстро. Каталог pg_wal/ будет продолжать заполняться файлами сегментов WAL до тех пор, пока ситуация не будет разрешена. (Если файловая система, содержащая каталог pg_wal/, заполнится, Tantor SE выполнит аварийное выключение. Никакие подтвержденные транзакции не будут потеряны, но база данных останется офлайн до освобождения некоторого пространства).

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

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

Обратите внимание, что хотя архивирование WAL позволит восстановить все изменения, внесенные в данные в вашей базе данных Tantor SE, оно не восстановит изменения, внесенные в файлы конфигурации (то есть postgresql.conf, pg_hba.conf и pg_ident.conf), поскольку они редактируются вручную, а не через SQL-операции. Возможно, вам захочется сохранить файлы конфигурации в месте, которое будет резервироваться вашими обычными процедурами резервного копирования файловой системы. См. Раздел 19.2 для получения информации о том, как переместить файлы конфигурации.

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

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

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

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

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

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

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

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

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

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

Хорошо, случилось самое худшее и вам нужно восстановиться из резервной копии. Вот процедура:

Важной частью всего этого является настройка файла восстановления, который описывает, как нужно восстановить и насколько должно выполняться восстановление. Единственное, что вам абсолютно необходимо указать, это restore_command, который сообщает Tantor SE, как извлекать архивные сегменты файлов журнала предзаписи. Как и archive_command, это строка командной оболочки. Она может содержать %f, который заменяется именем желаемого файла журнала, и %p, который заменяется путем копирования файла журнала. (Путь относительно текущего рабочего каталога, т.е. каталога данных кластера). Напишите %%, если вам нужно вставить фактический символ % в команду. Самая простая полезная команда выглядит примерно так:

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. Это также нормально и не указывает на проблему в простых ситуациях восстановления; см. подробнее раздел "Резервные копии и временные линии Раздел 25.3.5".

Если нужно восстановиться до какой-либо предыдущей точки во времени (скажем, прямо перед тем, как младший DBA удалил вашу основную транзакционную таблицу), просто укажите требуемую точку остановки. Вы можете указать точку остановки, известную как “цель восстановления”, либо по дате/времени, либо по имени точки восстановления, либо по завершению определенной транзакции. На момент написания этого документа только опции по дате/времени и по имени точки восстановления являются действительно полезными, поскольку нет инструментов, которые помогли бы вам точно определить, какой идентификатор транзакции использовать.

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

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

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

Каждый раз, когда создается новая временная шкала, Tantor SE создает файл “истории временных шкал”, который показывает, от какой временной шкалы она отклонилась и когда. Эти файлы истории необходимы для того, чтобы система могла выбрать правильные файлы сегментов WAL при восстановлении из архива, содержащего несколько временных шкал. Поэтому они архивируются в область архива WAL так же, как и файлы сегментов WAL. Файлы истории - это просто небольшие текстовые файлы, поэтому их долго хранить недорого (в отличие от больших файлов сегментов). Если хотите, вы можете добавить комментарии в файл истории, чтобы записать свои собственные заметки о том, как и почему была создана эта конкретная временная шкала. Такие комментарии будут особенно полезны, когда у вас есть множество разных временных шкал в результате экспериментов.

Сохраняется стандартное поведение восстановления до последней найденной временной линии в архиве. Если нужно восстановиться до временной линии, которая была актуальной на момент создания базовой резервной копии или в конкретную дочернюю временную линию (то есть, нужно вернуться к состоянию, которое было сгенерировано после попытки восстановления), необходимо указать current или идентификатор целевой временной линии в 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 довольно громоздкий, так как он включает множество снимков дисковых страниц. Эти снимки страниц предназначены для поддержки восстановления после сбоя, поскольку нам может потребоваться исправить частично записанные дисковые страницы. В зависимости от аппаратного и программного обеспечения вашей системы риск частичных записей может быть достаточно мал, чтобы его можно было игнорировать. В этом случае вы можете значительно сократить общий объем архивных журналов, отключив снимки страниц с помощью параметра full_page_writes. (Прочитайте заметки и предупреждения в разделе Глава 29 перед этим). Отключение снимков страниц не мешает использованию журналов для операций восстановления в точку во времени (PITR). Одной из областей для будущего развития является сжатие архивных данных WAL путем удаления ненужных копий страниц, даже если full_page_writes включен. В промежутке администраторы могут пожелать сократить количество включенных в WAL снимков страниц, увеличив интервалы контрольных точек настолько, насколько это возможно.