Журнал записи с опережением (WAL)

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

Настройки

wal_level (enum)

Со значением replica (по умолчанию) в журнал записываются данные, необходимые для поддержки архивирования WAL и репликации, включая запросы только на чтение на ведомом сервере. Уровень minimal оставляет только информацию, необходимую для восстановления после сбоя или аварийного отключения. Уровень logical добавляет информацию, требующуюся для поддержки логического декодирования. Каждый последующий уровень включает информацию, записываемую на всех уровнях ниже. Задать этот параметр можно только при запуске сервера.

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

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)

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

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

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

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

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

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

synchronous_commit (enum)

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

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

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

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

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

Таблица ниже суммирует возможности параметра synchronous_commit.

Режимы synchronous_commit:

параметр synchronous_commit	локальное долговечное подтверждение	резервное долговечное подтверждение после сбоя PG	резервное долговечное подтверждение после сбоя ОС	согласованность запроса резервного копирования
удаленное_применение	•	•	•	•
на	•	•	•
удаленная_запись	•	•
локальная	•
выключено

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); Не все эти варианты доступны на всех платформах. По умолчанию используется первый метод в приведенном выше списке, который поддерживается платформой, за исключением того, что fdatasync является значением по умолчанию в Linux и FreeBSD. Значение по умолчанию не обязательно идеально; может потребоваться изменить эту настройку или другие аспекты конфигурации системы для создания конфигураций, защищенных от сбоев, или достижения оптимальной производительности. Эти аспекты обсуждаются в Разделе Надежность. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.

full_page_writes (boolean)

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

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

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

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

wal_log_hints (boolean)

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

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

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

wal_compression (enum)

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

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

wal_init_zero (boolean)

Если установлено значение on (по умолчанию), эта опция приводит к заполнению новых файлов WAL нулями. В некоторых файловых системах это гарантирует выделение места до того, как потребуется записать записи 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 байт, обычно 8 КБ. Этот параметр можно задать только при запуске сервера.

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

wal_writer_delay (integer)

Указывает, как часто писатель WAL сбрасывает 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 с точки зрения объема. Если последняя очистка произошла менее wal_writer_delay назад и с тех пор было произведено менее wal_writer_flush_after WAL, то WAL записывается только в операционную систему, а не очищается на диск. Если wal_writer_flush_after установлен на 0 , то данные WAL всегда немедленно очищаются. Если это значение указано без единиц измерения, оно принимается за блоки WAL, т.е. XLOG_BLCKSZ байт, обычно 8 кБ. По умолчанию установлено значение 1MB . Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

wal_skip_threshold (integer)

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

commit_delay (integer)

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

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

commit_siblings (integer)

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

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

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. По умолчанию используется 256kB в Linux, 0 в других местах. (Если BLCKSZ не равен 8 КБ, значения по умолчанию и максимальные значения пропорционально масштабируются до него.) Этот параметр можно задать только в файле postgresql.conf или в командной строке сервера.

checkpoint_warning (integer)

Записать сообщение в журнал сервера, если контрольные точки, вызванные заполнением файлов сегментов WAL, происходят чаще, чем через этот промежуток времени (что предполагает, что max_wal_size следует увеличить). Если это значение указано без единиц измерения, оно принимается за секунды. По умолчанию - 30 секунд (30s). Ноль отключает предупреждение. Предупреждения не будут генерироваться, если 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 или в командной строке сервера.

Архивация

archive_mode (enum)

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

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

archive_command (string)

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

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

archive_library (string)

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

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

archive_timeout (integer)

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

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

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

recovery_prefetch (enum)

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

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

wal_decode_buffer_size (integer)

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

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

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

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

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

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

restore_command (string)

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

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

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 заключается в предоставлении механизма для очистки старых архивных файлов WAL, которые больше не нужны резервному серверу. Любая %r заменяется именем файла, содержащего последнюю допустимую точку восстановления. Это самый ранний файл, который должен быть сохранен для того, чтобы восстановить возможность перезапуска, поэтому все файлы, предшествующие %r, могут быть безопасно удалены. Эта информация может использоваться для обрезки архива до минимально необходимого для поддержки возобновления текущего восстановления. Модуль pg_archivecleanup часто используется в archive_cleanup_command для конфигураций с одним резервным копированием, например:

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

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

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

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

recovery_end_command (string)

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

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

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

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

По умолчанию восстановление будет выполняться до конца журнала 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 является значением по умолчанию.

Чтобы указать идентификатор линии времени в шестнадцатеричном формате (например, если он извлечен из имени файла WAL или файла истории), добавьте к нему префикс 0x. Например, если имя файла WAL — 00000011000000A10000004F, то идентификатор линии времени — 0x11 (или десятичное число 17).

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

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 не будет удален вручную.

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

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

Создание сводок WAL

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

summarize_wal (boolean)

Включает процесс создания сводок WAL. Обратите внимание, что создание сводок WAL можно включить как на ведущем, так и на резервном сервере. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. По умолчанию off.

Сервер не может быть запущен с summarize_wal=on, если wal_level имеет значение minimal. Если после запуска сервера задать summarize_wal=on, когда wal_level=minimal, процесс создания сводок запустится, но не станет создавать файлы сводок для WAL, сгенерированных с wal_level=minimal.

wal_summary_keep_time (integer)

Задает время, по истечении которого процесс создания сводок WAL автоматически удаляет старые сводки. Чтобы определять, какие файлы подлежат удалению, используются их временные метки. Обычно значение следует установить с запасом на время, превышающее интервал между полным резервным копированием и последующим инкрементальным резервным копированием. Сводки WAL должны быть доступны для всего диапазона изменений между предыдущей копией и новой, иначе создание инкрементальной копии завершится ошибкой. Если значение этого параметра равно нулю, сводки WAL не будут автоматически удаляться, но можно вручную удалять файлы, которые не требуются для будущих инкрементальных резервных копий. Этот параметр можно задать только в postgresql.conf или в командной строке при запуске сервера. Если значение задано без единиц измерения, оно считается заданным в минутах. Значение по умолчанию — 10 дней. Если summarize_wal = off, существующие сводки WAL не будут удаляться независимо от значения этого параметра, поскольку процесс создания сводок WAL не запустится.