18.5.1 Настройки
wal_level (enum)
wal_level определяет как много информации будет записываться в WAL. Значение по умолчанию - minimal, что означает, что записывается только информация, необходимая для восстановления при крахе системы или "немедленном" выключении. archive добавляет логи, необходимые для WAL архивирования, а hot_standby добавляет ещё и информацию, необходимую для выполнения запросов на чтения с резервного сервера. Этот параметр может быть задан только при старте сервера.
На уровне minimal WAL логирование - что-то вроде операции "в нагрузку", которую можно спокойно пропустить, что может сделать следующие операции быстрее (см раздел 14.4.7):
CREATE TABLE AS
CREATE INDEX
CLUSTER
COPY в таблицы, которые были созданы или усечены в этой же транзакции
Но такой WAL yt содержит достаточно информации, чтобы восстановить данные из резервной копии и WAL логов; для этого нужно использовать уровень archive или hot_standby, чтобы запустить архивирование WAL или потоковую репликацию.
На уровне hot_standby сохраняется та же информация, что и на уровне archive, плюс информация, необходимая для восстановления статуса текущей транзакции из WAL. Для того, чтобы позволить обрабатывать запросы на чтение с резервного сервера, wal_level должен быть установлен в hot_standby на мастере и hot_standby должен быть активирован на резервном сервере. Считается, что разница в производительности на уровнях archive и hot_standby незначительна, так что если Вы обнаружите что-то другое - обязательно об этом сообщите.
fsync (boolean)
Если этот параметр активирован, то PostgreSQL сервер будет стараться убедиться, что обновления физически записаны на диск, делая системный вызов fsync() или другим эквивалентным методом (см wal_sync_method). Это позволяет быть уверенным, что кластер БД может быть восстановлен к согласующемуся состоянию после краха ОС или выхода из строя оборудования.
Хотя отключение fsync чаще всего даёт выигрыш в производительности, это может привести к невосстановимому повреждению данных в случае перебоя с электричеством или краха ОС. Поэтому его рекомендуется отключать только если Вы легко можете восстановить свои данные из внешнего хранилища.
Пример ситуации, когда можно спокойно отключить fsync - при первоначальной загрузке данных в новый кластер БД из резервной копии, использовании кластера БД для обработки набора данных, после чего эта БД будет пересоздана, или клон БД только для чтения, который часто пересоздаётся и не используется для обеспечения бесперебойной работы. Только лишь высокое качество железа - не достаточная причина для отключения fsync.
Во многих ситуациях отключение synchronous_commit для некритических транзакций может привести к гораздо большему росту производительности, чем fsync, при этом без риска получить повреждённые данные.
fsync может быть задан либо в postgresql.conf, либо в командной строке. Если Вы его отключаете, подумайте и о том, чтобы отключить full_page_writes.
synchronous_commit (boolean)
Определяет, будет ли подтверждение транзакции ожидать записи WAL на диск перед возвратом "успеха" клиенту. Доступные значения - on, local и off. Значение по умолчанию, оно же самое безопасное - on. Если значение off, то может быть задержка между тем, что клиенту сообщено об успешном завершении транзакции и её реальной записью на диск (что, собственно, и гарантирует её сохранность). (Максимальная величина задержки равна 3*wal_writer_delay). В отличие от fsync, установка этого параметра в off не создаёт риска несогласованности БД: крах ОС или БД может привести к тому, что некоторые недавние якобы подтверждённые транзакции будут потеряны, но состояние БД будет такое же, как если бы эти транзакции были бы просто отменены. Так что отключение synchromous_commit может быть полезно в случаях, когда производительность важнее, чем гарантированность транзакций. Более подробно это обсуждается в разделе 29.3
Если заданы synchronous_standby_names, этот параметр так же контролирует, ожидает ли подтверждение транзакции записи WAL на диск и репликации на резервный сервер. Подтверждение не будет послано, пока не будет получено сообщение от синхронного резервного сервера, что транзакция была записана на диск. Если используется синхронная репликация, то как правило разумно либо дожидаться подтверждения как на локальный так и на удалённый диск, или же подтверждать транзакции асинхронно. Однако специальное значение local позволяет ждать записи только на локальный диск, но не подтверждения синхронной репликации.
Этот параметр может быть изменён в любое время; поведение каждой отдельной транзакции зависит от того, какое значение имела эта настройка на момент этой транзакции. Поэтому возможно и полезно подтверждать некоторые транзакции синхронно, а некоторые - асинхронно. Например, для того, чтобы подтвердить одну транзакцию асинхронно, тогда как остальные подтверждать синхронно, задайте SET LOCAL synchronous_commit TO OFF в этой транзакции.
wal_sync_method (enum)
Метод, используемый для принудительной записи обновлений WAL на диск. Если fsync выключен, то эта настройка игнорируется, так как принудительной записи WAL вообще не будет. Возможные значения:
- open_datasync (записывает WAL файлы при помощи open() c опцией 0_DSYNC)
- fdatasync (вызывает fdatadync() для каждого подтверждения)
- fsync (вызывает fsync() для каждого подтверждения)
- fsync_writethrough (вызывает fsync() для каждого подтверждения, принудительно записывая данные, минуя кеш записи)
- open_sync (записывает WAL файлы при помощи open() c опцией 0_SYNC)
Опции open_* так же при возможности используют 0_DIRECT. Не все варианты доступны на всех платформах. По умолчанию используется первый доступный на данной платформе метод из списка, но на Linux по умолчанию используется fdatasync. Значение по умолчанию не обязательно самое лучшее; возможно, что для большей надёжности или производительности Вам придётся изменить некоторые настройки. Это обсуждается в разделе 29.1. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
full_page_writes (boolean)
Когда этот параметр активирован, PostgreSQL сервер будет записывать всё содержимое каждой дисковой страницы WAL при первом изменении этой страницы после чекпойнта. Необходимость в этом возникает потому что во время записи страницы может произойти крах системы в результате чего на диске может получиться смесь старых и новых данных. Хранящиеся обычно в WAL изменения данных на уровне строки будут недостаточны для того, чтобы восстановить такую страницу в процессе восстановления данных. Сохранение же всей страницы гарантирует, что страница будет восстановлена целиком, но зато это требует записи большего объёма данных в WAL. (Так как восстановление WAL всегда начинается с чекпойнта, важно делать это при первом изменении каждой страницы после чекпойнта. Поэтому для снижения затрат на эту процедуру можно увеличить интервал чекпойнтов.)
Отключение этого параметра ускоряет обычные операции, но может привести к невосстановимому повреждению данных или к тихому повреждению данных при падении системы. Этот риск схожий с отключением fsync, хотя и меньший, и руководствоваться в вопросе его отключения стоит теми же принципами.
Отключение этого параметра не влияет на использование WAL архивирования для poin-in-time восстановления (PITR) (см раздел 24.3)
Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
wal_buffers (integer)
Количество разделяемой памяти, используемой для WAL данных, которые ещё не были записаны на диск. Значение по умолчанию -1, что означает использование 1/32 (около 3%) shared_buffers, но не меньше 64kB и не больше размера сегмента WAL, обычно 16MB. Это значение можно задать вручную, если автоматическое значение слишком большое или маленькое, но любое положительное значение меньше 32kB будет трактоваться как 32kB. Этот параметр можно задать только при старте сервера.
Содержимое WAL буферов записывается на диск при каждом подтверждении транзакции, так что очень большие значения скорее всего не дадут прироста производительности. Однако значение в несколько мегабайт может увеличить производительность записи на занятом сервере, где много клиентов подтверждают транзакции одновременно. Автоматически выбираемое значение в большинстве случаев даёт хороший результат.
Увеличение этого параметра может привести к тому, что PostgreSQL потребует больше разделяемой памяти System V, чем позволяет конфигурация вашей системы. В разделе 17.4.1 говорится как с этим справиться.
wal_writer_delay (integer)
Определяет паузу между циклами активности WAL writer'a. В каждом цикле writer записывает WAL на диск. После этого он засыпает на wal_writer_delay миллисекунд и снова начинает запись. Значение по умолчанию - 200 миллисекунд (200ms). Обратите внимание, что на многих системах шаг интервала должен быть 10 миллисекунд; задание значения которое не кратно 10 может расцениваться как большее значение, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
commit_delay (integer)
Когда данные транзакции записываются на диск, все другие транзакции, готовые к записи в это время тоже записываются на диск. commit_delay добавляет паузу, в микросекундах, перед тем, как транзакция будет записана на диск. Ненулевая задержка может привести к тому, что будет записано больше транзакций, если нагрузка на систему достаточна, чтобы дополнительные транзакции были готовы к записи. Поэтому пауза происходит только если хотя бы commit_siblings других транзакций активны на момент записи первой транзакции. Значением по умолчанию commit_delay является 0 (отсутствие задержки). Так как все отложенные данные будут записаны при каждой записи, вне зависимости от настройки, в редких случаях дополнительная пауза будет увеличивать производительность.
commit_siblings (integer)
Минимальное число одновременно открытых транзакций требуемых для выполнения паузы commit_delay. Больше значение повышает вероятность того, что как минимум ещё одна транзакция будет готова для записи в течении паузы. По умолчанию - 5 транзакций.
Максимальное число сегментов лога между автоматическими чекпойнтами WAL (каждый сегмент, обычно - 16 мегабайт). Значение по умолчанию - 3 сегмента. Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
chechpoint_timeout (integer)
Максимальный период времени между WAL чекпойнтами, в секундах. Значение по умолчанию - 5 минут (5min). Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
checkpoint_completion_target (floating point)
Определяет время для завершения чекпойнта как долю от времени между чекпойнтами. Значение по умолчанию - 0.5. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
checkpoint_warning (integer)
Записывает сообщение в лог сервера если создание чекпойнтов, вызванное заполнением файлов сегментов, происходит чаще, чем в это количество секунд (что подразумевает, что checkpoint_segments должно быть увеличено). Значение по умолчанию - 30 секунд (30s). 0 отключает предупреждения. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
Когда активирована эта настройка, завершённые сегменты WAL отправляются в архив, заданный archive_command. archive_mode и archive_command - разные параметры, так что каждый из них может быть изменён независимо. Этот параметр может быть задан только при запуске сервера. archive_mode не может быть активирован, если wal_level = minimal.
archive_command (string)
Команда оболочки, которая выполняется для архивирования файловых сегментов WAL. %p в строке будет заменён на путь к файлу архива, а %f - на имя файла архива. (Путь задаётся относительно рабочего каталога сервера, т.е. каталога данных). Для того, чтобы использовать знак % замените его на %%. Важно, чтобы команда возвращала 0 в качестве статуса завершения только в случае благополучного выполнения команды. Более подробно смотрите раздел 24.3.1
Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке. Он игнорируется, если archive_mode не был активирован при старте сервера. Если archive_command является пустой строкой (по умолчанию), а archive_mode активирован, WAL архивирование временно не работает, но сервер продолжает собирать WAL сегменты в ожидании получения команды для архивирования. Если указанная команда ничего не делает, но возвращает true (например, /bin/true или REM под Windows), то по факту это отменяет архивирование, но и прерывает цепочку WAL файлов, необходимых для восстановления архива, так что это можно использовать только в нестандартных ситуациях.
archive_timeout (integer)
archive_command вызывается только для завершённых сегментов WAL. Но, если ваш сервер производит небольшой WAL трафик (даже в некоторые периоды), то могут быть длительные паузы между завершением транзакции и её записью в архив. Для того, чтобы ограничить количество не заархивированных данных Вы можете задать archive_timeout, чтобы принудить сервер периодически переключаться на новый файл сегмента. Если этот параметр больше нуля, то сервер будет переключаться на новый файл сегмента каждые archive_timeout секунд и при этом была какая-то активность БД, включая единичный чекпойнт. (Увеличение checkpoint_time сократит лишние чекпойнты на бездействующей системе.) Обратите внимание, что заархивированный файл, закрытый из-за такого переключения, будет иметь такую же длину, что и полностью заполненный. Поэтому неразумно использовать слишком короткий archive_timeout - это быстро заполнит ваше архивное хранилище. archive_timeout со значением минута или что-то вроде того обычно наиболее разумный. Вы должны рассмотреть использование потоковой репликации вместо архивирования, если Вы хотите, чтобы ваши данные копировались с мастера на резервный сервер быстрее. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
Когда этот параметр активирован, PostgreSQL сервер будет записывать всё содержимое каждой дисковой страницы WAL при первом изменении этой страницы после чекпойнта. Необходимость в этом возникает потому что во время записи страницы может произойти крах системы в результате чего на диске может получиться смесь старых и новых данных. Хранящиеся обычно в WAL изменения данных на уровне строки будут недостаточны для того, чтобы восстановить такую страницу в процессе восстановления данных. Сохранение же всей страницы гарантирует, что страница будет восстановлена целиком, но зато это требует записи большего объёма данных в WAL. (Так как восстановление WAL всегда начинается с чекпойнта, важно делать это при первом изменении каждой страницы после чекпойнта. Поэтому для снижения затрат на эту процедуру можно увеличить интервал чекпойнтов.)
Отключение этого параметра ускоряет обычные операции, но может привести к невосстановимому повреждению данных или к тихому повреждению данных при падении системы. Этот риск схожий с отключением fsync, хотя и меньший, и руководствоваться в вопросе его отключения стоит теми же принципами.
Отключение этого параметра не влияет на использование WAL архивирования для poin-in-time восстановления (PITR) (см раздел 24.3)
Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
wal_buffers (integer)
Количество разделяемой памяти, используемой для WAL данных, которые ещё не были записаны на диск. Значение по умолчанию -1, что означает использование 1/32 (около 3%) shared_buffers, но не меньше 64kB и не больше размера сегмента WAL, обычно 16MB. Это значение можно задать вручную, если автоматическое значение слишком большое или маленькое, но любое положительное значение меньше 32kB будет трактоваться как 32kB. Этот параметр можно задать только при старте сервера.
Содержимое WAL буферов записывается на диск при каждом подтверждении транзакции, так что очень большие значения скорее всего не дадут прироста производительности. Однако значение в несколько мегабайт может увеличить производительность записи на занятом сервере, где много клиентов подтверждают транзакции одновременно. Автоматически выбираемое значение в большинстве случаев даёт хороший результат.
Увеличение этого параметра может привести к тому, что PostgreSQL потребует больше разделяемой памяти System V, чем позволяет конфигурация вашей системы. В разделе 17.4.1 говорится как с этим справиться.
wal_writer_delay (integer)
Определяет паузу между циклами активности WAL writer'a. В каждом цикле writer записывает WAL на диск. После этого он засыпает на wal_writer_delay миллисекунд и снова начинает запись. Значение по умолчанию - 200 миллисекунд (200ms). Обратите внимание, что на многих системах шаг интервала должен быть 10 миллисекунд; задание значения которое не кратно 10 может расцениваться как большее значение, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
commit_delay (integer)
Когда данные транзакции записываются на диск, все другие транзакции, готовые к записи в это время тоже записываются на диск. commit_delay добавляет паузу, в микросекундах, перед тем, как транзакция будет записана на диск. Ненулевая задержка может привести к тому, что будет записано больше транзакций, если нагрузка на систему достаточна, чтобы дополнительные транзакции были готовы к записи. Поэтому пауза происходит только если хотя бы commit_siblings других транзакций активны на момент записи первой транзакции. Значением по умолчанию commit_delay является 0 (отсутствие задержки). Так как все отложенные данные будут записаны при каждой записи, вне зависимости от настройки, в редких случаях дополнительная пауза будет увеличивать производительность.
commit_siblings (integer)
Минимальное число одновременно открытых транзакций требуемых для выполнения паузы commit_delay. Больше значение повышает вероятность того, что как минимум ещё одна транзакция будет готова для записи в течении паузы. По умолчанию - 5 транзакций.
18.5.2 Чекпойнты
checkpoint_segments (integer)Максимальное число сегментов лога между автоматическими чекпойнтами WAL (каждый сегмент, обычно - 16 мегабайт). Значение по умолчанию - 3 сегмента. Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
chechpoint_timeout (integer)
Максимальный период времени между WAL чекпойнтами, в секундах. Значение по умолчанию - 5 минут (5min). Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
checkpoint_completion_target (floating point)
Определяет время для завершения чекпойнта как долю от времени между чекпойнтами. Значение по умолчанию - 0.5. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
checkpoint_warning (integer)
Записывает сообщение в лог сервера если создание чекпойнтов, вызванное заполнением файлов сегментов, происходит чаще, чем в это количество секунд (что подразумевает, что checkpoint_segments должно быть увеличено). Значение по умолчанию - 30 секунд (30s). 0 отключает предупреждения. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
18.5.3 Архивирование
archieve_mode (boolean)Когда активирована эта настройка, завершённые сегменты WAL отправляются в архив, заданный archive_command. archive_mode и archive_command - разные параметры, так что каждый из них может быть изменён независимо. Этот параметр может быть задан только при запуске сервера. archive_mode не может быть активирован, если wal_level = minimal.
archive_command (string)
Команда оболочки, которая выполняется для архивирования файловых сегментов WAL. %p в строке будет заменён на путь к файлу архива, а %f - на имя файла архива. (Путь задаётся относительно рабочего каталога сервера, т.е. каталога данных). Для того, чтобы использовать знак % замените его на %%. Важно, чтобы команда возвращала 0 в качестве статуса завершения только в случае благополучного выполнения команды. Более подробно смотрите раздел 24.3.1
Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке. Он игнорируется, если archive_mode не был активирован при старте сервера. Если archive_command является пустой строкой (по умолчанию), а archive_mode активирован, WAL архивирование временно не работает, но сервер продолжает собирать WAL сегменты в ожидании получения команды для архивирования. Если указанная команда ничего не делает, но возвращает true (например, /bin/true или REM под Windows), то по факту это отменяет архивирование, но и прерывает цепочку WAL файлов, необходимых для восстановления архива, так что это можно использовать только в нестандартных ситуациях.
archive_timeout (integer)
archive_command вызывается только для завершённых сегментов WAL. Но, если ваш сервер производит небольшой WAL трафик (даже в некоторые периоды), то могут быть длительные паузы между завершением транзакции и её записью в архив. Для того, чтобы ограничить количество не заархивированных данных Вы можете задать archive_timeout, чтобы принудить сервер периодически переключаться на новый файл сегмента. Если этот параметр больше нуля, то сервер будет переключаться на новый файл сегмента каждые archive_timeout секунд и при этом была какая-то активность БД, включая единичный чекпойнт. (Увеличение checkpoint_time сократит лишние чекпойнты на бездействующей системе.) Обратите внимание, что заархивированный файл, закрытый из-за такого переключения, будет иметь такую же длину, что и полностью заполненный. Поэтому неразумно использовать слишком короткий archive_timeout - это быстро заполнит ваше архивное хранилище. archive_timeout со значением минута или что-то вроде того обычно наиболее разумный. Вы должны рассмотреть использование потоковой репликации вместо архивирования, если Вы хотите, чтобы ваши данные копировались с мастера на резервный сервер быстрее. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.
Комментариев нет:
Отправить комментарий