19.5. Журнал записи перед обработкой#

19.5. Журнал записи перед обработкой

19.5. Журнал записи перед обработкой

Для получения дополнительной информации по настройке этих параметров см. Раздел 29.5.

19.5.1. Настройки

wal_level (enum)

wal_level определяет, сколько информации записывается в WAL. Значение по умолчанию - replica, которое записывает достаточно данных для поддержки архивирования и репликации WAL, включая выполнение запросов только для чтения на резервном сервере. minimal удаляет все ведение журнала, кроме информации, необходимой для восстановления после сбоя или немедленного выключения. Наконец, logical добавляет информацию, необходимую для поддержки логического декодирования. Каждый уровень включает информацию, зарегистрированную на всех более низких уровнях. Этот параметр может быть установлен только при запуске сервера.

Уровень minimal генерирует наименьший объем WAL. Он не регистрирует информацию о строках для постоянных отношений в транзакциях, которые создают или перезаписывают их. Это может значительно ускорить операции (см. Раздел 14.4.7). Операции, которые инициируют эту оптимизацию, включают:

ALTER ... SET TABLESPACE
CLUSTER
CREATE TABLE
REFRESH MATERIALIZED VIEW (без опции CONCURRENTLY)
REINDEX
TRUNCATE

Однако, минимальный WAL не содержит достаточной информации для восстановления в определенный момент времени, поэтому необходимо использовать режим replica или выше, чтобы включить непрерывное архивирование (archive_mode) и двоичную потоковую репликацию. Фактически, сервер даже не запустится в этом режиме, если max_wal_senders не равно нулю. Обратите внимание, что изменение значения wal_level на minimal делает предыдущие базовые резервные копии непригодными для восстановления в определенный момент времени и для резервных серверов.

На logical уровне, та же информация регистрируется, что и с replica, плюс информация, необходимая для извлечения логических наборов изменений из WAL. Использование уровня logical увеличит объем WAL, особенно если множество таблиц настроено на REPLICA IDENTITY FULL и выполняется множество операторов UPDATE и DELETE.

В версиях до 9.6 этот параметр также позволял использовать значения archive и hot_standby. Они по-прежнему принимаются, но отображаются как replica.

fsync (boolean)

Если этот параметр включен, сервер Tantor SE будет пытаться убедиться, что обновления физически записываются на диск, выполняя системные вызовы fsync() или различные эквивалентные методы (см. wal_sync_method). Это гарантирует, что кластер базы данных сможет восстановиться в согласованное состояние после сбоя операционной системы или оборудования.

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

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

Для надежного восстановления при изменении параметра fsync с off на on необходимо принудительно записать все измененные буферы ядра на надежное хранилище. Это можно сделать при выключенном кластере или при включенном параметре fsync, запустив команду initdb --sync-only, выполнение команды sync, отмонтирование файловой системы или перезагрузку сервера.

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

fsync может быть установлен только в файле postgresql.conf или в командной строке сервера. Если вы отключите этот параметр, также рассмотрите возможность отключения full_page_writes.

synchronous_commit (enum)

Определяет, насколько должна быть завершена обработка WAL, прежде чем сервер базы данных вернет клиенту индикацию "успех". Допустимые значения: remote_apply, on (по умолчанию), remote_write, local, and off.

Если параметр synchronous_standby_names пустой, единственные значимые настройки - on и off; remote_apply, remote_write и local предоставляют тот же уровень локальной синхронизации, что и on. Локальное поведение всех режимов, отличных от off, заключается в ожидании локальной записи WAL на диск. В режиме off ожидания нет, поэтому может быть задержка между моментом сообщения об успехе клиенту и моментом, когда транзакция будет гарантированно безопасна от сбоя сервера. (Максимальная задержка составляет три раза wal_writer_delay). В отличие от fsync, установка этого параметра в off не создает никакого риска несогласованности базы данных: сбой операционной системы или базы данных может привести к потере некоторых недавно предположительно зафиксированных транзакций, но состояние базы данных будет таким же, как если бы эти транзакции были чисто отменены. Таким образом, отключение параметра synchronous_commit может быть полезной альтернативой, когда надежность важнее точной гарантии надежности транзакции. Для более подробного обсуждения см. Раздел 29.4.

