18.5. Журнал записи перед обработкой#
18.5. Журнал записи перед обработкой #
Для получения дополнительной информации по настройке этих параметров см. Раздел 28.5.
18.5.1. Настройки #
wal_level(enum) #wal_levelопределяет, сколько информации записывается в WAL. Значение по умолчанию -replica, которое записывает достаточно данных для поддержки архивирования и репликации WAL, включая выполнение запросов только для чтения на резервном сервере.minimalудаляет все ведение журнала, кроме информации, необходимой для восстановления после сбоя или немедленного выключения. Наконец,logicalдобавляет информацию, необходимую для поддержки логического декодирования. Каждый уровень включает информацию, зарегистрированную на всех более низких уровнях. Этот параметр может быть установлен только при запуске сервера.Уровень
minimalгенерирует наименьший объем WAL. Он не регистрирует информацию о строках для постоянных отношений в транзакциях, которые создают или перезаписывают их. Это может значительно ускорить операции (см. Раздел 14.4.7). Операции, которые инициируют эту оптимизацию, включают:ALTER ... SET TABLESPACECLUSTERCREATE TABLEREFRESH MATERIALIZED VIEW(без опцииCONCURRENTLY)REINDEXTRUNCATEОднако, минимальный 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 BE будет пытаться убедиться, что обновления физически записываются на диск, выполняя системные вызовы
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, andoff.Если параметр
synchronous_standby_namesпустой, единственные значимые настройки -onиoff;remote_apply,remote_writeиlocalпредоставляют тот же уровень локальной синхронизации, что иon. Локальное поведение всех режимов, отличных отoff, заключается в ожидании локальной записи WAL на диск. В режимеoffожидания нет, поэтому может быть задержка между моментом сообщения об успехе клиенту и моментом, когда транзакция будет гарантированно безопасна от сбоя сервера. (Максимальная задержка составляет три раза wal_writer_delay). В отличие от fsync, установка этого параметра вoffне создает никакого риска несогласованности базы данных: сбой операционной системы или базы данных может привести к потере некоторых недавно предположительно зафиксированных транзакций, но состояние базы данных будет таким же, как если бы эти транзакции были чисто отменены. Таким образом, отключение параметраsynchronous_commitможет быть полезной альтернативой, когда надежность важнее точной гарантии надежности транзакции. Для более подробного обсуждения см. Раздел 28.4.Если synchronous_standby_names не пусто, то
synchronous_commitтакже контролирует, будут ли транзакции ожидать обработки своих записей WAL на сервере(ах) резервного копирования.Когда установлено значение
remote_apply, коммиты будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и применили ее, чтобы она стала видимой для запросов на репликах и также записана на надежное хранилище на репликах. Это приведет к значительно большим задержкам коммита по сравнению с предыдущими настройками, так как она ожидает воспроизведения WAL. Когда установлено значениеon, коммита будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и записали ее на надежное хранилище. Это гарантирует, что транзакция не будет потеряна, если как основной сервер, так и все синхронные реплики подвергнутся повреждению хранилища базы данных. Когда установлено значениеremote_write, коммита будут ожидать, пока ответы от текущих синхронных реплик не указывают, что они получили запись коммита транзакции и записали ее в свои файловые системы. Эта настройка гарантирует сохранение данных, если резервная копия Tantor BE аварийно завершится, но не гарантирует сохранение данных, если резервная копия аварийно завершится на уровне операционной системы, поскольку данные не обязательно достигли надежного хранилища на резервной копии. Настройкаlocalзаставляет коммиты ожидать локальной записи на диск, но не ожидать репликации. Это обычно не желательно при использовании синхронной репликации, но предоставляется для полноты.Этот параметр можно изменить в любое время; поведение для каждой отдельной транзакции определяется настройкой, действующей в момент коммита. Поэтому возможно и полезно иметь некоторые транзакции, которые коммитятся синхронно, а другие - асинхронно. Например, чтобы сделать так,чтобы одна многооператорная транзакция коммитилась асинхронно, когда значение по умолчанию противоположное, выполните команду
SET LOCAL synchronous_commit TO OFFвнутри транзакции.Таблица 18.1 подводит итоги возможностей настроек
synchronous_commit.Таблица 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)
Не все из этих вариантов доступны на всех платформах. По умолчанию используется первый метод из приведенного выше списка, который поддерживается платформой, за исключением того, что
fdatasyncявляется значением по умолчанию на Linux и FreeBSD. Значение по умолчанию не обязательно является идеальным; возможно, потребуется изменить этот параметр или другие аспекты конфигурации системы, чтобы создать конфигурацию, устойчивую к сбоям, или достичь оптимальной производительности. Эти аспекты обсуждаются в Раздел 28.1. Этот параметр можно установить только в файлеpostgresql.confили в командной строке сервера.full_page_writes(boolean) #Когда этот параметр включен, сервер Tantor BE записывает полное содержимое каждой дисковой страницы в WAL во время первой модификации этой страницы после контрольной точки. Это необходимо, потому что запись страницы, которая выполняется во время сбоя операционной системы, может быть выполнена только частично, что приводит к дисковой странице, содержащей смесь старых и новых данных. Информация о изменениях на уровне строк, обычно хранящаяся в WAL, недостаточна для полного восстановления такой страницы во время восстановления после сбоя. Хранение полного изображения страницы гарантирует, что страница может быть правильно восстановлена, но за счет увеличения объема данных, которые должны быть записаны в WAL. (Поскольку воспроизведение WAL всегда начинается с контрольной точки, достаточно сделать это во время первого изменения каждой страницы после контрольной точки. Поэтому один из способов снизить стоимость записи полных страниц - увеличить параметры интервала контрольной точки).
Отключение этого параметра ускоряет нормальную работу, но может привести к непоправимой коррупции данных или скрытой коррупции данных после сбоя системы. Риски аналогичны отключению параметра
fsync, хотя и меньше, и его следует отключать только в тех же обстоятельствах, что и рекомендуется для этого параметра.Отключение этого параметра не влияет на использование архивирования WAL для восстановления до точки во времени (PITR) (см. Раздел 24.3).
Этот параметр может быть установлен только в файле
postgresql.confили в командной строке сервера. По умолчанию он установлен в значениеon.wal_log_hints(boolean) #Когда этот параметр установлен в
on, сервер Tantor BE записывает полное содержимое каждой дисковой страницы в WAL во время первой модификации этой страницы после контрольной точки, даже для некритических модификаций так называемых подсказочных битов.Если контрольные суммы данных включены, обновления подсказок всегда записываются в журнал WAL, и это настройка игнорируется. Вы можете использовать эту настройку, чтобы проверить, сколько дополнительных записей в журнале WAL произойдет, если контрольные суммы данных в вашей базе данных будут включены.
Этот параметр может быть установлен только при запуске сервера. Значение по умолчанию -
off.wal_compression(enum) #Этот параметр позволяет сжимать WAL с использованием указанного метода сжатия. При включении сервер Tantor BE сжимает полные изображения страниц, записанные в WAL, когда full_page_writes включен или во время базовой резервной копии. Сжатое изображение страницы будет разархивировано во время воспроизведения WAL. Поддерживаемые методы -
pglz,lz4(если Tantor BE был скомпилирован с--with-lz4) иzstd(если Tantor BE был скомпилирован с--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 BE до 9.3 параметр
commit_delayвел себя иначе и был гораздо менее эффективным: он влиял только на коммит транзакций, а не на все записи WAL, и ждал весь заданный интервал, даже если запись WAL была завершена раньше. Начиная с PostgreSQL 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, что отключает принудительную запись, до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или в командной строке сервера.
18.5.3. Архивирование #
archive_mode(enum) #Когда
archive_modeвключен, завершенные сегменты WAL отправляются в архивное хранилище путем установки archive_command или archive_library. Кроме значенияoff, чтобы отключить, существуют два режима:onиalways. Во время нормальной работы между двумя режимами нет разницы, но когда установлен режимalways, архиватор WAL также включен во время восстановления из архива или в режиме ожидания. В режимеalwaysвсе файлы, восстановленные из архива или переданные с помощью потоковой репликации, будут снова архивированы. См. Раздел 25.2.9 для получения дополнительной информации.archive_mode- отдельная настройка отarchive_commandиarchive_library, чтобыarchive_commandиarchive_libraryможно было изменить без выхода из режима архивирования. Этот параметр может быть установлен только при запуске сервера.archive_modeне может быть включен, когдаwal_levelустановлен вminimal.archive_command(string) #Команда локальной оболочки для выполнения архивации завершенного сегмента WAL файла. Любой
%pв строке заменяется на путь к файлу для архивации, а любой%fзаменяется только на имя файла. (Путь относительно рабочего каталога сервера, т.е. каталога данных кластера). Используйте%%для вставки фактического символа%в команду. Важно, чтобы команда возвращала только нулевой код завершения в случае успеха. Дополнительную информацию см. в разделе Раздел 24.3.1.Этот параметр можно установить только в файле
postgresql.confили в командной строке сервера. Он используется только в том случае, еслиarchive_modeбыл включен при запуске сервера иarchive_libraryустановлен в пустую строку. Если обаarchive_commandиarchive_libraryустановлены, будет вызвана ошибка. Еслиarchive_commandявляется пустой строкой (по умолчанию), в то время какarchive_modeвключен (иarchive_libraryустановлен в пустую строку), архивирование WAL временно отключено, но сервер продолжает накапливать файлы сегментов WAL в ожидании, что команда будет вскоре предоставлена. Установкаarchive_commandв команду, которая ничего не делает, но возвращает true, например,/bin/true(REMв Windows), фактически отключает архивирование, но также разрывает цепочку файлов WAL, необходимых для восстановления из архива, поэтому это следует использовать только в исключительных случаях.archive_library(string) #Библиотека для использования при архивировании завершенных сегментов WAL. Если установлено пустое значение (по умолчанию), архивирование через оболочку включено, и archive_command используется. Если оба
archive_commandиarchive_libraryустановлены, будет вызвана ошибка. В противном случае, указанная общая библиотека используется для архивирования. Процесс архивирования WAL перезапускается postmaster при изменении этого параметра. Для получения дополнительной информации см. Раздел 24.3.1 и Глава 48.Этот параметр может быть установлен только в файле
postgresql.confили в командной строке сервера.archive_timeout(integer) #xref linkend="guc-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) #Команда локальной оболочки для выполнения, чтобы получить архивный сегмент серии файлов журнала предзаписи. Этот параметр требуется для восстановления из архива, но необязателен для потоковой репликации. Любой
%fв строке заменяется именем файла, который нужно получить из архива, и любой%pзаменяется именем пути назначения копии на сервере. (Путь относительно текущего рабочего каталога, то есть каталога данных кластера). Любой%rзаменяется именем файла, содержащего последнюю допустимую точку перезапуска. Это самый ранний файл, который должен быть сохранен для возможности перезапуска восстановления, поэтому эта информация может быть использована для обрезки архива только до минимально необходимого для поддержки перезапуска с текущего восстановления.%rобычно используется только в конфигурациях теплого резервирования (см. Раздел 25.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обычно используется в конфигурации теплого резервного копирования (см. Раздел 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является значением по умолчанию.Чтобы указать идентификатор временной шкалы в шестнадцатеричном формате (например, если он извлечен из имени файла WAL или файла истории), добавьте к нему префикс
0x. Например, если имя файла WAL00000011000000A10000004F, то идентификатор временной шкалы0x11(или 17 в десятичной системе).Обычно вам нужно устанавливать этот параметр только в сложных ситуациях повторного восстановления, когда необходимо вернуться к состоянию, которое было достигнуто после восстановления до определенного момента. См. Раздел 24.3.5 для обсуждения.
recovery_target_action(enum) #Определяет, какое действие сервер должен выполнить после достижения цели восстановления. По умолчанию используется значение
pause, что означает приостановку восстановления. Значениеpromoteозначает завершение процесса восстановления и запуск сервера для принятия подключений. Наконец, значениеshutdownостановит сервер после достижения цели восстановления.Цель использования настройки
pauseсостоит в том, чтобы позволить выполнение запросов к базе данных для проверки, является ли этот целевой момент восстановления наиболее желательным. Приостановленное состояние можно возобновить с помощью функцииpg_wal_replay_resume()(см. Таблица 9.93), что приведет к завершению процесса восстановления. Если этот целевой момент восстановления не является желаемой точкой остановки, то следует выключить сервер, изменить настройки целевого момента восстановления на более поздний и перезапустить для продолжения восстановления.Настройка
shutdownполезна, чтобы иметь экземпляр готовым к точке воспроизведения, которую нужно. Экземпляр все еще сможет воспроизводить больше записей WAL (и, фактически, должен будет воспроизвести записи WAL с момента последней контрольной точки при следующем запуске).Обратите внимание, что поскольку файл
recovery.signalне будет удален, когдаrecovery_target_actionустановлено вshutdown, любое последующее запуск будет завершаться немедленным выключением, если конфигурация не изменена или файлrecovery.signalне будет удален вручную.Эта настройка не имеет эффекта, если не установлена цель восстановления. Если hot_standby не включено, установка
pauseбудет действовать так же, какshutdown. Если цель восстановления достигнута во время продвижения, установкаpauseбудет действовать так же, какpromote.В любом случае, если задана цель восстановления, но восстановление из архива завершается до достижения цели, сервер завершит работу скритической ошибкой.