18.5. Журнал предзаписи
За дополнительной информацией о настройке этих параметров обратитесь к Разделу 28.5.
18.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
Однако минимальный журнал не будет содержать достаточно информации для восстановления на момент времени, поэтому для включения непрерывной архивации (archive_mode) и потоковой двоичной репликации необходимо использовать уровень не ниже
replica
. Фактически сервер даже не запустится в этом режиме, если значениеmax_wal_senders
отлично от нуля. Заметьте, что в случае изменения значенияwal_level
наminimal
сделанные ранее базовые копии становятся непригодными для восстановления на момент времени и для резервных серверов.На уровне
logical
в журнал записывается та же информация, что и на уровнеreplica
, плюс информация, необходимая для извлечения из журнала наборов логических изменений. Повышение уровня доlogical
приводит к значительному увеличению объёма WAL, особенно если многие таблицы имеют характеристикуREPLICA IDENTITY FULL
и выполняется множество командUPDATE
иDELETE
.В выпусках до 9.6 для этого параметра допускались значения
archive
иhot_standby
. Эти значения по-прежнему принимаются, но теперь отображаются в значениеreplica
.fsync
(boolean
)Если этот параметр установлен, сервер Postgres Pro старается добиться, чтобы изменения были записаны на диск физически, выполняя системные вызовы
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
(локально) иoff
(выкл.).Если значение
synchronous_standby_names
не задано, для данного параметра имеют смысл только значенияon
иoff
; с вариантамиremote_apply
,remote_write
иlocal
будет выбран тот же уровень синхронизации, что и сon
. Локальное действие всех отличных отoff
режимов заключается в ожидании локального сброса WAL на диск. В режимеoff
ожидание отсутствует, поэтому может образоваться окно от момента, когда клиент узнаёт об успешном завершении, до момента, когда транзакция действительно гарантированно защищена от сбоя. (Максимальный размер окна равен тройному значению wal_writer_delay.) В отличие от fsync, значениеoff
этого параметра не угрожает целостности данных: сбой операционной системы или базы данных может привести к потере последних транзакций, считавшихся зафиксированными, но состояние базы данных будет точно таким же, как и в случае штатного прерывания этих транзакций. Поэтому выключение режимаsynchronous_commit
может быть полезной альтернативой отключению fsync, когда производительность важнее, чем надёжная гарантия сохранности каждой транзакции. Подробнее это обсуждается в Разделе 28.4.Если значение synchronous_standby_names не пустое, параметр
synchronous_commit
также определяет, должен ли сервер при фиксировании транзакции ждать, пока соответствующие записи WAL будут обработаны на ведомом сервере (серверах).Со значением
remote_apply
фиксирование завершается только после получения ответов от текущих синхронных ведомых серверов, говорящих, что они получили запись о фиксировании транзакции, сохранили её в надёжном хранилище, а также применили транзакцию, так что она стала видна для запросов на этих серверах. С таким вариантом задержка при фиксировании оказывается больше, так как необходимо дожидаться воспроизведения WAL. Со значениемon
фиксирование завершается только после получения ответов от текущих синхронных ведомых серверов, подтверждающих, что они получили запись о фиксировании транзакции и передали её в надёжном хранилище. Это гарантирует, что транзакция не будет потеряна, если только база данных не будет повреждена и на ведущем, и на всех синхронных ведомых серверах. Со значениемremote_write
фиксирование завершается после получения ответов от текущих синхронных серверов, говорящих, что они получили запись о фиксировании транзакции и сохранили её в своих ФС. Этот вариант позволяет гарантировать сохранность данных в случае отказа ведомого сервера Postgres Pro, но не в случае сбоя на уровне ОС, так как данные могут ещё не достичь надёжного хранилища на этом сервере. Со значениемlocal
фиксирование завершается после локального сброса данных, не дожидаясь репликации. Обычно это нежелательный вариант при синхронной репликации, но он представлен для полноты.Этот параметр можно изменить в любое время; поведение каждой конкретной транзакции определяется значением, действующим в момент её фиксирования. Таким образом, есть возможность и смысл фиксировать некоторые транзакции синхронно, а другие — асинхронно. Например, чтобы зафиксировать одну транзакцию из нескольких команд асинхронно, когда по умолчанию выбран противоположный вариант, выполните в этой транзакции
SET LOCAL synchronous_commit TO OFF
.Характеристики различных значений
synchronous_commit
сведены в Таблице 18.1.Таблица 18.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
. Выбираемый по умолчанию вариант не обязательно будет идеальным; в зависимости от требований к отказоустойчивости или производительности может потребоваться скорректировать выбранное значение или внести другие изменения в конфигурацию вашей системы. Соответствующие аспекты конфигурации рассматриваются в Разделе 28.1. Этот параметр можно задать только в файлеpostgresql.conf
или в командной строке при запуске сервера.full_page_writes
(boolean
)Когда этот параметр включён, сервер Postgres Pro записывает в WAL всё содержимое каждой страницы при первом изменении этой страницы после контрольной точки. Это необходимо, потому что запись страницы, прерванная при сбое операционной системы, может выполниться частично, и на диске окажется страница, содержащая смесь старых данных с новыми. При этом информации об изменениях на уровне строк, которая обычно сохраняется в WAL, будет недостаточно для получения согласованного содержимого такой страницы при восстановлении после сбоя. Сохранение образа всей страницы гарантирует, что страницу можно восстановить корректно, ценой увеличения объёма данных, которые будут записываться в WAL. (Так как воспроизведение WAL всегда начинается от контрольной точки, достаточно сделать это при первом изменении каждой страницы после контрольной точки. Таким образом, уменьшить затраты на запись полных страниц можно, увеличив интервалы контрольных точек.)
Отключение этого параметра ускоряет обычные операции, но может привести к неисправимому повреждению или незаметной порче данных после сбоя системы. Так как при этом возникают практически те же риски, что и при отключении
fsync
, хотя и в меньшей степени, отключать его следует только при тех же обстоятельствах, которые перечислялись в рекомендациях для вышеописанного параметра.Отключение этого параметра не влияет на возможность применения архивов WAL для восстановления состояния на момент времени (см. Раздел 24.3).
Этот параметр можно задать только в
postgresql.conf
или в командной строке при запуске сервера. По умолчанию этот параметр имеет значениеon
.wal_log_hints
(boolean
)Когда этот параметр имеет значение
on
, сервер Postgres Pro записывает в WAL всё содержимое каждой страницы при первом изменении этой страницы после контрольной точки, даже при второстепенных изменениях так называемых вспомогательных битов.Если включён расчёт контрольных сумм данных, изменения вспомогательных битов всегда проходят через WAL и этот параметр игнорируется. С помощью этого параметра можно проверить, насколько больше дополнительной информации записывалось бы в журнал, если бы для базы данных был включён подсчёт контрольных сумм.
Этот параметр можно задать только при запуске сервера. По умолчанию он имеет значение
off
.wal_compression
(enum
)Этот параметр включает сжатие WAL указанным методом. Если этот параметр имеет значение
on
, сервер Postgres Pro сжимает образы полных страниц, записываемые в WAL, когда включён режим full_page_writes или при создании базовой копии. Сжатый образ страницы будет развёрнут при воспроизведении WAL. Поддерживаемые методы:pglz
,lz4
(если Postgres Pro скомпилирован с параметром--with-lz4
) иzstd
(если Postgres Pro скомпилирован с параметром--with-zstd
). Значение по умолчанию —lz4
. Чтобы отключить сжатие, задайте этому параметру значениеoff
. Изменить этот параметр могут только суперпользователи и пользователи с соответствующим правомSET
.Включив сжатие, вы можете без дополнительных рисков повреждения данных уменьшить объём WAL, ценой дополнительной нагрузки на процессор, связанной со сжатием данных при записи в WAL и разворачиванием их при воспроизведении WAL.
wal_init_zero
(boolean
)Если этот параметр включён (
on
), создаваемые файлы WAL заполняются нулями. В ряде файловых систем благодаря этому заранее выделяется пространство, которое потребуется для записи WAL. Однако с файловыми системами, работающими по принципу COW (Copy-On-Write, Копирование при записи), это может быть бессмысленно, поэтому данный параметр позволяет отключить в данном случае неэффективное поведение. Со значениемoff
в создаваемый файл записывается только последний байт, чтобы файл WAL сразу обрёл желаемый размер.wal_recycle
(boolean
)Если этот параметр имеет значение
on
(по умолчанию), файлы WAL используются повторно (для этого они переименовываются), что избавляет от необходимости создавать новые файлы. В файловых системах COW может быть быстрее создать новые файлы, поэтому данный параметр позволяет отключить это поведение.wal_buffers
(integer
)Объём разделяемой памяти, который будет использоваться для буферизации данных WAL, ещё не записанных на диск. Значение по умолчанию, равное -1, задаёт размер, равный 1/32 (около 3%) от shared_buffers, но не меньше чем
64 КБ
и не больше чем размер одного сегмента WAL (обычно16 МБ
). Это значение можно задать вручную, если выбираемое автоматически слишком мало или велико, но при этом любое положительное число меньше32 КБ
будет восприниматься как32 КБ
. Если это значение задаётся без единиц измерения, оно считается заданным в блоках WAL (размер которых равенXLOG_BLCKSZ
байт, обычно это 8 КБ). Этот параметр можно задать только при запуске сервера.Содержимое буферов WAL записывается на диск при фиксировании каждой транзакции, так что очень большие значения вряд ли принесут значительную пользу. Однако значение как минимум в несколько мегабайт может увеличить быстродействие при записи на нагруженном сервере, когда сразу множество клиентов фиксируют транзакции. Автонастройка, действующая при значении по умолчанию (-1), в большинстве случаев выбирает разумные значения.
wal_writer_delay
(integer
)Определяет, с какой периодичностью процесс записи WAL будет сбрасывать WAL на диск. После очередного сброса WAL он делает паузу, длительность которой задаётся параметром
wal_writer_delay
, но может быть пробуждён асинхронно фиксируемой транзакцией. Если предыдущая операция сброса имела место в течение заданного параметромwal_writer_delay
времени и полученный за это время объём WAL не достиг значенияwal_writer_flush_after
, данные WAL только передаются ОС, но не сбрасываются на диск. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию — 200 миллисекунд (200ms
). Заметьте, что во многих системах разрешение таймера паузы составляет 10 мс; если задать вwal_writer_delay
значение, не кратное 10, может быть получен тот же результат, что и со следующим за ним кратным 10. Задать этот параметр можно только вpostgresql.conf
или в командной строке при запуске сервера.wal_writer_flush_after
(integer
)Определяет, при каком объёме процесс записи WAL будет сбрасывать WAL на диск. Если предыдущая операция сброса имела место в течение заданного параметром
wal_writer_delay
времени и полученный после неё объём WAL не достиг значенияwal_writer_flush_after
, данные WAL только передаются ОС, но не сбрасываются на диск. Еслиwal_writer_flush_after
равен0
, WAL сбрасывается на диск немедленно. Если это значение задаётся без единиц измерения, оно считается заданным в блоках WAL (размер которых равенXLOG_BLCKSZ
байт, обычно это 8 КБ). Значение по умолчанию — 1 мегабайт (1MB
). Задать этот параметр можно только вpostgresql.conf
или в командной строке при запуске сервера.wal_skip_threshold
(integer
)Когда выбран
wal_level
minimal
и фиксируется транзакция, которая создавала или перезаписывала постоянное отношение, этот параметр определяет, как будут сохраняться новые данные. Если объём данных меньше заданного значения, они будут записываться в журнал WAL; в противном случае затронутые файлы просто синхронизируются с ФС. Изменение этого параметра в зависимости от характеристик вашего хранилища может быть полезным, если при фиксировании такой транзакции наблюдается замедление других транзакций. Если это значение задаётся без единиц измерения, оно считается заданным в килобайтах. Значение по умолчанию — два мегабайта (2MB
).commit_delay
(integer
)Параметр
commit_delay
добавляет паузу перед собственно выполнением сохранения WAL. Эта задержка может увеличить быстродействие при фиксировании множества транзакций, позволяя зафиксировать большее число транзакций за одну операцию сохранения WAL, если система нагружена достаточно сильно и за заданное время успевают зафиксироваться другие транзакции. Однако этот параметр также увеличивает задержку максимум доcommit_delay
при каждом сохранении WAL. Эта задержка окажется бесполезной, если никакие другие транзакции не будут зафиксированы за это время, поэтому она добавляется, только если в момент запроса сохранения WAL активны как минимумcommit_siblings
других транзакций. Кроме того, эти задержки не добавляются при выключенномfsync
. Если это значение задаётся без единиц измерения, оно считается заданным в микросекундах. По умолчанию значениеcommit_delay
равно нулю (задержка отсутствует). Изменить этот параметр могут только суперпользователи и пользователи с соответствующим правомSET
.В PostgreSQL до версии 9.3, параметр
commit_delay
работал по-другому и не так эффективно: он задерживал только фиксирование транзакций, а не все операции сохранения WAL, и заданная пауза выдерживалась полностью, даже если WAL удавалось сохранить быстрее. Начиная с версии 9.3, заданное время ожидает только первый процесс, готовый произвести сохранение, тогда как все последующие процессы ждут только, когда он закончит эту операцию.commit_siblings
(integer
)Минимальное число одновременно открытых транзакций, при котором будет добавляться задержка
commit_delay
. Чем больше это значение, тем больше вероятность, что минимум одна транзакция окажется готовой к фиксированию за время задержки. По умолчанию это число равно пяти.
18.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
(при этом управление отложенной записью отключается) до 2 мегабайт (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
или в командной строке сервера.
18.5.3. Архивация
archive_mode
(enum
)Когда параметр
archive_mode
включён, полные сегменты WAL передаются в хранилище архива командой archive_command или функциями archive_library. Помимо значенияoff
(выключающего архивацию) есть ещё два:on
(вкл.) иalways
(всегда). В обычном состоянии эти два режима не различаются, но в режимеalways
архивация WAL активна и во время восстановления архива, и при использовании ведомого сервера. В этом режиме все файлы, восстановленные из архива или полученные при потоковой репликации, будут архивироваться (снова). За подробностями обратитесь к Подразделу 25.2.9.Параметры
archive_mode
иarchive_command
/archive_library
разделены, чтобы командуarchive_command
и библиотекуarchive_library
можно было изменять, не отключая режим архивации. Этот параметр можно задать только при запуске сервера. Режим архивации нельзя включить, когда установлен минимальный уровень WAL (wal_level
имеет значениеminimal
).archive_command
(string
)Команда локальной оболочки, которая будет выполняться для архивации завершённого сегмента WAL. Любое вхождение
%p
в этой строке заменяется путём архивируемого файла, а вхождение%f
заменяется только его именем. (Путь задаётся относительно рабочего каталога сервера, то есть каталога данных кластера.) Чтобы вставить в команду символ%
, его нужно записать как%%
. Важно, чтобы команда возвращала нулевой код, только если она завершается успешно. За дополнительной информацией обратитесь к Подразделу 24.3.1.Этот параметр можно задать только в
postgresql.conf
или в командной строке при запуске сервера. Данный параметр игнорируется, если режим архивации (archive_mode
) не был включён при запуске или параметрarchive_library
содержит непустую строку. Если значениеarchive_command
— пустая строка (по умолчанию), ноarchive_mode
включён (и при этом значениеarchive_library
— тоже пустая строка), архивация WAL временно отключается, но сервер продолжает накапливать файлы сегментов WAL в ожидании, что команда будет вскоре определена. Если в качествеarchive_command
задать команду, которая ничего не делает, но сообщает об успешном завершении, например/bin/true
(илиREM
в Windows), архивация по сути отключается, но при этом нарушается цепочка файлов WAL, необходимых для восстановления архива, поэтому такой вариант следует использовать только в особых случаях.archive_library
(string
)Библиотека, используемая для архивирования завершённых сегментов файла WAL. Если задана пустая строка (по умолчанию), применяется метод архивирования посредством оболочки и используется archive_command. В противном случае для архивирования используется указанная общая библиотека. При изменении этого параметра postmaster перезапускает процесс архивирования WAL. За дополнительными сведениями обратитесь к разделам Подраздел 24.3.1 и Глава 50.
Задать этот параметр можно только в
postgresql.conf
или в командной строке при запуске сервера.archive_timeout
(integer
)Команда archive_command или функции archive_library вызываются только для завершённых сегментов WAL. Поэтому, если ваш сервер записывает мало данных WAL (или это наблюдается в некоторые периоды времени), от завершения транзакции до надёжного сохранения её в архивном хранилище может пройти довольно много времени. Для ограничения времени существования неархивированных данных можно установить значение
archive_timeout
, чтобы сервер периодически переключался на новый файл сегмента WAL. Когда этот параметр больше нуля, сервер будет переключаться на новый файл сегмента, если с момента последнего переключения на новый файл прошло заданное время и наблюдалась какая-то активность базы данных, даже если это была просто контрольная точка. (Контрольные точки пропускаются, если в базе отсутствует активность). Заметьте, что архивируемые файлы, закрываемые досрочно из-за принудительного переключения, всё равно будут иметь тот же размер, что и полностью заполненные. Поэтому устанавливать дляarchive_timeout
очень маленькое значение неразумно — это ведёт к раздуванию архивного хранилища. Обычно дляarchive_timeout
имеет смысл задавать значение около минуты. Если вам нужно, чтобы данные копировались с главного сервера быстрее, вам следует подумать о переходе от архивации к потоковой репликации. Если это значение задаётся без единиц измерения, оно считается заданным в секундах. Этот параметр можно задать только вpostgresql.conf
или в командной строке при запуске сервера.
18.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 КБ.
18.5.5. Восстановление из архива
В этом разделе описываются параметры, действующие только в процессе восстановления. Они должны сбрасываться для любой последующей операции восстановления.
Под «восстановлением» здесь понимается и использование сервера в качестве ведомого, и выполнение целевого восстановления данных. Обычно ведомые серверы используется для обеспечения высокой степени доступности и/или масштабируемости чтения, тогда как целевое восстановление производится в случае потери данных.
Чтобы запустить сервер в режиме ведомого, создайте в каталоге данных файл standby.signal
. Сервер перейдёт к восстановлению и останется в этом состоянии и по достижении конца заархивированного WAL, чтобы осуществлять восстановление дальше. Для этого он подключится к передающему серверу, используя параметры в primary_conninfo
, или будет получать новые сегменты WAL с помощью команды restore_command
. Применительно к данному режиму представляют интерес параметры, описанные в этом разделе и в Подразделе 18.6.3. Параметры, описанные в Подраздел 18.5.6, также будут действовать, хотя для данного режима они вряд ли будут полезными.
Чтобы запустить сервер в режиме целевого восстановления, создайте в каталоге данных recovery.signal
. В случае одновременного существования файлов standby.signal
и recovery.signal
предпочтение отдаётся режиму ведомого. Режим целевого восстановления завершается после полного воспроизведения WAL из архива или при достижении целевой точки (recovery_target
). В данном режиме используются параметры, описанные в этом разделе и в Подразделе 18.5.6.
restore_command
(string
)Команда оболочки ОС, которая выполняется для извлечения архивного сегмента из набора файлов WAL. Этот параметр требуется для восстановления из архива, но необязателен для потоковой репликации. Любое вхождение
%f
в строке заменяется именем извлекаемого из архива файла, а%p
заменяется на путь назначения на сервере. (Путь указывается относительно текущего рабочего каталога, т. е. относительно каталога хранения данных кластера.) Любое вхождение%r
заменяется на имя файла, в котором содержится последняя действительная точка восстановления. Это самый ранний файл, который требуется хранить для возможности восстановления; зная его имя, размер архива можно уменьшить до минимально необходимого.%r
обычно используется при организации тёплого резерва (см. Раздел 25.2). Для того чтобы указать символ%
, продублируйте его (%%
).Обратите внимание, что команда должна возвращать ноль на выходе лишь в случае успешного выполнения. Команде будут поступать имена файлов, отсутствующих в архиве; в этом случае она должна возвращать ненулевой статус. Примеры:
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
В случае прерывания команды сигналом (отличным от SIGTERM, который используется для остановки сервера баз данных) или при возникновении ошибки оболочки (например, если команда не найдена), процесс восстановления будет остановлен и сервер не запустится.
archive_cleanup_command
(string
)Этот необязательный параметр указывает команду оболочки ОС, которая будет вызываться при каждой точке перезапуска. Назначение команды
archive_cleanup_command
— предоставить механизм очистки от старых архивных файлов WAL, которые более не нужны на ведомом сервере. Любое вхождение%r
заменяется на имя файла, содержащего последнюю действительную точку перезапуска. Это самый ранний файл, который необходимо хранить для возможности восстановления, а более старые файлы вполне можно удалить. Эта информация может быть использована для усечения архива с целью его минимизации при сохранении возможности последующего восстановления из заданной точки. Модуль pg_archivecleanup часто используется в качествеarchive_cleanup_command
в конфигурациях с одним ведомым сервером, например:archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
Стоит обратить внимание, что в конфигурациях с множеством ведомых серверов, использующих общий архивный каталог для восстановления, необходимо контролировать удаление файлов WAL, так как они могут ещё быть нужны некоторым серверам. Поэтому
archive_cleanup_command
обычно используется при организации тёплого резерва (см. Раздел 25.2). Чтобы указать символ%
в команде, продублируйте его (%%
).В случаях, когда команда возвращает ненулевой статус завершения, в журнал записывается предупреждающее сообщение. Если же команда прерывается сигналом или оболочка ОС выдаёт ошибку (например, команда не найдена), вызывается критическая ошибка.
Задать этот параметр можно только в
postgresql.conf
или в командной строке при запуске сервера.recovery_end_command
(string
)Этот параметр задаёт команду оболочки, которая будет выполнена единожды в конце процесса восстановления. Назначение параметра
recovery_end_command
— предоставить механизм для очистки после репликации или восстановления. Любое вхождение%r
заменяется именем файла, содержащим последнюю действительную точку восстановления, например, как в archive_cleanup_command.В случаях, когда команда возвращает ненулевой статус завершения, в журнал записывается предупреждающее сообщение, но сервер, несмотря на это, продолжает запускаться. Если же команда прерывается сигналом или оболочка ОС выдаёт ошибку (например, команда не найдена), кластер баз данных не запускается.
Задать этот параметр можно только в
postgresql.conf
или в командной строке при запуске сервера.
18.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
.Задавать этот параметр обычно требуется только в сложных ситуациях с повторами восстановления, когда необходимо вернуться к состоянию, которое само было достигнуто после восстановления на момент времени. Это обсуждается в Подразделе 24.3.5.
recovery_target_action
(enum
)Указывает, какое действие должен предпринять сервер после достижения цели восстановления. Вариант по умолчанию —
pause
, что означает приостановку восстановления. Второй вариант,promote
, означает, что процесс восстановления завершится, и сервер начнёт принимать подключения. Наконец, с вариантомshutdown
сервер остановится, как только цель восстановления будет достигнута.Вариант
pause
позволяет выполнить запросы к базе данных и убедиться в том, что достигнутая цель оказалась желаемой точкой восстановления. Для снятия с паузы нужно вызватьpg_wal_replay_resume()
(см. Таблицу 9.95), что в итоге приведёт к завершению восстановления. Если же окажется, что мы ещё не достигли желаемой точки восстановления, нужно остановить сервер, установить более позднюю цель и перезапустить сервер для продолжения восстановления.Вариант
shutdown
полезен для получения готового экземпляра сервера в желаемой точке. При этом данный экземпляр сможет воспроизводить дополнительные записи WAL (а при перезапуске ему придётся воспроизводить записи WAL после последней контрольной точки).Заметьте, что так как
recovery.signal
не переименовывается, когда вrecovery_target_action
выбран вариантshutdown
, при последующем запуске будет происходить немедленная остановка, пока вы не измените конфигурацию или не удалите файлrecovery.signal
вручную.Этот параметр не действует, если цель восстановления не установлена. Если не включён режим hot_standby, значение
pause
действует так же, как иshutdown
. Если цель восстановления достигается в процессе повышения,pause
действует какpromote
.В любом случае, если задана цель восстановления, но восстановление архива завершается до её завершения, сервер завершит работу с критической ошибкой.