Если synchronous_standby_names не пусто, то synchronous_commit также контролирует, будут ли транзакции ожидать обработки своих записей WAL на сервере(ах) резервного копирования.

Когда установлено значение remote_apply, коммиты будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и применили ее, чтобы она стала видимой для запросов на репликах и также записана на надежное хранилище на репликах. Это приведет к значительно большим задержкам коммита по сравнению с предыдущими настройками, так как она ожидает воспроизведения WAL. Когда установлено значение on, коммита будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и записали ее на надежное хранилище. Это гарантирует, что транзакция не будет потеряна, если как основной сервер, так и все синхронные реплики подвергнутся повреждению хранилища базы данных. Когда установлено значение remote_write, коммита будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и записали ее в свои файловые системы. Эта настройка гарантирует сохранение данных, если резервная копия Tantor SE аварийно завершится, но не гарантирует сохранение данных, если резервная копия аварийно завершится на уровне операционной системы, поскольку данные не обязательно достигли надежного хранилища на резервной копии. Настройка local заставляет коммиты ожидать локальной записи на диск, но не ожидать репликации. Это обычно не желательно при использовании синхронной репликации, но предоставляется для полноты.

Этот параметр можно изменить в любое время; поведение для каждой отдельной транзакции определяется настройкой, действующей в момент коммита. Поэтому возможно и полезно иметь некоторые транзакции, которые коммитятся синхронно, а другие - асинхронно. Например, чтобы сделать так,чтобы одна многооператорная транзакция коммитилась асинхронно, когда значение по умолчанию противоположное, выполните команду SET LOCAL synchronous_commit TO OFF внутри транзакции.

Таблица 19.1 подводит итоги возможностей настроек synchronous_commit.

Таблица 19.1. Режимы synchronous_commit

Настройка synchronous_commitЛокальный надежный коммитНадежный коммит реплики после сбоя PGНадежный коммит реплики после сбоя ОССогласованность запросов на реплике
remote_apply
on 
remote_write  
local   
off    

wal_sync_method (enum)

Метод, используемый для принудительной записи журнала транзакций (WAL) на диск. Если параметр fsync выключен, то этот параметр не имеет значения, поскольку обновления WAL-файлов не будут принудительно записываться на диск. Возможные значения:

  • open_datasync (записывает WAL-файлы с опцией open() O_DSYNC)

  • fdatasync (вызов fdatasync() при каждом коммите)

  • fsync (вызывает fsync() после каждого коммита)

  • fsync_writethrough (вызывает fsync() при каждом коммите, принудительно записывая любой кеш записи на диск)

  • open_sync (записывать файлы WAL с опцией open() O_SYNC)

Варианты с префиксом open_* также используют O_DIRECT, если это возможно. Не все эти варианты доступны на всех платформах. По умолчанию используется первый метод из списка выше, который поддерживается платформой, за исключением того, что на Linux и FreeBSD по умолчанию используется fdatasync. По умолчанию это не обязательно оптимальный вариант; возможно, потребуется изменить эту настройку или другие аспекты конфигурации системы, чтобы создать надежную конфигурацию или достичь оптимальной производительности. Эти аспекты обсуждаются в разделе Раздел 29.1. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

full_page_writes (boolean)

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

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

Отключение этого параметра не влияет на использование архивирования WAL для восстановления до точки во времени (PITR) (см. Раздел 25.3).

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. По умолчанию он установлен в значение on.

wal_log_hints (boolean)

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

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

Этот параметр может быть установлен только при запуске сервера. Значение по умолчанию - off.

wal_compression (enum)

Этот параметр позволяет сжимать WAL с использованием указанного метода сжатия. При включении сервер Tantor SE сжимает полные изображения страниц, записанные в WAL, когда full_page_writes включен или во время базовой резервной копии. Сжатое изображение страницы будет разархивировано во время воспроизведения WAL. Поддерживаемые методы - pglz, lz4 (если Tantor SE был скомпилирован с --with-lz4) и zstd (если Tantor SE был скомпилирован с --with-zstd). Значение по умолчанию - off. Изменить этот параметр могут только суперпользователи и пользователи с соответствующими привилегиями SET.

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

wal_init_zero (boolean)

Если установлено значение on (по умолчанию), эта опция приводит к заполнению новых файлов журнала предзаписи нулями. На некоторых файловых системах это гарантирует выделение места перед записью записей WAL. Однако, Copy-On-Write (файловые системы с копированием при записи, COW) могут не выигрывать от этой техники, поэтому предоставляется возможность пропустить ненужную работу. Если установлено значение off, при создании файла записывается только последний байт, чтобы он имел ожидаемый размер.

wal_recycle (boolean)

Если установлено значение on (по умолчанию), эта опция вызывает переименование файлов WAL для их повторного использования, избегая необходимости создания новых файлов. На файловых системах COW может быть быстрее создавать новые файлы, поэтому предоставляется возможность отключить это поведение.

wal_buffers (integer)

Количество общей памяти, используемой для данных WAL, которые еще не были записаны на диск. Значение по умолчанию -1 выбирает размер, равный 1/32 (примерно 3%) от shared_buffers, но не менее 64kB и не более размера одного сегмента WAL, обычно 16MB. Это значение можно установить вручную, если автоматический выбор слишком большой или слишком маленький, но любое положительное значение меньше 32kB будет рассматриваться как 32kB. Если это значение указано без единиц измерения, оно принимается в качестве блоков WAL, то есть XLOG_BLCKSZ байт, обычно 8kB. Этот параметр может быть установлен только при запуске сервера.

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

wal_writer_delay (integer)

Определяет, с какой периодичностью происходит сброс WAL-журнала в файловую систему. После сброса WAL-журнала писатель спит в течение времени, указанного в параметре wal_writer_delay, если его не разбудит асинхронно выполняющаяся транзакция. Если последний сброс произошел менее wal_writer_delay назад и за это время было создано менее wal_writer_flush_after объема WAL-журнала, то WAL-журнал записывается только в операционную систему, а не сбрасывается на диск. Если значение не указано с единицами измерения, оно считается в миллисекундах. Значение по умолчанию - 200 миллисекунд (200ms). Обратите внимание, что на многих системах эффективное разрешение задержек сна составляет 10 миллисекунд; установка значения wal_writer_delay, не кратного 10, может привести к тем же результатам, что и установка следующего более высокого кратного 10. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

wal_writer_flush_after (integer)

Определяет, как часто происходит сброс записей WAL в терминах объема. Если последний сброс произошел менее чем wal_writer_delay назад и меньше чем wal_writer_flush_after записей WAL было создано с тех пор, то записи WAL записываются только в операционную систему, а не сбрасываются на диск. Если wal_writer_flush_after установлено в 0, то данные WAL всегда сразу сбрасываются. Если это значение указано без единиц измерения, оно считается в блоках WAL, то есть XLOG_BLCKSZ байт, обычно 8 КБ. По умолчанию установлено значение 1 МБ. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

wal_skip_threshold (integer)

Когда wal_level установлен в minimal и транзакция коммитится после создания или перезаписи постоянного отношения, эта настройка определяет, как сохранить новые данные. Если размер данных меньше этой настройки, они записываются в журнал WAL; в противном случае используется fsync для затронутых файлов. В зависимости от свойств вашего хранилища, повышение или понижение этого значения может помочь, если такие коммиты замедляют параллельные транзакции. Если это значение указано без единиц измерения, оно считается в килобайтах. Значение по умолчанию - два мегабайта (2MB).

wal_sender_stop_when_crc_failed (bool)

Если wal-sender-stop-when-crc-failed имеет значение true, страницы данных WAL проверяются на контрольную сумму. Если контрольная сумма не верна, страница данных сохраняется из буфера. Если мы не можем прочитать ее из буфера, walsender останавливается.

commit_delay (integer)

Установка параметра commit_delay добавляет задержку времени перед инициированием сброса WAL. Это может улучшить пропускную способность группового коммита, позволяя большему количеству транзакций подтверждаться через один сброс WAL, если нагрузка на систему достаточно высока, чтобы дополнительные транзакции стали готовы к коммиту в заданный интервал. Однако это также увеличивает задержку на время commit_delay для каждого сброса WAL. Поскольку задержка просто теряется, если другие транзакции не готовы к коммиту, задержка выполняется только в том случае, если при инициировании сброса активны как минимум commit_siblings других транзакций. Также задержки не выполняются, если fsync отключен. Если это значение указано без единиц измерения, оно принимается в микросекундах. Значение по умолчанию для commit_delay - ноль (без задержки). Изменить этот параметр могут только суперпользователи и пользователи с соответствующими привилегиями SET.

В релизах Tantor SE до 9.3 параметр commit_delay вел себя иначе и был гораздо менее эффективным: он влиял только на коммит транзакций, а не на все записи WAL, и ждал весь заданный интервал, даже если запись WAL была завершена раньше. Начиная с PostgreSQL 9.3, первый процесс, готовый к записи, ждет заданный интервал, в то время как последующие процессы ждут только до завершения операции записи лидером.

commit_siblings (integer)

Минимальное количество одновременно открытых транзакций, которое требуется для выполнения задержки commit_delay перед коммитом. Большее значение увеличивает вероятность того, что хотя бы одна другая транзакция будет готова к коммиту в течение интервала задержки. Значение по умолчанию - пять транзакций.

19.5.2. Контрольные точки

checkpoint_timeout (integer)

Максимальное время между автоматическими контрольными точками WAL. Если это значение указано без единиц измерения, оно считается в секундах. Допустимый диапазон составляет от 30 секунд до одного дня. По умолчанию установлено пять минут (5min). Увеличение этого параметра может увеличить время, необходимое для восстановления после сбоя. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

checkpoint_completion_target (floating point)

Указывает цель завершения контрольной точки в виде доли от общего времени между контрольными точками. По умолчанию значение равно 0.9, что позволяет распределить контрольную точку почти на всем доступном интервале, обеспечивая достаточно стабильную нагрузку на ввод-вывод, а также оставляя некоторое время для завершения контрольной точки. Снижение этого параметра не рекомендуется, поскольку это приводит к более быстрому завершению контрольной точки. Это приводит к увеличению издержек на ввод-вывод во время контрольной точки, а затем к периоду меньших издержек на ввод-вывод между завершением контрольной точки и следующей запланированной контрольной точкой. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

checkpoint_flush_after (integer)

Всякий раз, когда было записано больше этого количества данных во время выполнения контрольной точки, попытайтесь заставить ОС выполнять эти записи в основное хранилище. Это позволит ограничить количество грязных данных в кеше страниц ядра, уменьшая вероятность задержек при выполнении fsync в конце контрольной точки или когда ОС записывает данные обратно в больших пакетах в фоновом режиме. Часто это приводит к существенному снижению задержки транзакции, но также есть случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может ухудшиться. Этот параметр может не иметь эффекта на некоторых платформах. Если это значение указано без единиц измерения, оно принимается в блоках, то есть в байтах BLCKSZ, обычно 8 КБ. Допустимый диапазон значений составляет от 0, что отключает принудительную запись, до 2MB. По умолчанию на Linux -256kB, в остальных случаях - 0. (Если BLCKSZ не равно 8 КБ, значения по умолчанию и максимальные значения масштабируются пропорционально ему). Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

checkpoint_warning (integer)

Записывает сообщение в журнал сервера, если контрольные точки, вызванные заполнением файлов сегментов WAL, происходят ближе друг к другу, чем указанное время (что указывает на необходимость увеличения значения max_wal_size). Если это значение указано без единиц измерения, оно считается в секундах. По умолчанию установлено значение 30 секунд (30s). Значение 0 отключает предупреждение. Предупреждения не будут генерироваться, если значение checkpoint_timeout меньше значения checkpoint_warning. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

max_wal_size (integer)

Максимальный размер, до которого может расти WAL во время автоматических контрольных точек. Это мягкое ограничение; размер WAL может превышать значение max_wal_size в особых случаях, таких как высокая нагрузка, сбой archive_command или archive_library, или высокое значение wal_keep_size. Если это значение указано без единиц измерения, оно считается в мегабайтах. По умолчанию установлено значение 1 ГБ. Увеличение этого параметра может увеличить время, необходимое для восстановления после сбоя. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

min_wal_size (integer)

Пока использование диска для WAL остается ниже этого значения, старые файлы WAL всегда перерабатываются для будущего использования на контрольной точке, а не удаляются. Это может быть использовано для обеспечения достаточного пространства WAL для обработки всплесков использования WAL, например, при выполнении больших пакетных заданий. Если это значение указано без единиц измерения, оно принимается в мегабайтах. Значение по умолчанию - 80 МБ. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

19.5.3. Архивирование

archive_mode (enum)

Когда archive_mode включен, завершенные сегменты WAL отправляются в архивное хранилище путем установки archive_command или archive_library. Кроме значения off, чтобы отключить, существуют два режима: on и always. Во время нормальной работы между двумя режимами нет разницы, но когда установлен режим always, архиватор WAL также включен во время восстановления из архива или в режиме ожидания. В режиме always все файлы, восстановленные из архива или переданные с помощью потоковой репликации, будут снова архивированы. См. Раздел 26.2.9 для получения дополнительной информации.

archive_mode - отдельная настройка от archive_command и archive_library, чтобы archive_command и archive_library можно было изменить без выхода из режима архивирования. Этот параметр может быть установлен только при запуске сервера. archive_mode не может быть включен, когда wal_level установлен в minimal.

archive_command (string)

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

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера. Он игнорируется, если параметр archive_mode был включен при запуске сервера и параметр archive_library установлен в пустую строку. Если параметр archive_command является пустой строкой (по умолчанию), в то время как параметр archive_mode включен (и параметр archive_library установлен в пустую строку), архивирование WAL временно отключается, но сервер продолжает накапливать файлы сегментов WAL в ожидании предоставления команды. Установка параметра archive_command на команду, которая ничего не делает, но возвращает true, например, /bin/true (REM в Windows), эффективно отключает архивирование, но также нарушает цепочку файлов журнала предзаписи, необходимых для восстановления из архива, поэтому он должен использоваться только в необычных случаях.

archive_library (string)

Библиотека, используемая для архивирования завершенных сегментов файлов журнала предзаписи. Если установлено пустое значение (по умолчанию), включено архивирование через оболочку, и используется параметр archive_command. В противном случае, указанная общая библиотека используется для архивирования. Процесс архивации WAL перезапускается постмастер при изменении этого параметра. Дополнительную информацию см. в разделах Раздел 25.3.1 и Глава 49.

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

archive_timeout (integer)

xref linkend="guc-archive-command"/> или archive_library вызывается только для завершенных сегментов WAL. Поэтому, если ваш сервер генерирует мало трафика WAL (или имеет периоды простоя, когда это происходит), может возникнуть длительная задержка между завершением транзакции и ее безопасной записью в архивное хранилище. Чтобы ограничить возможный возраст неархивированных данных, вы можете установить archive_timeout для принудительного переключения сервера на новый файл сегмента WAL периодически. Когда этот параметр больше нуля, сервер переключается на новый файл сегмента, когда прошло указанное количество времени с момента последнего переключения файла сегмента, и была какая-либо активность в базе данных, включая одну контрольную точку (контрольные точки пропускаются, если нет активности в базе данных). Обратите внимание, что архивные файлы, которые закрываются раньше из-за принудительного переключения, все равно имеют такую же длину, как и полностью заполненные файлы. Поэтому не рекомендуется использовать очень короткий archive_timeout — это приведет к раздутию вашего архивного хранилища. Обычно разумными являются значения archive_timeout в минуту или около того. Если вы хотите, чтобы данные были скопированы с первичного сервера быстрее, рассмотрите возможность использования потоковой репликации вместо архивирования. Если это значение указано без единиц измерения, оно считается в секундах. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

19.5.4. Восстановление

Этот раздел описывает настройки, которые применяются к восстановлению в общем, влияющие на восстановление после сбоя, потоковую репликацию и репликацию на основе архива.

recovery_prefetch (enum)

Определяет, следует ли предварительно загружать блоки, на которые ссылается WAL и которые еще не находятся в буферном пуле, во время восстановления. Допустимые значения: off, on и try (по умолчанию). Значение try включает предварительную загрузку только в том случае, если операционная система предоставляет функцию posix_fadvise, которая в настоящее время используется для реализации предварительной загрузки. Обратите внимание, что некоторые операционные системы предоставляют эту функцию, но она ничего не делает.

Предварительная загрузка блоков, которые скоро понадобятся, может сократить время ожидания ввода-вывода во время восстановления с некоторыми рабочими нагрузками. См. также параметры wal_decode_buffer_size и maintenance_io_concurrency, которые ограничивают активность предварительной загрузки.

wal_decode_buffer_size (integer)

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

19.5.5. Восстановление архива

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

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

Для запуска сервера в режиме ожидания, создайте файл с именем standby.signal в каталоге данных. Сервер перейдет в режим восстановления и не остановится восстановление, когда достигнут конец архивного WAL, но будет продолжать попытки продолжить восстановление, подключаясь к отправляющему серверу, указанному в параметре primary_conninfo и/или получая новые сегменты WAL с помощью restore_command. Для этого режима интересны параметры из этого раздела и Раздел 19.6.3. Параметры из Раздел 19.5.6 также будут применяться, но обычно не полезны в этом режиме.

Для запуска сервера в целевом режиме восстановления создайте файл с именем recovery.signal в каталоге данных. Если созданы оба файла standby.signal и recovery.signal, режим ожидания имеет приоритет. Целевой режим восстановления завершается, когда все архивные WAL-файлы полностью воспроизведены или достигнута переменная recovery_target. В этом режиме будут использоваться параметры как из этого раздела, так и из Раздел 19.5.6.

restore_command (string)

Команда локальной оболочки для выполнения, чтобы получить архивный сегмент серии файлов журнала предзаписи. Этот параметр требуется для восстановления из архива, но необязателен для потоковой репликации. Любой %f в строке заменяется именем файла, который нужно получить из архива, и любой %p заменяется именем пути назначения копии на сервере. (Путь относительно текущего рабочего каталога, то есть каталога данных кластера). Любой %r заменяется именем файла, содержащего последнюю допустимую точку перезапуска. Это самый ранний файл, который должен быть сохранен для возможности перезапуска восстановления, поэтому эта информация может быть использована для обрезки архива только до минимально необходимого для поддержки перезапуска с текущего восстановления. %r обычно используется только в конфигурациях теплого резервирования (см. Раздел 26.2). Запишите %%, чтобы вставить фактический символ %.

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

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

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

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

archive_cleanup_command (string)

Этот необязательный параметр указывает команду интерпретатора (оболочки), которая будет выполнена при каждой точке перезапуска. Целью параметра archive_cleanup_command является предоставление механизма для очистки старых архивных файлов журнала предзаписи, которые больше не нужны серверу-резервной копии. Любое вхождение %r заменяется именем файла, содержащего последнюю допустимую точку перезапуска. Это самый ранний файл, который необходимо сохранить, чтобы возможно было выполнить восстановление с возможностью перезапуска, и поэтому все файлы, предшествующие %r, можно безопасно удалить. Эта информация может быть использована для обрезки архива до минимально необходимого объема, необходимого для поддержки перезапуска из текущего восстановления. Модуль pg_archivecleanup часто используется в параметре archive_cleanup_command для конфигураций с одной резервной копией, например:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

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

Если команда возвращает ненулевой код завершения, то будет записано предупреждающее сообщение в журнале. Исключение составляет случай, когда команда была прервана сигналом или ошибкой оболочки (например, команда не найдена), в этом случае будет вызвана критическая ошибка.

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

recovery_end_command (string)

Этот параметр указывает команду оболочки, которая будет выполнена только один раз в конце восстановления. Этот параметр является необязательным. Целью recovery_end_command является предоставление механизма для очистки после репликации или восстановления. Любое %r заменяется именем файла, содержащего последнюю допустимую точку перезапуска, как в archive_cleanup_command.

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

Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

19.5.6. Цель восстановления

По умолчанию восстановление будет выполняться до конца журнала WAL. Следующие параметры могут быть использованы для указания более ранней точки остановки. В конфигурационном файле может быть указан только один из параметров recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time или recovery_target_xid; если в конфигурационном файле указано более одного из этих параметров, будет вызвана ошибка. Эти параметры могут быть установлены только при запуске сервера.

recovery_target = 'immediate'

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

Технически, это строковый параметр, но 'immediate' в настоящее время является единственным допустимым значением.

recovery_target_name (string)

Этот параметр указывает именованную точку восстановления (созданную с помощью pg_create_restore_point()), к которой будет выполняться восстановление.

recovery_target_time (timestamp)

Этот параметр определяет временную метку, до которой будет выполняться восстановление. Точная точка остановки также зависит от recovery_target_inclusive.

Значение этого параметра - это временная метка в том же формате, принимаемом типом данных timestamp with time zone, за исключением того, что нельзя использовать сокращение часового пояса (если переменная timezone_abbreviations была установлена ранее в файле конфигурации). Предпочтительным стилем является использование числового смещения от UTC, или вы можете указать полное название часового пояса, например, Europe/Helsinki, а не EEST.

recovery_target_xid (string)

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

recovery_target_lsn (pg_lsn)

Этот параметр указывает LSN местоположения журнала предварительной записи, до которого будет выполняться восстановление. Точная точка остановки также зависит от recovery_target_inclusive. Этот параметр разбирается с использованием системного типа данных pg_lsn.

Следующие параметры дополнительно определяют цель восстановления и влияют на то, что происходит при достижении цели:

recovery_target_inclusive (boolean)

Определяет, остановиться ли сразу после указанной цели восстановления (on), или непосредственно перед целью восстановления (off). Применяется, когда указаны recovery_target_lsn, recovery_target_time или recovery_target_xid. Этот параметр управляет включением транзакций, имеющих точное местоположение WAL (LSN), время коммита или идентификатор транзакции, соответственно, в процессе восстановления. По умолчанию on.

recovery_target_timeline (string)

Указывает восстановление в определенную временную линию. Значение может быть числовым идентификатором временной линии или специальным значением. Значение current восстанавливает в ту же временную линию, которая была актуальной при создании базовой резервной копии. Значение latest восстанавливает в последнюю временную линию, найденную в архиве, что полезно для сервера-резервной копии. Значение latest является значением по умолчанию.

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

recovery_target_action (enum)

Определяет, какое действие сервер должен выполнить после достижения цели восстановления. По умолчанию используется значение pause, что означает приостановку восстановления. Значение promote означает завершение процесса восстановления и запуск сервера для принятия подключений. Наконец, значение shutdown остановит сервер после достижения цели восстановления.

Цель использования настройки pause состоит в том, чтобы позволить выполнение запросов к базе данных для проверки, является ли этот целевой момент восстановления наиболее желательным. Приостановленное состояние можно возобновить с помощью функции pg_wal_replay_resume() (см. Таблица 9.91), что приведет к завершению процесса восстановления. Если этот целевой момент восстановления не является желаемой точкой остановки, то следует выключить сервер, изменить настройки целевого момента восстановления на более поздний и перезапустить для продолжения восстановления.

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

Обратите внимание, что поскольку файл recovery.signal не будет удален, когда recovery_target_action установлено в shutdown, любое последующее запуск будет завершаться немедленным выключением, если конфигурация не изменена или файл recovery.signal не будет удален вручную.

Эта настройка не имеет эффекта, если не установлена цель восстановления. Если hot_standby не включено, установка pause будет действовать так же, как shutdown. Если цель восстановления достигнута во время продвижения, установка pause будет действовать так же, как promote.

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