tag:blogger.com,1999:blog-34954587623433211672024-03-12T18:23:30.391-07:00PostgreSQLIshayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.comBlogger26125tag:blogger.com,1999:blog-3495458762343321167.post-36760566004402910422013-01-24T22:11:00.002-08:002013-01-24T22:11:23.162-08:0025.3. Обеспечение отказоустойчивости<br />
<div class="SECT1" style="margin: 0px; padding: 0px;">
<div style="text-align: justify;">
Если мастер падает, то резервный сервер должен начать процедуру failover (обеспечения отказоустойчивости).</div>
<div style="text-align: justify;">
Если падает резервный сервер, то никаких действий предпринимать не надо. Если резервный сервер может быть перезапущен, даже спустя некоторое время, то процесс восстановления может быть немедленно возобновлён. Если же перезапустить резервный сервер не возможно, то тогда нужно использовать другой резервный сервер.</div>
<div style="text-align: justify;">
Если мастер падает и резервный сервер становится новым мастером, а затем перезапускается старый мастер, то у Вас должен быть механизм, который бы сообщил старому мастеру, что он уже не является основным сервером. Чаще всего это называется <a href="http://en.wikipedia.org/wiki/STONITH" target="_blank">STONITH</a> (Shoot The Other Node In The Head - <i>Выстрел Другому Узлу в Голову - ВДрУГ ;)</i> ), что необходимо для того, чтобы избежать ситуаций, где два узла действовали бы как мастера, что привело бы к проблемам и потере информации.</div>
<div style="text-align: justify;">
Многие системы обеспечения отказоустойчивости используют только две системы - мастер и резервный сервер, которые соединены каким-то механизмом, который контролирует наличие соединения между обоими системами и жизнеспособность мастера. Кроме того, можно использовать третью систему ("мудрый" сервер), который позволит избежать некоторых случаев отказа, но его использование оправдано лишь при наличии достаточного внимания к настройке и скрупулёзном тестировании.</div>
<div style="text-align: justify;">
PostgreSQL не предоставляет системы ПО, которая бы определяла падение мастера и сообщала об этом резервному серверу. Есть множество систем, которые для этого можно использовать и которых хорошо интегрированы со средствами ОС, необходимыми для обеспечения отказоустойчивости, такими как миграция IP.</div>
<div style="text-align: justify;">
После того, как происходит переход на резервный сервер, у Вас есть только один действующий сервер. Это называется "вырожденное" состояние, так как бывший резервный сервер теперь мастер, а бывший мастер выключен и может оставаться в таком состоянии. Чтобы вернуться к нормальной системе, Вы должны пересоздать резервный сервер, либо на бывшем мастере после его ремонта, либо на третей, возможно новой, системе. После этого Вы можете захотеть поменять роли серверов. Некоторые используют третий сервер в качестве резерва для нового мастера, пока не сделают новый резервный сервер, однако это усложняет настройку системы и её обслуживание.</div>
<div style="text-align: justify;">
Таким образом переключение с мастера на резервный сервер может быть быстрым, но требует некоторой подготовки отказоустойчивого кластера. Периодическое переключение с мастера на резервный сервер полезно, так как предоставляет время для обслуживания каждого из серверов. Кроме того, это позволяет проверить механизм обеспечения отказоустойчивости и убедиться, что он и вправду будет работать, когда это понадобится. Очень желательно, чтобы все действия администратора на этот случай были так же письменно зафиксированы.</div>
<div style="text-align: justify;">
Для того, чтобы активировать резервный сервер в случае аварии при использовании пересылки логов, используйте pg_ctl promote или создайте триггер-файл с именем и по адресу, указанным в параметре trigger_file файла recovery.conf. Если Вы собираетесь использовать команду pg_ctl promote, то параметр trigger_file не нужен. Он так же не нужен, если Вы будете использовать резервные сервера только для снятия нагрузки с мастера за счёт выполнения на них только запросов на чтение, а не для обеспечения отказоустойчивости.</div>
<div style="font-family: verdana, sans-serif; font-size: 12px;">
<br /></div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com1tag:blogger.com,1999:blog-3495458762343321167.post-34442125495830035442013-01-22T04:39:00.001-08:002013-01-22T04:39:16.764-08:00pg_basebackup<h2>
Название</h2>
<div>
pg_basebackup -- делает резервную копию кластера PostgreSQL</div>
<h2>
Краткое описание</h2>
<div>
pg_basebackup [<i>option...</i>]</div>
<h2>
Описание</h2>
<div style="text-align: justify;">
pg_basebackup используется для создания резервной копии БД работающего кластера PostgreSQL. Этот процесс не влияет на других клиентов БД и может использоваться и для point-in-time восстановления (см <a href="http://postgresql.ru.net/manual/continuous-archiving.html" target="_blank">раздел 24.3</a>), и как начальная точка для передачи логов или потоковой репликации (см <a href="http://postgresql-lab.blogspot.ru/2012/12/25.html" target="_blank">раздел 24.2</a>).</div>
<div style="text-align: justify;">
pg_basebackup делает двоичную копию файлов кластера БД, убедившись, что система автоматически входит и выходит из режима создания резервной копии. Копия всегда создаётся всего кластера, не возможно сделать копию отдельных БД или объектов БД. Для создания резервных копий отдельных БД используйте инструменты вроде <a href="http://postgresql.ru.net/manual/app-pgdump.html" target="_blank">pg_dump</a>.</div>
<div style="text-align: justify;">
Резервная копия делается через обычное подключение PostgreSQL и использует протокол репликации. Поэтому соединение должно быть установлено пользователем, имеющим привилегию REPLICATION (см <a href="http://postgresql.ru.net/manual/role-attributes.html" target="_blank">раздел 20.2</a>) и у него должны быть соответствующие разрешения в pg_hba.conf. Сервер так же должен иметь достаточно высокое значение <a href="http://postgresql-lab.blogspot.ru/2013/01/186.html" target="_blank">max_wal_senders</a>, чтобы разрешить хотя бы одно подключение.</div>
<div style="text-align: justify;">
Одновременно может быть запущенно несколько экземпляров pg_basebackup, но с точки зрения производительности лучше запустить один pg_basebackup и потом просто сделать копии результата.<a name='more'></a></div>
<h2>
Опции</h2>
<div style="text-align: justify;">
Следующие опции командной строки определяют расположение и формат вывода:</div>
<div style="text-align: justify;">
-D <i>directory</i></div>
<div style="text-align: justify;">
--pgdata=<i>directory</i></div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Каталог, где должна находиться резервная копия.</div>
<div style="text-align: justify;">
Если копия создаётся в режиме tar и в качестве каталога указан - (дефис), tar файл будет записан в stdout.</div>
<div style="text-align: justify;">
Этот параметр обязателен.</div>
</blockquote>
<div style="text-align: justify;">
-F <i>format</i></div>
<div style="text-align: justify;">
--format=<i>format</i></div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Определяет формат вывода. В качестве значения можно использовать:</div>
<b><div style="text-align: justify;">
<b>p</b></div>
</b><b><div style="text-align: justify;">
<b>plain</b></div>
</b><blockquote class="tr_bq">
<div style="text-align: justify;">
Пишет результат в качестве простого файла с тем же расположением, что и в текущем каталоге данных и пространстве таблиц. Когда у кластера нет дополнительных пространств таблиц, вся БД размещается в указанной директории. Если кластер содержит дополнительные пространства таблиц, основной каталог данных будет расположен в указанной директории а все остальные пространства таблиц будут расположены по тому же абсолютному пути, по которому они расположены на сервере.</div>
<div style="text-align: justify;">
Это формат по умолчанию.</div>
</blockquote>
<b><div style="text-align: justify;">
<b>t</b></div>
</b><b><div style="text-align: justify;">
<b>tar</b></div>
</b><blockquote class="tr_bq">
<div style="text-align: justify;">
Записывает вывод в качестве tar файла в указанной директории. Основной каталог данных будет записан в файл namedbase.tar, а все остальные пространства таблиц будут названы в соответствии в OID пространства таблицы.</div>
<span style="text-align: start;"><div style="text-align: justify;">
Если в качестве каталога указан - (дефис), tar файл будет записан в stdout, что удобно для использования каналов, например, для gzip. Это возможно только если в кластере нет дополнительных пространств имён.</div>
</span></blockquote>
</blockquote>
<div style="text-align: justify;">
<i>-</i>x</div>
<div style="text-align: justify;">
--xlog</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Добавляет лог файлы требуемых транзакций (WAL файлы) в резервную копию. Эта опция добавит все логи транзакций, созданные во время резервной копии. Если эта опция передана, то можно запустить postmaster сразу в извлечённой резервной копии, без необходимости в дополнительных архивах логов; таким образом создаётся полностью самодостаточная резервная копия.</div>
<b><div style="text-align: justify;">
<b>Примечание:</b> файлы логов транзакций добавляются в конце создания резервной копии. Поэтому необходимо, чтобы параметр <a href="http://postgresql-lab.blogspot.ru/2013/01/186.html" target="_blank">wal_keep_segments</a> имел достаточно большое значение, чтобы эти логи не были удалены до завершения резервного копирования. Если произойдёт ротация лога в процессе его перемещения, то резервная копия будет бесполезна.</div>
</b></blockquote>
<div style="text-align: justify;">
-z</div>
<div style="text-align: justify;">
--gzip</div>
<blockquote class="tr_bq" style="text-align: justify;">
Добавляет gzip сжатие к итоговому tar файлу с уровнем сжатия по умолчанию. Возможно только для tar.</blockquote>
<div style="text-align: justify;">
-Z <i>level</i></div>
<div style="text-align: justify;">
<i>--</i>compress=<i>level</i></div>
<blockquote class="tr_bq" style="text-align: justify;">
<span style="text-align: start;">Добавляет gzip сжатие к итоговому tar файлу и задаёт уровень сжатия (1-9, где 9 - самое лучшее сжатие). Возможно только для tar.</span></blockquote>
<div style="text-align: justify;">
Следующие опции командной строки определяют создание резервной копии и запуск программы:</div>
<div style="text-align: justify;">
-с <i>fast | spread</i></div>
<div style="text-align: justify;">
--checkpoint=<i>fast|spread</i></div>
<blockquote class="tr_bq" style="text-align: justify;">
Устанавливает режим чекпойта - fast или spread (по умолчанию).</blockquote>
<div style="text-align: justify;">
-l <i>label</i></div>
<div style="text-align: justify;">
--label=<i>label</i></div>
<blockquote class="tr_bq" style="text-align: justify;">
Задаёт метку для резервной копии. Если не определена, то используется значение по умолчанию "pg_basebackup base backup"</blockquote>
<div style="text-align: justify;">
-P</div>
<div style="text-align: justify;">
--progress</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Включает получения сообщений о приблизительном прогрессе во время создания резервной копии. Так как БД может изменяться в процессе копирования, значения о прогрессе лишь приблизительные и могут не соответствовать реальному состоянию дел на 100%. В частности, когда WAL логи включены в резервную копию, общее количество данных не может быть оценено заранее, и, в этом случае, итоговый размер будет увеличиваться, как только он перешагнёт размер без WAL.</div>
<div style="text-align: justify;">
Если эта опция передана, резервное копирование начётся с вычисления размера БД, после чего будет сообщён реально обработаный объём данных. Из-за этого создание резервной копии может длиться дольше, особенно в самом начале.</div>
</blockquote>
<div style="text-align: justify;">
-v</div>
<div style="text-align: justify;">
--verbose</div>
<blockquote class="tr_bq" style="text-align: justify;">
Активирует "подробный" режим. Будут отображены дополнительные шаги при запуске и завершении, показаны имена обрабатываемых на данный момент файлов при используемой опции -p.</blockquote>
<div style="text-align: justify;">
Следующие опции командной строки определяют параметры подключения к БД:</div>
<div style="text-align: justify;">
-h <i>host</i></div>
<div style="text-align: justify;">
<i>--</i>host=<i>host</i></div>
<blockquote class="tr_bq" style="text-align: justify;">
Определяет имя машины, на которой запущен сервер. Если значение начинается со слеша, то оно используется как каталог для Unix-domain socket. Значение по умолчанию берётся из переменной окружения PGHOST, если она задана, в противном случае используется Unix-domain socket.</blockquote>
<div style="text-align: justify;">
<i>-</i>p <i>port</i></div>
<div style="text-align: justify;">
--port=<i>port</i></div>
<blockquote class="tr_bq" style="text-align: justify;">
Определяет TCP порт или Unix-domain socket, на котором сервер ожидает подключения. Значения по умолчанию - переменная окружения PGRORT или значение, заданное при компиляции.</blockquote>
<div style="text-align: justify;">
<i>-</i>U <i>username</i></div>
<div style="text-align: justify;">
--username=<i>username</i></div>
<blockquote class="tr_bq">
Имя пользователя для подключения</blockquote>
<div style="text-align: justify;">
-w</div>
<div style="text-align: justify;">
--no-password</div>
<blockquote class="tr_bq" style="text-align: justify;">
Ни в коем случае не запрашивает пароль. Если сервер требует пароля и нет файла паролей, например, .pgpass, то подключиться не удастся. Эта опция может быть полезна в скриптах, когда нет пользователя, который мог бы ввести пароль.</blockquote>
<div style="text-align: justify;">
-W</div>
<div style="text-align: justify;">
--password</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Заставляет pg_basebackup запросить пароль перед подключением к БД.</div>
<div style="text-align: justify;">
Эта опция никогда не является жизненно важной, так как pg_basebackup сам спросит пароль, если его требует сервер. Однако, на выяснение того, что серверу нужен пароль, pg_basebackup потратит одну попытку подключения. Так что в некоторых случаях, где мы хотим избежать лишних попыток подключения, полезно указать эту опцию.</div>
</blockquote>
<div style="text-align: justify;">
Другие, более редко используемые параметры:</div>
<div style="text-align: justify;">
-V</div>
<div style="text-align: justify;">
--version</div>
<blockquote class="tr_bq">
Печатает версию pg_basebackup и завершает работу</blockquote>
<div style="text-align: justify;">
-?</div>
<div style="text-align: justify;">
--help</div>
<blockquote class="tr_bq">
Показывает справку об аргументах командной строки и завершает работу</blockquote>
<h2>
Окружение</h2>
<div>
Эта утилита, как и многие другие утилиты PostgreSQL, использует переменные окружения, поддерживаемые libpq (см <a href="http://postgresql.ru.net/manual/libpq-envars.html" target="_blank">раздел 31.13</a>)</div>
<h2>
Примечание</h2>
<div style="text-align: justify;">
Резервная копия будет вкSee Alsoлючать все файлы в каталоге данных и пространстве таблиц, включая файлы конфигурации и все файлы, расположенные там сторонними программами. В каталоге данных могут быть только обычные файлы и каталоги, без символьных ссылок и файлов устройств.</div>
<div style="text-align: justify;">
Из-за того, как PostgreSQL обрабатывает пространства таблиц, путь к ним должен быть аналогичен на той системе, где резервная копия восстанавливается. Однако сам каталог данных может находиться и в другом месте.</div>
<h2>
Примеры</h2>
<div>
Для того, чтобы создать базовую резервную копию сервера с mydbserver и сохранить его в локальном каталоге /usr/local/pgsql/data:</div>
<div>
$ pg_basebackup -h mydbserver -D /usr/local/pgsql/data</div>
<div>
Для того, чтобы создать резервную копию локального сервера в виде одного tar файла для каждого пространства таблиц и сохранить его в каталоге backup, отображая прогресс архивирования:</div>
<div>
$ pg_basebackup -D backup -Ft -z -P</div>
<div>
Для того, чтобы создать резервную копию БД с одним пространством таблиц и сжать его с bzip2:</div>
<div>
$ pg_basebackup -D - -Ft | bzip2 > backup.tar.bz2</div>
<div>
(Эта команда не сработает при наличии нескольких пространств таблиц в БД)</div>
<h2>
См также</h2>
<div class="REFSECT1" style="font-family: verdana, sans-serif; font-size: 12px; margin: 0px; padding: 0px;">
<a href="http://postgresql.ru.net/manual/app-pgdump.html" style="color: #2e89bf; text-decoration: initial;">pg_dump</a></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com2tag:blogger.com,1999:blog-3495458762343321167.post-25287629557288381202013-01-21T01:31:00.000-08:002013-01-21T01:31:06.701-08:0019.2. Карты имён пользователей<div style="text-align: justify;">
Когда Вы используете внешние системы аутентификации как Ident или GSSAPI, то имя пользователя ОС, который устанавливает соединение, может не совпадать с именем пользователя, под которым он хочет подключиться. В этом случае карта имён пользователей может использоваться ОС для отображения имени пользователя ОС на имя пользователя БД. Для того, чтобы использовать отображение имён пользователей, используйте опцию map=map-name в поле опций pg_hba.conf. Эта опция поддерживается для всех методов аутентификации, которые получают внешние имена пользователей. Так как для разных подключений могут быть необходимы разные карты, имя карты в параметре указывает, какую именно карту использовать в этом случае.<a name='more'></a></div>
<div style="text-align: justify;">
Карты имён пользователей определяются в ident map file, который по умолчанию называется pg_ident.conf и хранится в каталоге данных. (Его возможно разместить и в другом месте - для этого используется параметр <a href="http://postgresql-lab.blogspot.ru/2013/01/182.html">ident_file</a>). Этот файл должен содержать строки в следующем формате:</div>
<div style="text-align: justify;">
map-name system-username database-username</div>
<div style="text-align: justify;">
Комментарии и пробелы обрабатываются так же как и в pg_hba.conf. map-name - обычное имя, которое используется как имя карты в pg_hba.conf. Два других поля определяют имя пользователя ОС и соответствующее имя пользователя БД. Одно и то же map-name можно несколько раз упоминать для разных пользователей в пределах одного файла.</div>
<div style="text-align: justify;">
Нет ограничений по соответствию имён пользователей ОС именам пользователей БД и наоборот. Таким образом, записи в карте должны трактоваться как "этот пользователь ОС может подключаться как этот пользователь БД", а не рассматривать их как аналоги. Подключение будет разрешено в случае если есть строка в карте, которая связывает имя пользователя, полученное из внешней системы аутентификации, с именем пользователя, под которым хотят подключиться.</div>
<div style="text-align: justify;">
Если поле system-username начинается со слеша (/), оставшаяся часть поля будет трактоваться как регулярное выражение (в <a href="http://postgresql-lab.blogspot.com/2013/01/97-pattern-matching.html">разделе 9.7.3.1</a> подробно описан синтаксис регулярных выражений PostgreSQL). Регулярное выражение может включать одно выражение или субвыражение в скобках, на которое можно потом сослаться в поле database-username при помощи \1 (обратный слеш и единица). Это позволяет отображать несколько имён пользователей на одной строке, что очень полезно для простого синтаксиса замены. Например, эти записи:</div>
<div style="text-align: justify;">
mymap /^(.*)@mydomain\.com$ \1</div>
<div style="text-align: justify;">
mymap /^(.*)@otherdomain\.com$ guest</div>
<div style="text-align: justify;">
удалит часть домена из имени пользователя, которое заканчивается на @mydomain.com и позволяет любому, чьё имя заканчивается на @otherdomain.com, заходить с именем guest.</div>
<div style="text-align: justify;">
<b>Совет:</b> Помните, что по умолчанию регулярное выражение может соответствовать только части строки. Обычно разумно использовать ^ и $, как показано в нашем примере, чтобы заставить шаблон соответствовать всему имени пользователя.</div>
<div style="text-align: justify;">
Файл pg_ident.conf прочитывается при запуске сервера и при получении главным процессом сигнала SIGHUP. Если Вы отредактировали файл на работающей системе, Вы должны послать сигнал основному процессу (при помощи pg_ctl reload или kill -HUP) для того, чтобы он перечитал файл.</div>
<div style="text-align: justify;">
Файл pg_ident.conf, который может быть использован вместе с файлом pg_hba.conf из <a href="http://postgresql-lab.blogspot.ru/2013/01/191-pghbaconf.html">примера в прошлом разделе</a>, приведён ниже. В нашем примере, любой, кто зашёл на машину в сети 192.168 не под именем bryanh, ann или robert не получит доступа. Пользователь robert получит право подключиться к PostgreSQL только под именем bob, не как robert или ещё кто-то. ann сможет подключиться только как ann. Пользователь bryanh сможет подключиться либо как bryanh, либо как guest1.</div>
<div style="text-align: justify;">
<br /></div>
<div class="EXAMPLE" style="font-family: verdana, sans-serif; font-size: 12px; margin: 0px; padding: 0px;">
<pre class="PROGRAMLISTING" style="padding: 0px;"># MAPNAME SYSTEM-USERNAME PG-USERNAME
omicron bryanh bryanh
omicron ann ann
# robert на этой машине будет пользователем <span style="font-family: verdana, sans-serif;">bob</span>
omicron robert bob
# bryanh может подключиться и как guest1
omicron bryanh guest1</pre>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com1tag:blogger.com,1999:blog-3495458762343321167.post-63006585206029200382013-01-20T22:56:00.001-08:002013-01-20T22:56:29.524-08:0019.1. Файл pg_hba.conf<div style="text-align: justify;">
Аутентификация клиента контролируется конфигурационным файлом, который обычно называется pg_hba.conf и хранится в каталоге кластера БД. (HBA означает host-based authentication - аутентификацию на основе хоста.) Файл со значениями по умолчанию создаётся при инициализации кластера при помощи initdb. Тем не менее можно разместить этот файл где угодно, для этого используется параметр <a href="http://postgresql-lab.blogspot.ru/2013/01/182.html" target="_blank">hba_file</a>.<br />
<a name='more'></a></div>
<div style="text-align: justify;">
Этот файл состоит из записей, по одной на строку. Пустые строки игнорируются, так же как и любой текст после знака #. Запись не может располагаться на нескольких строках. Каждая запись состоит из нескольких полей, разделённых пробелами или знаками табуляции. Значение поля может содержать пробелы, если это значение заключено в кавычки. Заключение в кавычки одного из ключевых слов в полях имени БД, пользователя или адреса (например, all или replication) приводит к тому, что это слово теряет свою специальную функцию и трактуется просто как набор соответствующих символов (то есть "all" будет означать не "любое значение", а значение с именем "all").</div>
<div style="text-align: justify;">
Каждая запись определяет тип подключения, интервал клиентских IP адресов (если это актуально для данного типа подключения), имя БД, имя пользователя и метод аутентификации, который будет использоваться для подключений, подпадающих под эти параметры. Первая запись с подходящим типом соединения, адресом клиента, запрашиваемой БД и именем пользователя будет использована для аутентификации. Если аутентификация по выбранной записи не проходит, то последующие записи даже не рассматриваются. Если подходящих записей нет - запрос отклоняется.</div>
<div style="text-align: justify;">
Запись может быть одного из семи видов:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<pre class="SYNOPSIS" style="padding: 0px; text-align: start;"><span style="font-family: inherit; font-size: x-small;">local <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
host <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>address</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
hostssl <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>address</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
hostnossl <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>address</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
host <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>IP-address</i></tt> <tt class="REPLACEABLE"><i>IP-mask</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
hostssl <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>IP-address</i></tt> <tt class="REPLACEABLE"><i>IP-mask</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]
hostnossl <tt class="REPLACEABLE"><i>database</i></tt> <tt class="REPLACEABLE"><i>user</i></tt> <tt class="REPLACEABLE"><i>IP-address</i></tt> <tt class="REPLACEABLE"><i>IP-mask</i></tt> <tt class="REPLACEABLE"><i>auth-method</i></tt> [<span class="OPTIONAL"><tt class="REPLACEABLE"><i>auth-options</i></tt></span>]</span></pre>
</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Значение полей следующее:</div>
<div style="text-align: justify;">
local</div>
<blockquote class="tr_bq" style="text-align: justify;">
Такая запись будет соответствовать соединениям, производимым через Unix-domain socket. Если записи такого типа нет, то подключения через Unix-domain socket будут запрещены.</blockquote>
<div style="text-align: justify;">
host</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Эта запись соответсвует подключениям через TCP/IP. Запись host соответствует как SSL так и не SSL подключениям.</div>
<div style="text-align: justify;">
<b style="font-weight: bold;">Примечание: </b>Удалённые TCP/IP подключения будут не возможны, пока сервер не будет запущен с соответствующем значением параметра listen_addresses, так как по умолчанию такие соединения будут ожидаться только на localhost.</div>
</blockquote>
<div style="text-align: justify;">
hostssl</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Эта запись будет соответствовать подключениям через TCP/IP, но только если они происходят с SSL шифрованием.</div>
<div style="text-align: justify;">
Для того, чтобы использовать эту опцию, сервер должен быть собран с поддержкой SSL. Более того, SSL должен быть активирован при запуске сервера при помощи параметра настройки <a href="http://postgresql-lab.blogspot.ru/2013/01/183.html" target="_blank">ssl</a> (более подробно - в <a href="http://postgresql-lab.blogspot.ru/2013/01/179-tcpip-ssl.html" target="_blank">разделе 17.9</a>)</div>
</blockquote>
<div style="text-align: justify;">
hostnossl</div>
<blockquote class="tr_bq" style="text-align: justify;">
Эта запись ведёт себя обратным образом от hostssl, ей подходят только те записи, которые делаются через TCP/IP и <i>не </i>используют SSL.</blockquote>
<div style="text-align: justify;">
database</div>
<blockquote class="tr_bq" style="text-align: justify;">
Определяет, какое / какие имена БД будут соответствовать этой записи. all означает, что подходит любая БД. Значение sameuser означает, что запись будет походить для запросов, где БД имеет то же имя, что и подключающийся пользователь. Значение samerole определяет, запись будет соответствовать случаю, когда подключающийся пользователь будет являться членом роли с именем запрашиваемой БД. (samegroup - устаревший, но всё ещё допустимый аналог samerole.) Значение replication определяет, что запись будет соответствовать случаю подключения для репликации (обратите внимание, что подключения для репликации не определяют конкретную БД). Другими словами, это имя определённой БД PostgreSQL. Можно указать несколько имён БД, разделив их запятыми. Можно указать файл, содержащий имена БД, указав его имя с предварительным знаком @.</blockquote>
<div style="text-align: justify;">
user</div>
<blockquote class="tr_bq" style="text-align: justify;">
Определяет при каком / каких имени пользователя будет происходить совпадение с данной записью. Значение all означает, что запись будет совпадать с любым имененем пользователя. Другими словами, это поле определяет или имя пользователя БД, или имя группы, если перед значением стоит +. (Напомним, что нет реальной разницы между пользователями и группами в PostgreSQL; знак + на самом деле означает "совпадает с любой ролью, которая прямо или не прямо является членом этой роли", тогда как имя без + означает, что совпадение будет только при совпадении именно с этой ролью.) Можно указать несколько имён пользователей, разделив их запятыми. Можно указать файл, содержащий имена пользователей, указав его имя с предварительным знаком @.</blockquote>
<div style="text-align: justify;">
address</div>
<blockquote class="tr_bq">
<div style="text-align: justify;">
Определяет адреса машины клиента, которым соответствует эта запись. Это поле может содержать либо имя хоста, либо диапазон IP адресов, либо одно из специальных слов, указанных ниже.</div>
<div style="text-align: justify;">
IP адрес задаётся в обычной точечной десятичной нотации с длиной маски <a href="http://ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%81%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B0%D1%86%D0%B8%D1%8F" target="_blank">бесклассовой адресации</a>. Длина маски определяет сколько бит IP адреса должны совпадать с заданными тут. Биты справа от маски в указанном IP адресе должны быть равны нулю. Не должно быть пробелов между адресом, знаком / и длиной маски.</div>
<div style="text-align: justify;">
Обычным примером диапазона IP адресов, указанного таким образом, является 172.20.143.89/32 для конкретного хоста, 172.20.143.0/24 для небольшой сети, 10.6.0.0/16 для большой. 0.0.0.0/0 означает любой IPv4 адрес, а ::/0 - любой IPv6 адрес. Для того, чтобы указать конкретный хост, используйте маску 32 для IPv4 или 128 для IPv6. В сетевом адресе не пропускайте конечные нули.</div>
<div style="text-align: justify;">
IP адрес, заданный в формате IPv4 будет соответствовать IPv6 подключению с соответствующим адресом, например, 127.0.0.1 будет соответствовать адресу ::ffff:127.0.0.1. Адрес же, заданный в формате IPv6, будет соответствовать только IPv6 подключениям, даже если сам этот адрес находится в диапазоне IPv4-in-IPv6. Обратите внимание, что записи в формате IPv6 будут отклонены, если системная библиотека С не поддерживает IPv6 адреса.</div>
<div style="text-align: justify;">
Кроме того, Вы можете использовать all, чтобы указать любой адрес, samehost, чтобы указать IP адрес самого сервера, и samenetto, что будет указывать на любой адрес в подсети, к которой подключён сервер.</div>
<div style="text-align: justify;">
Если указано имя хоста (всё, что не является IP адресом или ключевым словом - рассматривается как имя хоста), то это имя сравнивается с результатом получения имени узла по IP (то есть, используется reverse DNS lookup, если используется DNS). При сравнении регистр не учитывается. Если находится совпадение, то по имени определяется IP хоста при помощи forward DNS lookup, соответствует ли хоть один из полученных IP адресу хоста. Только если обе проверки выполняются, тогда считается что совпадение с записью произошло. (Имя узла, которое используется в pg_hba.conf, должно быть одним из адресов, полученных при разрешении имени, иначе совпадение не будет засчитано. Некоторые базы данных имён позволяют ассоциировать с IP адресом несколько имён хостов, но ОС будет возвращать только одно имя при запросе на получения имени по IP.)</div>
<div style="text-align: justify;">
Имя хоста, начинающееся с точки указывает на суффикс имени хоста. Таким образом, .example.com будет соответствовать foo.example.com (но не будет соответствовать просто example.com).</div>
<div style="text-align: justify;">
Когда имена хостов определены в pg_hba.conf, Вы должны быть уверены, что разрешение имён работает достаточно быстро. Может быть разумным настроить локальный кэш разрешения имён, например, <a href="http://www.freebsd.org/cgi/man.cgi?query=nscd&apropos=0&sektion=8&manpath=FreeBSD+9-current&arch=default&format=html" target="_blank">nscd</a>. Кроме того, Вы можете захотеть активировать параметр конфигурации log_hostname, чтобы видеть в логе имена хостов клиентов, вместо их IP.
</div>
<table border="1" cellpadding="5" class="SIDEBAR" style="border-collapse: collapse; margin: 1em 0px;"><tbody style="border-top-color: rgb(204, 204, 204); border-top-style: solid; border-top-width: 1px;">
<tr><td style="padding: 0.3em 0.5em;"><div class="SIDEBAR" style="margin: 0px; padding: 0px;">
<a href="http://www.blogger.com/blogger.g?blogID=3495458762343321167" name="AEN30768"></a><br />
<div style="margin-bottom: 1.2em; margin-top: 0.6em; padding: 0px;">
<div style="text-align: justify;">
Иногда пользователи удивляются, почему имена хостов обрабатываются таким сложным способом с двумя разрешениями имён и требует обратного разрешения IP адреса, что может быть не настроено или может выдавать нежелательные имена хоста. Во-первых, это сделано для эффективности, так как при попытке подключения требуется два разрешения адреса клиента. Если у резолвера есть проблемы с этим адресом, то это проблема клиента, не сервера. При другом способе реализации, если бы делалось только прямое разрешение, то при каждой попытке подключения требовалось бы разрешать каждое имя из файла pg_hba.conf, что само по себе было бы медленно. И если бы возникла проблема с разрешением одного имени, то это была бы проблема для всех узлов, не только проблемного.<br />
Кроме того, обратное разрешение необходимо для реализации возможности использования суффикса, так как для него необходимо полное имя клиента.<br />
Обратите внимание, что это поведение согласуется с другими популярными реализациями контроля доступа на основе имена узла, такими как Apache HTTP сервер и TCP Wrappers.</div>
</div>
</div>
</td></tr>
</tbody></table>
</blockquote>
<div style="text-align: justify;">
Это поле применимо только к записям host, hostssl и hostnossl.</div>
IP-address<br />
IP-mask<br />
<blockquote class="tr_bq" style="text-align: justify;">
Эти поля могут быть использованы как альтернатива нотации бесклассовой адресации. Вместо указания длины маски, можно указать просто маску в отдельной колонке. Например, 255.0.0.0 будет соответствовать длине маске 8, а 255.255.255.255 - длине маски 32.</blockquote>
<blockquote class="tr_bq" style="text-align: justify;">
Эти поля актуальны только для записей host, hostssl и hostnossl.</blockquote>
auth-method<br />
<blockquote class="tr_bq" style="text-align: justify;">
Определяет метод аутентификации, который будет использован при совпадении с записью. Возможные значения приведены тут, детали - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3</a><br />
<b>trust</b><br />
Безусловно разрешает все подключения. Этот метод разрешает любому, кто может подключиться к серверу БД, зайти под любым пользователем PostgreSQL без необходимости предоставить пароль или использования какого-либо ещё способа аутентификации. Более подробно - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.1</a>.<br />
<b>reject</b><br />
Безусловно отклоняет подключение. Это полезно для "отфильтровывания" некоторых узлов из группы, например строка reject может запретить конкретному узлу подключение, тогда как следующая строка разрешает подключения для остальных узлов этой сети.<br />
<b>md5</b><br />
Требует от клиента предоставить md5 шифрованный пароль для аутентификации. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.2</a><br />
<b>password</b><br />
Требует от клиента предоставить незашифрованный пароль для аутентификации. Так как пароль посылается по сети в открытом виде, эта опция не должна использоваться для небезопасных сетей. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.2</a><br />
<b>gss</b><br />
Использует GSSAPI для аутентификации пользователя. Доступно только для TCP/IP подключений. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.3</a><br />
<b>sspi</b><br />
Использует SSPI для аутентификации пользователя. Доступно только для Windows. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.4</a><br />
<b>krb5</b><br />
Использует Kreberos V5 для аутентификации пользователя. Доступно только для TCP/IP подключений. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.5</a><br />
<b>ident</b><br />
Получает имя пользователя ОС клиента, соединяясь с сервером <a href="http://ru.wikipedia.org/wiki/Ident" target="_blank">ident</a> на клиенте и проверяет, соответствует ли оно имени пользователя для запрашиваемой БД. Аутентификация ident может использоваться только на TCP/IP соединениях. Когда это значение используется для локальных соединений, то вместо этого используется peer аутентификация. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.6</a><br />
<b>peer</b><br />
Получает имя пользователя ОС из самой ОС и проверяет, соответствует ли оно имени пользователя для запрашиваемой БД. Доступно только для локальных подключений. Подробнее - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.7</a><br />
<b>ldap</b><br />
Аутентификация при помощи сервера LDAP. Подробнее - <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">раздел 19.3.8</a><br />
<b>radius</b><br />
Аутентификация при помощи сервера RADIUS. Подробнее - <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">раздел 19.3.9</a><br />
<b>cert</b><br />
Аутентификация при помощи SSL сертификата клиента. Подробнее - <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">раздел 19.3.10</a><br />
<b>pam</b><br />
Аутентификация при помощи <a href="http://ru.wikipedia.org/wiki/Pluggable_Authentication_Modules" target="_blank">Pluggable Authentication Modules (PAM)</a>, предоставляемыми ОC. Подробнее - <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">раздел 19.3.11</a></blockquote>
<br />
auth-options<br />
<blockquote class="tr_bq" style="text-align: justify;">
После поля auth-method могут быть поля в форме name=value, которые задают опции для метода аутентификации. О доступных опциях для каждого метода - см. ниже</blockquote>
<div style="text-align: justify;">
Файлы, добавляемые при помощи знака @, прочитываются как список имён, которые могут быть разделены пробелами или запятыми. Комментарии предваряются знаком #. Допустимы конструкции с вложением фалов. Если имя, следующее за @ не является абсолютным путём, то путь рассчитывается относительно каталога, содержащего ссылающийся файл.</div>
<div style="text-align: justify;">
Так как записи pg_hba.conf проверяются последовательно при каждой попытке подключения, порядок расположения записей крайне важен. Обычно, более ранние записи будут иметь более строгие требования к совпадению и более лёгкие методы аутентификации, тогда как более поздние подходят для большего числа случаев подключений и требуют более серьёзных методов аутентификации. Например, мы можем хотеть использовать trust для локальных TCP/IP соединений, но требовать пароль для удалённых TCP/IP соединений. В этом случае запись, определяющая метод аутентификации trust для соединений с 127.0.0.1 должна быть раньше, чем запись, требующая предоставления пароля для более широкого диапазона клиентских IP адресов.</div>
<div style="text-align: justify;">
Файл pg_hba.conf прочитывается при старте системы и при получении главным процессом сигнала SIGHUP. Если Вы отредактировали этот файл на работающей системе, Вы должны послать сигнал главному процессу (при помощи pg_ctl reload или kill -HUP), чтобы файл был перечитан.</div>
<div style="text-align: justify;">
<b>Совет</b>: для подключения к конкретной БД пользователь должен не только пройти проверку через файл pg_hba.conf, но и должен иметь привилегию CONNECT для этой БД. Если Вы хотите ограничить список пользователей к некоторым БД, обычно это проще всего сделать выдавая или отбирая привилегию CONNECT, а не редактировать правила в pg_hba.conf</div>
<div style="text-align: justify;">
Некоторые примеры записей pg_hba.conf приведены ниже. В следующем же разделе более подробно будут описаны различные методы аутентификации. (<i>Копипаста из примера работать, возможно, не будет из-за смеси пробелов и табуляций - примечание переводчика</i>)</div>
<div style="text-align: justify;">
<br /></div>
<div class="EXAMPLE" style="margin: 0px; padding: 0px;">
<pre class="PROGRAMLISTING" style="padding: 0px;"><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;"># Позволяем любому локальному пользователю подключиться к любой БД с любым </span></span><span style="font-size: 12px;">именем</span><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;">
# пользователя при помощи Unix-domain sockets (значение по умолчанию для локальных
# подключений).
#
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
# То же самое, но при помощи loopback TCP/IP подключений.
#
# TYPE DATABASE USER ADDRESS METHOD
host all </span></span><span style="font-family: verdana, sans-serif; font-size: 12px;"> all 127.0.0.1/32 trust</span></pre>
<pre class="PROGRAMLISTING" style="padding: 0px;"><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;">
# То же самое, но используя отдельное поле для маски сети
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 127.0.0.1 255.255.255.255 trust
# То же самое для IPv6.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all ::1/128 trust
# То же самое при помощи имени узла (работает и для IPv4 и для IPv6).
#
# TYPE DATABASE USER ADDRESS METHOD
host all all localhost trust
# Позволяет любому пользователю с любого хоста с IP 192.168.93.x
# подключиться к БД "postgres" с тем именем пользователя, которое</span></span></pre>
<pre class="PROGRAMLISTING" style="padding: 0px;"><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;"># предоставляется ident для подключений (обычно - имя пользователя ОС)
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Позволяет любому пользователю с узла 192.168.12.10 подключиться к БД
# "postgres" если передан верный пароль пользователя
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.12.10/32 md5
# Позволяет любому пользователю с хоста домена example.com
# подключиться к любой БД при верном пароле пользователя
#
# TYPE DATABASE USER ADDRESS METHOD
host all all .example.com md5
# В отсутствии предыдущих строк, эти две записи будут отклонять
# все подключения с 192.168.54.1 (так как они совпадают с первой
# записью), но разрешает подключения Kerberos 5 со всего
# интернета. Маска 0 означает, что не рассматриваются биты IP
# адреса хоста, так что сюда попадает любой узел.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 krb5
# Позволяет пользователям с узлов 192.168.x.x подключиться к любой
# БД, если он проходит проверку ident. Если, например, ident говорит, что</span></span></pre>
<pre class="PROGRAMLISTING" style="padding: 0px;"><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;"># пользователь - "bryanh" и он пытается подключиться как пользователь
# PostgreSQL "guest1", соединение будет разрешено, если запись в pg_ident.conf
# для карты "omicron" говорит, что "bryanh" может подключиться как "guest1".
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.0.0/16 ident map=omicron
# Если есть только эти три строки для локальных подключений, то они будут
# разрешать локальным пользователям подключаться только к их собственным</span></span></pre>
<pre class="PROGRAMLISTING" style="padding: 0px;"><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;"># БД (БД с тем же именем, что их имя пользователя), за исключением администраторов
# и членов роли "support", которые могут подключиться к любой БД. Файл
# $PGDATA/admins содержит список имён администраторов. Пароли требуются во
# всех случаях.
#
# TYPE DATABASE USER ADDRESS METHOD
local sameuser all md5
local all @admins md5
local all +support md5
# Последние две строки из примера выше могут быть объеденные в одну:
local all @admins,+support md5
# Поле БД тоже может использовать список и имена файлов:
local db1,db2,@demodbs all md5</span></span></pre>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com3tag:blogger.com,1999:blog-3495458762343321167.post-65402485360261059212013-01-17T04:33:00.002-08:002013-01-17T04:33:55.453-08:0018.6. Репликация<div style="text-align: justify;">
Эти настройки управляют встроенной <i>потоковой репликацией </i>(см <a href="http://postgresql-lab.blogspot.ru/2012/12/25.html" target="_blank">раздел 25.2.5</a>). Некоторые параметры должны быть заданы на мастере, другие - на резервном сервере, которые будут получать данные репликации.<a name='more'></a></div>
<h2 style="text-align: justify;">
18.6.1 Мастер</h2>
<div style="text-align: justify;">
Следующие параметры могут быть заданы на мастере - том сервере, который будет посылать данные для репликации на один или более резервных серверов. Обратите внимание, что кроме этих параметров, должно быть установлено корректное значение параметра <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">wal_level</a>; кроме этого Вы скорее всего захотите активировать WAL архивирование (см <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">раздел 18.5.3</a>). Значения этих параметров на резервном сервере не имеют значения, но Вы всё равно можете их задать в качестве подготовки его как мастера.</div>
<div style="text-align: justify;">
<b>max_wal_senders (integer)</b></div>
<div style="text-align: justify;">
Определяет максимальное количество одновременных подключений от резервных серверов или клиентов потокового резервного копирования (т.е. максимальное количество одновременно запущенных процессов отправителей WAL). Значение по умолчанию - 0. Этот параметр может быть задан только при старте сервера. wal_level должен быть установлен в archive или hot_standby, чтобы разрешить подключения от резервных серверов.</div>
<div style="text-align: justify;">
<b>wal_sender_delay (integer)</b></div>
<div style="text-align: justify;">
Определяет задержку между циклами активности процессов отправителей WAL. В каждом цикле отправитель WAL посылает все WAL, собранные с последнего цикла, на резернвый сервер. После этого процесс засыпает на wal_sender_delay и цикл начинается заново. Сон прерывается подтверждением транзакции, так что подтверждённые транзакции отправляются на резервные сервера сразу после подтверждения, вне зависимости от этой настройки. Значение по умолчанию - 1 секунда (1s). Обратите внимание, что не многих системах разница между значениями этого параметра должна быть не меньше 10 миллисекунд; задание значения не кратного 10 будет иметь тот же эффект, что и ближайшее больше значение, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
<b>wal_keep_segments (integer)</b></div>
<div style="text-align: justify;">
Определяет минимальное число файлов сегментов лога, хранимых в каталоге pg_xlog, в случае если резервный сервер должен получить их для потоковой репликации. Каждый сегмент обычно равен 16 мегабайт. Если резервный сервер отстаёт от мастера больше чем на wal_keep_segments сегментов, то мастер удалит нужные сегменты WAL и в таком случае подключение репликации будет прервано. (Однако, резервный сервер может затем восстановить эти сегменты из архива, если происходит архивирование WAL.)</div>
<div style="text-align: justify;">
Данная настройка задаёт только минимальное количество сегментов, хранимых в pg_xlog; система может хранить и больше количество сегментов для архивирования WAL или восстановления из чекпойнта. Если wal_keep_segments = 0 (значение по умолчанию), то система на хранит дополнительные сегменты для резервных серверов, так что количество доступных сегментов WAL является функцией места предыдущего чекпойнта и статуса архивирования WAL. Этот параметр не имеет влияния на restartpoints. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
<b>vacuum_defer_cleanup_age (integer)</b></div>
<div style="text-align: justify;">
Определяет число транзакций, по которым VACUUM и HOT обновления будут определять очистку версий мёртвых строк. Значение по умолчанию - 0 транзакций, что означает, что версии мёртвых строк будут удалены как только появится возможность, то есть как только они не видны ни одной открытой транзакции. Вы можете захотеть установить ненулевое значение на мастере, который поддерживает "горячие" резервные сервера, как это описано в <a href="http://postgresql-lab.blogspot.com/2013/01/255-hot-standby.html" target="_blank">разделе 25.5</a>. Это предоставляет больше времени для запросов к резервным серверам, чтобы при этом не возникли конфликты из-за раннего удаления строк. Однако, поскольку это значение измеряется в терминах количества операций записи транзакций на основном сервере, трудно предсказать, сколько времени это предоставит для резервного сервера. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
Вам следует так же рассмотреть возможность использования настройки hot_standby_feedback в качестве альтернативы этого параметра.</div>
<div style="text-align: justify;">
<b>replication_timeout (integer)</b></div>
<div style="text-align: justify;">
Соединения репликации, неактивные больше чем заданное тут время в миллисекундах, разрываются. Это полезно для мастера для обнаружения проблем в сети и сбоя резервного сервера. Значение, равное 0, отключает этот механизм. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке. Значение по умолчанию - 60 секунд.</div>
<div style="text-align: justify;">
Для того, чтобы соединения не разрывались, wal_receiver_status_interval должен быть активирован на резервном сервере и это значение должно быть меньше, чем replication_timeout.</div>
<div style="text-align: justify;">
<b>synchronous_standby_names (string)</b></div>
<div style="text-align: justify;">
Значением параметра является список, с разделителями запятыми, который содержит имена резервных серверов, которые поддерживают <i>синхронную репликацию, </i>как это описано в <a href="http://postgresql-lab.blogspot.ru/2012/12/25.html" target="_blank">разделе 25.2.6</a>. В каждый момент времени есть максимум один активный синхронный резервный сервер; транзакции, ожидающие подтверждения, будут подтверждены лишь после того, как этот резервный сервер подтвердит получение их данных. Синхронным резервным сервером будет первый из списка, который и подключён и получает данные в реальном времени (как это отображается в состоянии потока в <a href="http://postgresql-lab.blogspot.com/2013/01/272-statistics-collector.html" target="_blank">pg_stat_replication</a>). Другие резервные сервера, находящиеся позже в этом списке, являются потенциальными синхронными резервными серверами. Если текущий синхронный резервный сервер по какой-то причине отключается, то он тут же замещается на следующий сервер в этом списке. Указание более одного сервера может повысить отказоустойчивость.</div>
<div style="text-align: justify;">
В качестве имени резервного сервера в этом параметре надо указывать значение настройки application_name на резервном сервере, <span style="color: red;">as set in the primary_conninfo of the standby's walreceiver. </span>Нет какого-то способа обеспечить уникальность имён серверов. В случае, если одному и тому же имени соответствует два или более сервера, один из них будет выбран в качестве синхронного, но какой именно - не определено. Значение * будет означать любое application_name, включая значение по умолчанию walreceiver.</div>
<div style="text-align: justify;">
Если имена резервных серверов тут не указаны, тогда синхронной репликации не происходит и подтверждение транзакции не будет ожидать репликации. Это конфигурация по умолчанию. Даже если синхронная репликация активирована, можно сделать так, чтобы конкретные транзакции не ожидали репликации, задав значение параметра <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">synchronous_commit</a> local или off.</div>
<div style="text-align: justify;">
Этот параметр может быть задан в postgresql.conf или в командной строке.</div>
<h2 style="text-align: justify;">
18.6.2 Резервные сервера</h2>
<div style="text-align: justify;">
Эти настройки определяют поведение резервных серверов, которые должны получать данные для репликации. Их значение на мастере не имеет никакого значения.</div>
<div style="text-align: justify;">
<b>hot_standby (boolean)</b></div>
<div style="text-align: justify;">
Определяет, можете ли Вы подключиться для выполнения запросов к серверу во время восстановления, как это описано в <a href="http://postgresql-lab.blogspot.com/2013/01/255-hot-standby.html" target="_blank">разделе 25.5</a>. Значение по умолчанию - off. Этот параметр может быть задан только при старте сервера. Он имеет значение только при восстановлении архива или в режиме standby (резервного сервера).</div>
<div style="text-align: justify;">
<b>max_standby_archive_delay (integer)</b></div>
<div style="text-align: justify;">
Когда активен режим "горячего" резервного сервера, этот параметр определяет как долго резервный сервер должен ждать перед отменой запроса к нему, если этот запрос конфликтует с записями WAL, которые должны быть сейчас применены, как об этом говорится в <a href="http://postgresql-lab.blogspot.com/2013/01/255-hot-standby.html" target="_blank">разделе 25.5.2</a>. max_standby_archive_delay применяется когда WAL данные считываются из WAL архива (и потому не являются текущими данными). Значение по умолчанию - 30 секунд. Единица измерения - миллисекунды, если не определено иначе. Значение -1 позволяет резервному серверу вечно ждать завершения конфликтующего запроса. Этот параметр может быть определён в postgresql.conf или в командной строке.</div>
<div style="text-align: justify;">
Обратите внимание, что max_standby_archive_delay - не то же самое, что и максимальное время, которое запрос может выполняться до его завершения; это то время, которое дано на применение одного сегмента WAL данных. Таким образом, если один запрос привёл к значительной задержке в начале сегмента WAL, последующие конфликтующие запросы будут иметь гораздо меньше этого времени.</div>
<div style="text-align: justify;">
<b>max_standby_streaming_delay (integer)</b></div>
<div>
<div style="text-align: justify;">
Когда активен режим "горячего" резервного сервера, этот параметр определяет как долго резервный сервер должен ждать перед отменой запроса к нему, если этот запрос конфликтует с записями WAL, которые должны быть сейчас применены, как об этом говорится в <a href="http://postgresql-lab.blogspot.com/2013/01/255-hot-standby.html" target="_blank">разделе 25.5.2</a>. max_standby_streaming_delay применяется когда WAL данные получаются через потоковую репликацию. Значение по умолчанию - 30 секунд. Единица измерения - миллисекунды, если не определено иначе. Значение -1 позволяет резервному серверу вечно ждать завершения конфликтующего запроса. Этот параметр может быть определён в postgresql.conf или в командной строке.</div>
<div style="text-align: justify;">
Обратите внимание, что max_standby_streaming_delay - не то же самое, что и максимальное время, которое запрос может выполняться до его завершения; это то время, которое дано на применение одного сегмента WAL данных после его получения с мастера. T<span style="color: red;">hus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again.</span></div>
<div style="text-align: justify;">
<b>wal_receiver_status_interval (integer)</b></div>
</div>
<div style="text-align: justify;">
Определяет минимальную частоту, с которой процесс получения WAL на резервном сервере будет gjcksfnm на мастер информацию о прогрессе репликации, который можно увидеть при помощи <a href="http://postgresql-lab.blogspot.com/2013/01/272-statistics-collector.html" target="_blank">pg_stat_replication</a>. Резервный сервер сообщает последнюю позицию в логе транзакций, которая была записана, последняя позиция, сброшенная на диск и последняя применённая позиция. Значением этого параметра является максимальный интервал, в секундах, между отчётами. Обновления посылаются каждый раз, когда изменяется позиция записи или сброса на диск, или, не позже, чем указанное тут время. Таким образом, реальная применённая позиция может немного отличаться от переданной. Установка этого параметра в 0 отключает обновление статуса. Этот параметр может быть задан в postgresql.conf или в командной строке. Значение по умолчанию - 10 секунд.</div>
<div style="text-align: justify;">
Когда активирован replication_timeout на мастере, wal_receiver_status_interval тоже должен быть активирован и его значение должно быть меньше, чем replication_timeout.</div>
<div style="text-align: justify;">
<b>hot_standby_feedback (boolean)</b></div>
<div style="text-align: justify;">
Определяет, будет или нет "горячий" резервный сервер посылать "отзыв" (feedback) мастеру по поводу запросов, которые сейчас выполняются на резервном сервере. Этот параметр может быть использован для того, чтобы запросы не прекращались из-за очистки записей, но может увеличить нагрузку на мастер. "Отзывы" не будут посылаться чаще, чем 1 отзыв в wal_receiver_status_interval интервал. Значение по умолчанию - off. Этот параметр может быть задан в postgresql.conf или в командной строке.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-59086674802562941862013-01-16T03:56:00.001-08:002013-01-16T03:56:49.270-08:0018.5. Write Ahead Log<div style="text-align: justify;">
Обратитесь так же к <a href="http://postgresql.ru.net/manual/wal-configuration.html" target="_blank">разделу 29.4</a>, где говорится более подробно об WAL и настройке чекпойнтов.<br />
<a name='more'></a></div>
<h2>
18.5.1 Настройки</h2>
<div style="text-align: justify;">
<b>wal_level (enum)</b></div>
<div style="text-align: justify;">
wal_level определяет как много информации будет записываться в WAL. Значение по умолчанию - minimal, что означает, что записывается только информация, необходимая для восстановления при крахе системы или "немедленном" выключении. archive добавляет логи, необходимые для WAL архивирования, а hot_standby добавляет ещё и информацию, необходимую для выполнения запросов на чтения с резервного сервера. Этот параметр может быть задан только при старте сервера.</div>
<div style="text-align: justify;">
На уровне minimal WAL логирование - что-то вроде операции "в нагрузку", которую можно спокойно пропустить, что может сделать следующие операции быстрее (см раздел 14.4.7):</div>
<div style="text-align: justify;">
CREATE TABLE AS</div>
<div style="text-align: justify;">
CREATE INDEX</div>
<div style="text-align: justify;">
CLUSTER</div>
<div style="text-align: justify;">
COPY в таблицы, которые были созданы или усечены в этой же транзакции</div>
<div style="text-align: justify;">
Но такой WAL yt содержит достаточно информации, чтобы восстановить данные из резервной копии и WAL логов; для этого нужно использовать уровень archive или hot_standby, чтобы запустить архивирование WAL или потоковую репликацию.</div>
<div style="text-align: justify;">
На уровне hot_standby сохраняется та же информация, что и на уровне archive, плюс информация, необходимая для восстановления статуса текущей транзакции из WAL. Для того, чтобы позволить обрабатывать запросы на чтение с резервного сервера, wal_level должен быть установлен в hot_standby на мастере и <a href="http://postgresql-lab.blogspot.com/2013/01/186-replication.html" target="_blank">hot_standby</a> должен быть активирован на резервном сервере. Считается, что разница в производительности на уровнях archive и hot_standby незначительна, так что если Вы обнаружите что-то другое - обязательно об этом сообщите.</div>
<div style="text-align: justify;">
<b>fsync (boolean)</b></div>
<div style="text-align: justify;">
Если этот параметр активирован, то PostgreSQL сервер будет стараться убедиться, что обновления физически записаны на диск, делая системный вызов fsync() или другим эквивалентным методом (см wal_sync_method). Это позволяет быть уверенным, что кластер БД может быть восстановлен к согласующемуся состоянию после краха ОС или выхода из строя оборудования.</div>
<div style="text-align: justify;">
Хотя отключение fsync чаще всего даёт выигрыш в производительности, это может привести к невосстановимому повреждению данных в случае перебоя с электричеством или краха ОС. Поэтому его рекомендуется отключать только если Вы легко можете восстановить свои данные из внешнего хранилища.</div>
<div style="text-align: justify;">
Пример ситуации, когда можно спокойно отключить fsync - при первоначальной загрузке данных в новый кластер БД из резервной копии, использовании кластера БД для обработки набора данных, после чего эта БД будет пересоздана, или клон БД только для чтения, который часто пересоздаётся и не используется для обеспечения бесперебойной работы. Только лишь высокое качество железа - не достаточная причина для отключения fsync.</div>
<div style="text-align: justify;">
Во многих ситуациях отключение synchronous_commit для некритических транзакций может привести к гораздо большему росту производительности, чем fsync, при этом без риска получить повреждённые данные.</div>
<div style="text-align: justify;">
fsync может быть задан либо в postgresql.conf, либо в командной строке. Если Вы его отключаете, подумайте и о том, чтобы отключить full_page_writes.</div>
<div style="text-align: justify;">
<b>synchronous_commit (boolean)</b></div>
<div style="text-align: justify;">
Определяет, будет ли подтверждение транзакции ожидать записи WAL на диск перед возвратом "успеха" клиенту. Доступные значения - on, local и off. Значение по умолчанию, оно же самое безопасное - on. Если значение off, то может быть задержка между тем, что клиенту сообщено об успешном завершении транзакции и её реальной записью на диск (что, собственно, и гарантирует её сохранность). (Максимальная величина задержки равна 3*wal_writer_delay). В отличие от fsync, установка этого параметра в off не создаёт риска несогласованности БД: крах ОС или БД может привести к тому, что некоторые недавние якобы подтверждённые транзакции будут потеряны, но состояние БД будет такое же, как если бы эти транзакции были бы просто отменены. Так что отключение synchromous_commit может быть полезно в случаях, когда производительность важнее, чем гарантированность транзакций. Более подробно это обсуждается в <a href="http://postgresql.ru.net/manual/wal-async-commit.html" target="_blank">разделе 29.3</a></div>
<div style="text-align: justify;">
Если заданы <a href="http://postgresql-lab.blogspot.com/2013/01/186-replication.html" target="_blank">synchronous_standby_names</a>, этот параметр так же контролирует, ожидает ли подтверждение транзакции записи WAL на диск и репликации на резервный сервер. Подтверждение не будет послано, пока не будет получено сообщение от синхронного резервного сервера, что транзакция была записана на диск. Если используется синхронная репликация, то как правило разумно либо дожидаться подтверждения как на локальный так и на удалённый диск, или же подтверждать транзакции асинхронно. Однако специальное значение local позволяет ждать записи только на локальный диск, но не подтверждения синхронной репликации.</div>
<div style="text-align: justify;">
Этот параметр может быть изменён в любое время; поведение каждой отдельной транзакции зависит от того, какое значение имела эта настройка на момент этой транзакции. Поэтому возможно и полезно подтверждать некоторые транзакции синхронно, а некоторые - асинхронно. Например, для того, чтобы подтвердить одну транзакцию асинхронно, тогда как остальные подтверждать синхронно, задайте SET LOCAL synchronous_commit TO OFF в этой транзакции.</div>
<div style="text-align: justify;">
wal_sync_method (enum)</div>
<div style="text-align: justify;">
Метод, используемый для принудительной записи обновлений WAL на диск. Если fsync выключен, то эта настройка игнорируется, так как принудительной записи WAL вообще не будет. Возможные значения:</div>
<div style="text-align: justify;">
<ul>
<li>open_datasync (записывает WAL файлы при помощи open() c опцией 0_DSYNC)</li>
<li>fdatasync (вызывает fdatadync() для каждого подтверждения)</li>
<li>fsync (вызывает fsync() для каждого подтверждения)</li>
<li>fsync_writethrough (вызывает fsync() для каждого подтверждения, принудительно записывая данные, минуя кеш записи)</li>
<li>open_sync (записывает WAL файлы при помощи open() c опцией 0_SYNC)</li>
</ul>
<div>
Опции open_* так же при возможности используют 0_DIRECT. Не все варианты доступны на всех платформах. По умолчанию используется первый доступный на данной платформе метод из списка, но на Linux по умолчанию используется fdatasync. Значение по умолчанию не обязательно самое лучшее; возможно, что для большей надёжности или производительности Вам придётся изменить некоторые настройки. Это обсуждается в <a href="http://postgresql.ru.net/manual/wal-reliability.html" target="_blank">разделе 29.1</a>. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div>
<b>full_page_writes (boolean)</b><br />
Когда этот параметр активирован, PostgreSQL сервер будет записывать всё содержимое каждой дисковой страницы WAL при первом изменении этой страницы после чекпойнта. Необходимость в этом возникает потому что во время записи страницы может произойти крах системы в результате чего на диске может получиться смесь старых и новых данных. Хранящиеся обычно в WAL изменения данных на уровне строки будут недостаточны для того, чтобы восстановить такую страницу в процессе восстановления данных. Сохранение же всей страницы гарантирует, что страница будет восстановлена целиком, но зато это требует записи большего объёма данных в WAL. (Так как восстановление WAL всегда начинается с чекпойнта, важно делать это при первом изменении каждой страницы после чекпойнта. Поэтому для снижения затрат на эту процедуру можно увеличить интервал чекпойнтов.)<br />
Отключение этого параметра ускоряет обычные операции, но может привести к невосстановимому повреждению данных или к тихому повреждению данных при падении системы. Этот риск схожий с отключением fsync, хотя и меньший, и руководствоваться в вопросе его отключения стоит теми же принципами.<br />
Отключение этого параметра не влияет на использование WAL архивирования для poin-in-time восстановления (PITR) (см <a href="http://postgresql.ru.net/manual/continuous-archiving.html" target="_blank">раздел 24.3</a>)<br />
Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<b>wal_buffers (integer)</b><br />
Количество разделяемой памяти, используемой для WAL данных, которые ещё не были записаны на диск. Значение по умолчанию -1, что означает использование 1/32 (около 3%) <a href="http://postgresql-lab.blogspot.ru/2013/01/184.html" target="_blank">shared_buffers</a>, но не меньше 64kB и не больше размера сегмента WAL, обычно 16MB. Это значение можно задать вручную, если автоматическое значение слишком большое или маленькое, но любое положительное значение меньше 32kB будет трактоваться как 32kB. Этот параметр можно задать только при старте сервера.<br />
Содержимое WAL буферов записывается на диск при каждом подтверждении транзакции, так что очень большие значения скорее всего не дадут прироста производительности. Однако значение в несколько мегабайт может увеличить производительность записи на занятом сервере, где много клиентов подтверждают транзакции одновременно. Автоматически выбираемое значение в большинстве случаев даёт хороший результат.<br />
Увеличение этого параметра может привести к тому, что PostgreSQL потребует больше разделяемой памяти System V, чем позволяет конфигурация вашей системы. В <a href="http://postgresql-lab.blogspot.ru/2013/01/174.html" target="_blank">разделе 17.4.1 </a>говорится как с этим справиться.<br />
<b>wal_writer_delay (integer)</b><br />
Определяет паузу между циклами активности WAL writer'a. В каждом цикле writer записывает WAL на диск. После этого он засыпает на wal_writer_delay миллисекунд и снова начинает запись. Значение по умолчанию - 200 миллисекунд (200ms). Обратите внимание, что на многих системах шаг интервала должен быть 10 миллисекунд; задание значения которое не кратно 10 может расцениваться как большее значение, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<b>commit_delay (integer)</b><br />
Когда данные транзакции записываются на диск, все другие транзакции, готовые к записи в это время тоже записываются на диск. commit_delay добавляет паузу, в микросекундах, перед тем, как транзакция будет записана на диск. Ненулевая задержка может привести к тому, что будет записано больше транзакций, если нагрузка на систему достаточна, чтобы дополнительные транзакции были готовы к записи. Поэтому пауза происходит только если хотя бы commit_siblings других транзакций активны на момент записи первой транзакции. Значением по умолчанию commit_delay является 0 (отсутствие задержки). Так как все отложенные данные будут записаны при каждой записи, вне зависимости от настройки, в редких случаях дополнительная пауза будет увеличивать производительность.<br />
<b>commit_siblings (integer)</b><br />
Минимальное число одновременно открытых транзакций требуемых для выполнения паузы commit_delay. Больше значение повышает вероятность того, что как минимум ещё одна транзакция будет готова для записи в течении паузы. По умолчанию - 5 транзакций.<br />
<h2>
18.5.2 Чекпойнты</h2>
<b>checkpoint_segments (integer)</b><br />
Максимальное число сегментов лога между автоматическими чекпойнтами WAL (каждый сегмент, обычно - 16 мегабайт). Значение по умолчанию - 3 сегмента. Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<b>chechpoint_timeout (integer)</b><br />
Максимальный период времени между WAL чекпойнтами, в секундах. Значение по умолчанию - 5 минут (5min). Увеличение этого параметра может увеличить время, необходимое для восстановления после краха. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<b>checkpoint_completion_target (floating point)</b><br />
Определяет время для завершения чекпойнта как долю от времени между чекпойнтами. Значение по умолчанию - 0.5. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<b>checkpoint_warning (integer)</b><br />
Записывает сообщение в лог сервера если создание чекпойнтов, вызванное заполнением файлов сегментов, происходит чаще, чем в это количество секунд (что подразумевает, что checkpoint_segments должно быть увеличено). Значение по умолчанию - 30 секунд (30s). 0 отключает предупреждения. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.<br />
<h2>
18.5.3 Архивирование</h2>
<b>archieve_mode (boolean)</b><br />
Когда активирована эта настройка, завершённые сегменты WAL отправляются в архив, заданный archive_command. archive_mode и archive_command - разные параметры, так что каждый из них может быть изменён независимо. Этот параметр может быть задан только при запуске сервера. archive_mode не может быть активирован, если wal_level = minimal.<br />
<b>archive_command (string)</b><br />
Команда оболочки, которая выполняется для архивирования файловых сегментов WAL. %p в строке будет заменён на путь к файлу архива, а %f - на имя файла архива. (Путь задаётся относительно рабочего каталога сервера, т.е. каталога данных). Для того, чтобы использовать знак % замените его на %%. Важно, чтобы команда возвращала 0 в качестве статуса завершения только в случае благополучного выполнения команды. Более подробно смотрите <a href="http://postgresql.ru.net/manual/continuous-archiving.html#BACKUP-ARCHIVING-WAL" target="_blank">раздел 24.3.1</a><br />
Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке. Он игнорируется, если archive_mode не был активирован при старте сервера. Если archive_command является пустой строкой (по умолчанию), а archive_mode активирован, WAL архивирование временно не работает, но сервер продолжает собирать WAL сегменты в ожидании получения команды для архивирования. Если указанная команда ничего не делает, но возвращает true (например, /bin/true или REM под Windows), то по факту это отменяет архивирование, но и прерывает цепочку WAL файлов, необходимых для восстановления архива, так что это можно использовать только в нестандартных ситуациях.<br />
<b>archive_timeout (integer)</b><br />
archive_command вызывается только для завершённых сегментов WAL. Но, если ваш сервер производит небольшой WAL трафик (даже в некоторые периоды), то могут быть длительные паузы между завершением транзакции и её записью в архив. Для того, чтобы ограничить количество не заархивированных данных Вы можете задать archive_timeout, чтобы принудить сервер периодически переключаться на новый файл сегмента. Если этот параметр больше нуля, то сервер будет переключаться на новый файл сегмента каждые archive_timeout секунд и при этом была какая-то активность БД, включая единичный чекпойнт. (Увеличение checkpoint_time сократит лишние чекпойнты на бездействующей системе.) Обратите внимание, что заархивированный файл, закрытый из-за такого переключения, будет иметь такую же длину, что и полностью заполненный. Поэтому неразумно использовать слишком короткий archive_timeout - это быстро заполнит ваше архивное хранилище. archive_timeout со значением минута или что-то вроде того обычно наиболее разумный. Вы должны рассмотреть использование потоковой репликации вместо архивирования, если Вы хотите, чтобы ваши данные копировались с мастера на резервный сервер быстрее. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-80624696554055749562013-01-15T00:41:00.002-08:002013-01-15T00:41:50.428-08:0018.4. Потребление ресурсов<h2>
18.4.1 Память<a name='more'></a></h2>
<div>
<b>shared_buffers (integer)</b></div>
<div style="text-align: justify;">
Задаёт количество памяти, которую сервер БД использует для буферов разделяемой памяти. Значение по умолчанию, обычно, 32 мегабайта (32MB), но оно может быть и меньше, если ваши настройки ядра не поддерживают такой объём (определяется в процессе initdb). Значение должно быть не меньше 128 килобайт. (Значение не по умолчанию BLCKSZ изменяет минимальное значение.) В любом случае для хорошей производительности требуется обычно более высокое значение, чем минимальное. Этот параметр можно задать только при старте сервера.</div>
<div style="text-align: justify;">
Если у Вас выделенный сервер БД с более чем 1GB ОЗУ, хорошим начальным значением будет 25% доступной памяти. Бывают случаи, когда для эффективной работы требуется даже больше памяти, но, поскольку PostgreSQL так же полагается на кэш ОС, скорее всего выделение более 40% ОЗУ для shared_buffers не даст прироста производительности. Большие значения shared_buffers требуют соответствующего увеличения checkpoint_segments, для того, чтобы растянуть во времени запись большого количества новых или изменённых данных.</div>
<div style="text-align: justify;">
На системах с менее чем 1GB ОЗУ подходят меньшие значения, чтобы было достаточно места для Ос. Кроме того, на Windows большие значения shared_buffers не будут эффективными. Более полезным может оказаться сохранение этой настройки небольшой, но зато увеличив используемый ОС кэш. На Windows полезными значениями могут оказаться значения от 64MB до 512MB.</div>
<div style="text-align: justify;">
Увеличение этого значения может привести к тому, что PostgreSQL потребует больше разделяемой памяти System V, чем позволяет конфигурация вашей системы. Более подробно об этом сказано в <a href="http://postgresql-lab.blogspot.ru/2013/01/174.html" target="_blank">разделе 17.4.1</a></div>
<div style="text-align: justify;">
<b>temp_buffers (integer)</b></div>
<div style="text-align: justify;">
Задаёт максимальное количество временных буферов, используемых для каждой сессии БД. Эти "сессионные" настройки используются только для доступа к временным таблицам. Значение по умолчанию - 8MB. Это значение может быть изменено в каждой сессии, но только до перед первым использованием временной таблицы в пределах сессии; последующие попытки изменить это значение не повлияют на текущую сессию.</div>
<div style="text-align: justify;">
Сессия выделяет временные буферы по мере их потребления до достижения лимита, заданного temp_buffers. Стоимость увеличения этого лимита временных буферов для сессии, которой не требуется много буферов, заключается лишь дескрипторе буфера, или где-то 64 байта на одно увеличение (видимо, на один буфер - примечание переводчика). Но, если буфер используется, то требуется ещё 8192 байта (или, в общем, BLCKSZ байт).</div>
<div style="text-align: justify;">
<b>max_prepared_transactions (integer)</b></div>
<div style="text-align: justify;">
Задаёт максимальное число транзакций, которые могут одновременно находиться в состоянии "подготовленные" (см <a href="http://postgresql-lab.blogspot.com/2013/01/prepare-transaction.html" target="_blank">PREPARE TRANSACTION</a>). Значение 0 (по умолчанию) отключает возможности создания подготовленных транзакций. Этот параметр можно установить только при запуске сервера.</div>
<div style="text-align: justify;">
Если Вы не планируете использовать подготовленные транзакции, то стоит отключить эту возможность, чтобы исключить возможность их случайного создания. Если же Вы их используете, То max_prepared_transactions скорее всего Вы захотите установить не меньше, чем <a href="http://postgresql-lab.blogspot.ru/2013/01/183.html" target="_blank">max_connections</a>, так чтобы в каждой сессии могла быть такая транзакция.</div>
<div style="text-align: justify;">
Увеличение этого параметра может привести к росту потребностей PostgreSQL в разделяемой памяти System V. Для увеличения лимитов вашей системы обращайтесь к <a href="http://postgresql-lab.blogspot.ru/2013/01/174.html" target="_blank">разделу 17.4.1</a></div>
<div style="text-align: justify;">
На резервном сервере этот параметр должен быть не меньше, чем на мастере. Иначе запросы к нему не будут обрабатываться.</div>
<div style="text-align: justify;">
<i>(Из postgresql.conf:</i></div>
<i># Внимание: Увеличение max_prepared_transactions стоит ~600 bytes разделяемой памяти<br /># на слот транзакции + пространство блокировки (см max_locks_per_transaction).</i><div>
<i>)</i><br /><div>
<b style="text-align: justify;">work_mem (integer)</b></div>
<div style="text-align: justify;">
Определяет количество памяти, используемое для внутренних операций сортировки и хеш-таблиц перед их записью во временные файлы. По умолчанию - 1Mb. Имейте ввиду, что для в сложных запросах несколько операций сортировки или хеширования могут быть запущены параллельно; каждая из этих операций сможет использовать указанный тут объём памяти перед записью данных во временные файлы. Запущенные сессии так же могут выполнять эти операции одновременно. Поэтому общее количество используемой памяти может быть в несколько раз больше, чем work_mem; необходимо помнить об этом, устанавливая это значение. Операции сортировки используются командами ORDER BY, DISTINCT и при объединении слиянием. Хэш таблицы используются в hash join, hash-based aggregation и hash-based обработкой IN подзапросов.</div>
<div style="text-align: justify;">
<b>maintenance_work_mem (integer)</b></div>
<div style="text-align: justify;">
Определяет максимальное количество памяти, используемое для операций обслуживания, такие как VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. По умолчанию - 16MB. Так как только одна такая операция может выполняться в одно время в сессии БД и редко параллельно будет выполняться несколько таких операций, можно поставить этому параметру достаточно большое значение, больше чем work_mem. Большие значения могут увеличить производительность операций vacuum и восстановления дампов БД.</div>
<div style="text-align: justify;">
Обратите внимание, что когда запускается autovacuum, то может потребоваться до <a href="http://postgresql-lab.blogspot.com/2013/01/1810-automatic-vacuuming.html" target="_blank">autovacuum_max_worker</a> раз такого количества памяти, так что не задавайте это значение слишком большим.</div>
<div style="text-align: justify;">
<b>max_stack_depth (integer)</b></div>
<div style="text-align: justify;">
Определяет максимальную безопасную глубину стека выполнения сервера (server's execution stack). Идеальным значением этого параметра будет текущий лимит раздела стека, предоставляемый ядром (устанавливаемый через ulimit -s или что-то эквивалентное), менее безопасно - мегабайт или что-то вроде этого. Безопасное значение требуется поскольку глубина стека не проверяется в каждой процедуре на сервере, за исключением потенциальных рекурсивных процедур. Значение по умолчанию - 2MB, достаточно маленькое и при этом скорее всего не приводящее к падениям сервера. Однако оно может быть мало для выполнения сложных функций. Только суперпользователь может изменить эту настройку.</div>
<div style="text-align: justify;">
Установка max_stack_depth больше, чем лимит ядра будет означать, что запуск рекурсивной функции может привести к краху конкретного серверного процесса. На платформах, где PostgreSQL может определить лимит ядра, сервер не позволит использовать такое небезопасное значение. Однако не все платформы предоставляют такую возможность, так что будьте осторожны.</div>
<h2>
18.4.2 Использование ресурсов ядра</h2>
<div style="text-align: justify;">
max_files_per_process (integer)</div>
<div style="text-align: justify;">
Задаёт максимальное число одновременно отрытых файлов для каждого серверного процесса. Значение по умолчанию - 1000. Если ядро принудительно само устанавливает такой лимит, то Вам вообще не надо об этом беспокоиться. Но на некоторых платформах (особенно на большинстве BSD систем) ядро позволит отдельному процессу открыть больше файлов, чем поддерживает сама система, если несколько процессов попытаются открыть такое количество файлов. Если Вы столкнулись с ошибкой "Too many open files", попробуйте уменьшить значение этого параметра. Его можно задать только при старте сервера.</div>
<div style="text-align: justify;">
<b>shared_preload_libraries (string)</b></div>
<div style="text-align: justify;">
Эта строка определяет библиотеки, которые должны быть загружены <i>при</i> старте сервера. Например, значение '$libdir/mylib' приведёт к тому, что mylib.so (или, на некоторых платформах, mylib.sl) будет загружен из стандартного каталога установки. Все имена библиотек переводятся в нижний регистр, если они не заключены в двойные кавычки. Если требуется загрузить несколько библиотек, разделите их имена запятыми. Этот параметр может быть задан только при запуске сервера.</div>
<div style="text-align: justify;">
Таким образом могут быть загружены библиотеки процедурного языка PostgreSQL, обычно это что-то вроде '$libdir/plXXX', где XXX - зпыйдб perl, tcl или python.</div>
<div style="text-align: justify;">
Предварительная загрузка библиотеки позволяет избежать затрат времени на загрузку библиотеки, когда она понадобится. С другой стороны, время запуска каждого нового серверного процесса может незначительно увеличиться, даже если этот процесс и не будет использовать эту библиотеку. Так что этот параметр рекомендуется для библиотек, которые используются в большинстве случаев.</div>
<div style="text-align: justify;">
<i>Примечание: </i>на Windows предварительная загрузка библиотек не сокращает время на запукс каждого нового процесса; каждый процесс будет заново загружать все библиотеки. Всё же shared_preload_libraries полезна и на Windows, так как некоторым библиотекам может требоваться выполнить какие-то действия при запуске сервера (например, библиотеке может потребоваться зарезервировать лёгкие блокировки или разделяемую память, что нельзя сделать после старта сервера).</div>
<div style="text-align: justify;">
Если указанную библиотеку не удаётся найти, сервер не запускается.</div>
<div style="text-align: justify;">
Каждая PostgreSQL-поддерживаемая библиотека имеет "волшебный блок", который проверяется в целях проверки совместимости. Поэтому не-PostgreSQL библиотеки не могут быть загружены таким способом.</div>
<h2>
18.4.3 Задержка vacuum на основе подсчёта нагрузки</h2>
<div style="text-align: justify;">
В процессе выполнения команд <a href="http://postgresql-lab.blogspot.com/2013/01/vacuum.html" target="_blank">VACUUM</a> и <a href="http://postgresql-lab.blogspot.com/2013/01/analyze.html" target="_blank">ANALYZE</a> система работает с внутренним счётчиком, который подсчитывает затраты на различные произведённые операции ввода / вывода. Когда этот счётчик достигает предела (определённого в vacuum_cost_limit), процесс, выполняющий операции, засыпает на короткий период времени, заданный в vacuum_cost_delay. После чего счётчик сбрасывается и всё начинается заново.</div>
<div style="text-align: justify;">
Цель этот - позволить администратору сократить влияние этих команд на текущую работу с БД. Есть много случаев, когда нет необходимости в скорейшем завершении команд типа VACUUM и ANALYZE; однако обычно крайне важно, чтобы они по минимуму влияли на производительность БД. Задержка vacuum на основе подсчёта нагрузки позволяет администратору добиться этого.</div>
<div style="text-align: justify;">
По умолчанию эта возможность отключена для команд VACUUM, запускаемых вручную. Для того, чтобы включить эту возможность, задайте vacuum_cost_delay ненулевое значение.</div>
<div style="text-align: justify;">
<b>vacuum_cost_delay (integer)</b></div>
<div style="text-align: justify;">
Интервал времени, в миллисекундах, на который процесс заснёт при достижении лимита затрат. Значение по умолчанию - 0, то есть такая функциональность вообще отключена. Положительное значение активирует эту возможность. Помните, что на многих системах разрешение этого параметра - 10 миллисекунд; установка в качестве значения числа, которое не делится на 10 может иметь тот же эффект, что и ближайшее большее число, кратное 10.</div>
<div style="text-align: justify;">
Эффективным чаще всего являются небольшие значения, порядка 10-20 миллисекунд. Сглаживание потребления ресурсов лучше регулируется другими параметрами.</div>
<div style="text-align: justify;">
<b>vacuum_cost_page_hit (integer)</b></div>
<div style="text-align: justify;">
Ориентировочная стоимость очистки буфера, находящегося в общем буфере кеша. Представляет из себя затраты на блокировку буферного пула, просмотра общей хеш таблицы и сканирования содержимого страницы. Значение по умолчанию - 1.</div>
<div style="text-align: justify;">
<b>vacuum_cost_page_miss (integer)</b></div>
<div style="text-align: justify;">
Ориентировочная стоимость очистки буфера, который должен быть считан с диска. Представляет из себя затраты на блокировку буферного пула, просмотра общей хеш таблицы, считывания желаемого блока с диска и сканирования содержимого страницы. Значение по умолчанию - 10.</div>
<div style="text-align: justify;">
<b>vacuum_cost_page_dirty (integer)</b></div>
<div style="text-align: justify;">
Ориентировочная стоимость изменения vacuum'ом блока, который уже был очищен. Представляет из себя дополнительные затраты ввода / вывода, необходимые для сброса чистого блока на диск. Значение по умолчанию - 20.</div>
<div style="text-align: justify;">
<b>vacuum_cost_limit (integer)</b></div>
<div style="text-align: justify;">
Суммарная стоимость при достижении которой процесс очистки засыпает. Значение по умолчанию - 200.</div>
<div style="text-align: justify;">
<i>Примечание:</i> Есть некоторые операции, которые держат критическую блокировку и потому должны завершиться как можно быстрее. Во время таких операций засыпания не происходит. По этой причине может получиться, что суммарная стоимость будет на каком-то этапе значительно больше, чем установленный лимит. Для того, чтобы избежать в таком случае длительных пауз, реальная задержка рассчитывается как vacuum_cost_delay * accumulated_balance / vacuum_cost_limit c максимумом vacuum_cost_delay * 4.</div>
<h2>
18.4.4 Background writer</h2>
<div style="text-align: justify;">
Есть отдельный серверный процесс, называемый background writer, чьей функцией является запись "грязных" (новых или изменённых) общих буферов. Он записывает общие буферы так, что серверным процессам, обрабатывающим запросы пользователей редко, или даже никогда не приходится ожидать этой записи. Однако background writer увеличивает общую нагрузку ввода / вывода, так как, хотя страница, становящаяся "грязной" несколько раз подряд, была бы иначе записана только один раз за интервал чекпойнта, background writer может записать её за этот интервал несколько раз (каждый раз, как она становится "грязной"). Параметры, описанные в этом разделе, могут быть использованы для настройки его поведения.</div>
<div style="text-align: justify;">
<b>bgwriter_delay (integer)</b></div>
<div style="text-align: justify;">
Определяет паузу между циклами активности background writer. В каждом цикле writer обслуживает некоторое количество "грязных" буферов (определяемое в других параметрах). После этого он засыпает на bgwriter_delaymilliseconds и всё начинается заново. Установка в качестве значения числа, которое не делится на 10 может иметь тот же эффект, что и ближайшее большее число, кратное 10. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
<b>bgwriter_lru_maxpages (integer)</b></div>
<div style="text-align: justify;">
В каждом цикле не больше, чем это количество буферов может быть записано background writer'oм. Если установить в качестве значения 0, то background writer не будет записывать буферы, кроме как во веремя чекпойнтов. Значение по умолчанию - 100 буферов. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
<b>bgwriter_lru_multipler (floating point)</b></div>
<div style="text-align: justify;">
Число "грязных" буферов, которые записываются в каждом цикле основывается на числе новых буферов, которые потребовались серверному процессу в последних циклах. Среднее количество недавно требовавшихся буферов умножается на bgwriter_lru_multiplier, в результате чего получается число буферов, которые потребуются в следующем цикле. "Грязные" буферы записываются до тех пор, пока число чистых, повторно используемых буферов не достигает нужного количества. (Но, в любом случае, будет записано не больше чем bgwriter_lru_maxpages буферов за цикл.) Таким образом, значение 1.0 означает подход "just in time", когда будет записано ровно столько буферов, сколько предположительно потребуется. Большие значения обеспечивают некий запас прочности на случай всплесков, тогда как меньшие означают, что мы намеренно оставляем запись на совесть серверных процессов. Значение по умолчанию - 2.0. Этот параметр может быть задан либо в postgresql.conf, либо в командной строке.</div>
<div style="text-align: justify;">
Небольшие значения bgwriter_lru_maxpages и bgwriter_lru_multiplier сокращают дополнительную нагрузку от background writer, но приводят к тому, что скорее всего запись придётся производить серверным процессам, откладывая выполнение пользовательских запросов.</div>
<h2>
18.4.5 Асинхронное поведение</h2>
<div style="text-align: justify;">
<b>effective_io_concurrency (integer)</b></div>
<div style="text-align: justify;">
Задаёт число операций ввода / вывода, которые, как PostgreSQL ожидает, будут выполняться одновременно. Увеличение этого значения увеличивает число операций ввода/вывода, которые одна сессия PostgreSQL будет пытаться провести параллельно. Допустимые значения - от 1 до 1000, или 0 для того, чтобы отключить асинхронные запросы ввода/вывода. На данный момент эта настройка влияет только на bitmap heap scans.</div>
<div style="text-align: justify;">
Хорошим началом для этой настройки будет число дисков, объединённых в RAID 0 или 1, которые используются для БД. (Для RAID 5 не надо учитывать диск чётности). Однако, если база данных часто занята несколькими запросами в параллельных сессиях, более низкие значения может хватить, чтобы занять дисковый массив. Значение выше, чем необходимо для загрузки дисков работой, приведет к дополнительной загрузки процессора.</div>
<div style="text-align: justify;">
Для более экзотических систем, таких как хранилища в ОЗУ или RAID массивы с ограничением по шине, правильным значением может быть число доступных путей ввода/вывода. Для поиска лучшего значения может потребоваться провести несколько тестов.</div>
<div style="text-align: justify;">
Асинхронный ввод/вывод зависит от эффективного функционирования posix_fadvise, а в этом деле не все йогурты одинаково полезны. Если эта функция отсутствует в системе, то установка значения, отличного от 0 приведёт к ошибке. На некоторых ОС (например, Solaris), функция присутствует, но ничего не делает.</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com1tag:blogger.com,1999:blog-3495458762343321167.post-88914203741022533862013-01-13T02:09:00.001-08:002013-01-13T02:09:40.290-08:0018.3. Подключения и аутентификация<h3>
18.3.1 Настройки подключения<a name='more'></a></h3>
<div>
<b>listen_addresses (string)</b></div>
<div style="text-align: justify;">
Определяет TCP/IP адрес(а) на которых сервер ожидает подключения клиентов. Эти значения указываются в строкой с точкой с запятой в качестве разделителя. Можно указать как имена, так и IP адреса. * обозначает все доступные IP интерфейсы. 0.0.0.0 разрешает слушать все IPv4, а :: все IPv6 адреса. Если список пустой, то сервер не будет ждать подключения ни на каком IP интерфейсе; в таком случае для подключения можно использовать только Unix domain socket. Значением по умолчанию является только "localhost", что разрешает только TCP/IP loopback подключения. Хотя настройки аутентификации клиента (<a href="http://postgresql-lab.blogspot.ru/search/label/%D0%B3%D0%BB%D0%B0%D0%B2%D0%B0%2019" target="_blank">глава 19</a>) позволяет тонко настроить разрешения подключения к серверу, listen_addresses определяет доступные для использования интерфейсов, что может помочь предотвратить повторяющиеся повторные подключения злоумышленника к небезопасным сетевым интерфейсам. Этот параметр можно задать только при запуске сервера.</div>
<div style="text-align: justify;">
<b>port (integer)</b></div>
<div style="text-align: justify;">
Сервер по умолчанию слушает порт 5432. Обратите внимание, что этот порт используется на всех IP адресах. Этот параметр может быть задан только при запуске сервера.</div>
<div style="text-align: justify;">
<b>max_connections (integer)</b></div>
<div style="text-align: justify;">
Определяет максимальное количество одновременных подключений к серверу БД. По умолчанию разрешено 100 подключений, но их число может быть меньше, в зависимости от поддержки ядра (это определяется во время initdb). Параметр может быть задан только вовремя запуска сервера.</div>
<div style="text-align: justify;">
Увеличение числа подключений может потребовать большего объёма разделяемой памяти или семафоров, чем позволяют настройки вашей ОС. Подробнее об этом говорится в <a href="http://postgresql-lab.blogspot.ru/2013/01/174.html" target="_blank">разделе 17.4.1</a>.</div>
<div style="text-align: justify;">
Когда Вы запускаете резервный сервер, Вы должны разрешить то же количество подключений или больше, чем на мастере. В противном случае запросы к нему не смогут быть обработаны.</div>
<div style="text-align: justify;">
<b>superuser_reserved_connections (integer)</b></div>
<div style="text-align: justify;">
Определяет число "слотов" подключений, которые зарезервированы для подключений суперпользователями PostgreSQL. Максимум max_connections подключений может быть активно одновременно. Когда же число активных подключений достигает max_connections - superuser_reserved_connections, новые подключения будут возможны только для суперпользователя; новые подключения для репликации не будут приняты.</div>
<div style="text-align: justify;">
Значение по умолчанию - 3. Это число должно быть меньше, чем max_connections. Этот параметр можно задать только при запуске сервера.</div>
<div style="text-align: justify;">
<b>unix_socket_directory (string)</b></div>
<div style="text-align: justify;">
Определяет каталог Unix-domain socket, где сервер будет ожидать подключений от клиентских приложений. Значение по умолчанию - /tmp, но оно может быть изменено на этапе сборки. Этот параметр можно задать только при запуске сервера.</div>
<div style="text-align: justify;">
Кроме самого файла сокета, который называется .s.PGSQL.<i>nnnn,</i> где <i>nnnn</i> - номер порта сервера, ещё создаётся обычный файл с именем .s.PGSQL.<i>nnnn.</i>lock<i>. </i>Ни один из этих файлов не должен быть вручную удалён.</div>
<div style="text-align: justify;">
Этот параметр не используется на Windwos, так как там нет Unix=domain socket.</div>
<div style="text-align: justify;">
<b>unix_socket_group (string)</b></div>
<div style="text-align: justify;">
Задаёт владельца группы Unix-domain socket. (Владельцем самого сокета всегда является пользователь, который запускает сервер.) Вместе с параметром unix_socket_permissions он может использоваться как дополнительный механизм контроля подключений через unix-domain socket. По умолчанию значение этого параметра - пустая строка, что означает группу по умолчанию для пользователя сервера. Этот параметр можно задать только при запуске сервера.</div>
<div style="text-align: justify;">
Этот параметр не используется на Windwos, так как там нет Unix=domain socket.</div>
<div style="text-align: justify;">
<b>unix_socket_permissions (integer)</b></div>
<div style="text-align: justify;">
Задаёт права доступа к unix-domain socket, которые используют обычный механизм прав доступа к файлам. В качестве параметра ожидается число, которое задаёт формат доступа к файлу, используемое командами chmod и umask. (Для того, чтобы использовать восьмеричный формат ввода число должно начинаться с нуля (0)).</div>
<div style="text-align: justify;">
Значение по умолчанию - 0777, что подразумевает, что любой может подключиться к сокету. Логичным значением так же может быть 0770 (разрешение подключения только владельцу файла и группе, см unix_socket_group) и 0700 (разрешение подключения только пользователю). (Обратите внимание, что для unix-domain socket важны разрешения только на запись, так что нет никакого смысла задавать или снимать разрешения на выполнение или чтение).</div>
<div style="text-align: justify;">
Этот способ контроля доступа не зависит от описанного в <a href="http://postgresql-lab.blogspot.ru/search/label/%D0%B3%D0%BB%D0%B0%D0%B2%D0%B0%2019" target="_blank">главе 19</a>.</div>
<div style="text-align: justify;">
<div>
Этот параметр можно задать только при запуске сервера.</div>
<div>
Этот параметр не используется на Windwos, так как там нет Unix=domain socket.</div>
<div>
<b>bonjour (boolean)</b></div>
<div>
Включает объявление о существовании сервера через Bonjour. По умолчанию - off. Этот параметр может быть задан только при запуске сервера.</div>
<div>
<b>bonjour_name (string)</b></div>
<div>
Определяет имя Bonjour сервиса. Если в качестве параметра задана пустая строка (значение по умолчанию), то используется имя компьютера. Параметр игнорируется если сервер не был скомпилирован с поддержкой bonjour. Этот параметр может быть задан только при старте сервера.</div>
<div>
<b>tcp_keepalives_idle (integer)</b></div>
<div>
Определяет количество секунд до отправки пакета keepalive по бездействующему каналу. Значение 0 использует системное значение. Этот параметр поддерживается только на системах, поддерживающих символы TCP_KEEPIDLE или TCP_KEEPALIVE и на Windows; на других системах это значение должно быть равно 0. Этот параметр игнорируется, если подключение происходит через unix-domain socket.</div>
<div>
<i>Примечание:</i> на Windows значение 0 будет означать 2 часа, так как на Windows нет возможности прочитать системное значение.</div>
<div>
<b>tcp_keepalives_interval (integer)</b></div>
<div>
Определяет количество секунд между отправкой keepalive по бездействующему соединению. Значение 0 использует системное значение. Этот параметр поддерживается только на системах, поддерживающих символ TCP_KEEPINTVL и на Windows; на других системах это значение должно быть равно 0. Этот параметр игнорируется, если подключение происходит через unix-domain socket.</div>
<div>
<i>Примечание:</i> на Windows значение 0 будет означать 1 секунду, так как на Windows нет возможности прочитать системное значение.</div>
<div>
<b>tcp_keepalives_count (integer)</b></div>
<div>
Определяет количество пакетов keepalive, отправляемых по бездействующему соединению. Значение 0 использует системное значение. Этот параметр поддерживается только на системах, поддерживающих символ TCP_KEEPCONT; на других системах это значение должно быть равно 0. Этот параметр игнорируется, если подключение происходит через unix-domain socket.</div>
<div>
<i>Примечание:</i> этот параметр не поддерживается на Windows и должен быть равен 0.</div>
<h2>
18.3.2 Безопасность и аутентификация</h2>
<div>
<b>authentication_timeout (integer)</b></div>
<div>
Максимальное время для завершения аутентификации клиента в секундах. Если потенциальный клиент за это время не завершил протокол аутентификации, то сервер завершает соединения. Это не позволяет зависшим клиентам занимать соединение. Значение по умолчанию - 1 минута (1m). Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке.</div>
<div>
<b>ssl(boolean)</b></div>
<div>
Разрешает SSL соединения. Перед использованием прочитайте <a href="http://postgresql-lab.blogspot.ru/2013/01/179-tcpip-ssl.html" target="_blank">раздел 17.9</a>. По умолчанию - off. Этот параметр может быть задан только при запуске сервера. SSL соединения возможны только через TCP/IP соединения.</div>
<div>
<b>ssl_renogotiation_limit (integer)</b></div>
<div>
Определяет как много данных может быть передано по SSL-шифрованному соединения перед повторным обменом ключами. Повторный обмен ключами снижает шансы атакующего провести криптоанализ на большом объёме переданных данных, но так же и снижает производительность. В качестве лимита используется сумма переданных и полученных данных. Если этот параметр равен 0, то повторный обмен ключами не происходит. Значение по умолчанию - 512MB.</div>
<div>
<i>Примечание:</i> SSL библиотеки до ноября 2009 небезопасны при использовании обмена ключами SSL из-за уязвимости в SSL протоколе. В качестве решения этой проблемы некоторые поставщики предоставляют SSL библиотеки, не способные на обмен ключами. Если такие библиотеки есть на клиенте или сервере, то обмен ключами должен быть отключен.</div>
<div>
<b>ssl_ciphers (string)</b></div>
<div>
Определяет список SSL шифров, которые можно использовать для безопасных подключений. В руководстве по openssl приведён список доступных шифров.</div>
<div>
<b>password_encryption (boolean)</b></div>
<div>
Когда пароль определён в <a href="http://postgresql-lab.blogspot.com/2013/01/create-user.html" target="_blank">CREATE USER</a> или <a href="http://postgresql-lab.blogspot.com/2013/01/alter-role.html" target="_blank">ALTER ROLE</a> без ENCRYPTED или UNENCRYPTED, то этот параметр определяет, должне ли пароль быть зашифрован. По умаолчанию - on (пароль шифруется).</div>
<div>
<b>krb_server_keyfile (string)</b></div>
<div>
Задаёт расположение файла ключа сервера Kerberos. Более подробно об этом написано в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделах 19.3.5. или 19.3.3</a>. Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке.</div>
<div>
<b>krb_srvname (string)</b></div>
<div>
Задаёт имя сервиса Kerberos. Более подробно - в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.5</a>. Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке.</div>
<div>
<b>krb_caseins_users (boolean)</b></div>
<div>
Определяет, надо ли рассматривать имена пользователей Kerberos и GSSAPI как регистрозависимые. По умолчанию - off (не зависят от регистра). Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке.</div>
<div>
<b>db_user_namespace (boolean)</b></div>
<div>
Этот параметр разрешает использовать отдельные пространства имён пользователей для каждой БД. По умолчанию off. Этот параметр может быть задан либо в файле postgresql.conf, либо в командной строке.</div>
<div>
Если он активирован, то Вы должны создавать пользователя в виде имя_пользователя@имя_базы_данных. Когда при подключении передаётся имя пользователя,к нему присоединяют @ и имя базы данных, полученное в результате имя пользователя рассматривается сервером. Обратите внимание, что когда Вы создаёте пользователя с именем, содержащим @ в SQL окружении, Вы должны поместить имя пользователя в кавычки.</div>
<div>
Если Вы используете этот параметр, Вы всё ещё можете создавать обычных, глобальных пользователей. Для этого просто добавьте @ к имени клиента, например joe@. Знак @ будет отброшен при поиске пользователя.</div>
<div>
db_user_namespace приводит к тому, что имена пользователя на клиенте и сервере будут отличаться. Аутентификация всегда проводится с именем пользователя на сервере, так что метод аутентификации должен быть настроен на имя пользователя на сервере, не на клиенте. Так как md5 использует имя пользователя в качестве соли как на клиенте, так и на сервере, md5 не может быть использован при db_user_namespace.</div>
<div>
<i>Примечание:</i> Эта опция используется в качестве временного решения. Когда будет найдено окончательное решение, опция будет удалена.</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-36337517215184786642013-01-10T07:20:00.001-08:002013-01-10T07:21:07.371-08:0018.2. Расположение файлов<br />
<div style="text-align: justify;">
Кроме конфигурационного файла postgresql.conf, о котором мы уже говорили, PostgreSQL использует два других конфигурационных файла, редактируемых вручную, отвечающих за аутентификацию клиента (они обсуждаются в <a href="http://postgresql-lab.blogspot.ru/search/label/%D0%B3%D0%BB%D0%B0%D0%B2%D0%B0%2019" target="_blank">главе 19)</a>. По умолчанию все три конфигурационных файла хранятся в каталоге с данными. Параметры, описанные в этом разделе позволяют расположить эти файлы где-либо в другом месте. (Это может облегчить администрирование сервера. В частности зачастую гораздо проще убедиться что сделана резервнвая копия конфигурационных файлов если они хранятся отдельно от остальных данных).</div>
<div style="text-align: justify;">
<b>data_directory (string)</b></div>
<div style="text-align: justify;">
Определяет каталог, используемый для хранения данных. Этот параметр может быть определён только при запуске сервера</div>
<div style="text-align: justify;">
<b>config_file (string)</b></div>
<div style="text-align: justify;">
Определяет главный конфигурационный файл сервера (обычно называемый postgresql.conf). Этот параметр может быть определён только как аргумент командной строки</div>
<div style="text-align: justify;">
<b>hba_file (string)</b></div>
<div style="text-align: justify;">
Определяет конфигурационный файл для аутентификации на основе хостов (обычно называемый pg_hba.conf). Этот параметр может быть задан только при запуске сервера.</div>
<div style="text-align: justify;">
<b>ident_file (string)</b></div>
<div style="text-align: justify;">
Определяет конфигурационный файл для карт имён пользователей, обсуждаемых в <a href="http://postgresql-lab.blogspot.com/2013/01/192-user-name-maps.html" target="_blank">разделе 19.2</a> (обычно называемый pg_ident.conf). Этот параметр может быть задан только при запуске сервера.</div>
<div style="text-align: justify;">
<b>external_pid_file (string)</b></div>
<div style="text-align: justify;">
Определяет имя дополнительного PID (process-ID) файла, который сервер должен создать для использования программы управления сервером. Этот параметр может быть задан только при запуске сервера.</div>
<div style="text-align: justify;">
В установке по умолчанию ни один из этих параметров не задан явно. Вместо этого все файлы ищутся в каталоге с данными, который определяется либо через параметр -D командной строки, либо через переменную окружения PGDATA.</div>
<div style="text-align: justify;">
Если Вы хотите хранить конфигурационные файлы где-то в другом месте, то -D или PGDATA должны указывать место хранения конфигурационных файлов, а параметр data_directory в postgresql.conf (или в командной строке) должен указывать каталог с данными. Обратите внимание, что data_directory переопределяет -D и PGDATA в поиске данных, но не в поиске файлов настроек.</div>
<div style="text-align: justify;">
Если Вы хотите, то Вы можете задать свои имена файлов конфигурации при помощи параметров config_file, hba_file и / или ident_file. config_file может быть определён только в командной строке, но другие имена могут быть обозначены в главном конфигурационном файле. Если явно заданы все три параметра и data_directory, то тогда вообще можно обойтись без -D или PGDATA.</div>
<div style="text-align: justify;">
Указанный в отношении этих параметров относительный путь будет использован относительно места запуска postgres.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-46004429456560404282013-01-10T02:00:00.001-08:002013-01-10T06:26:08.312-08:0018.1. Настройка параметров<span style="text-align: justify;">Все имена параметров чувствительны к регистру. Каждый параметр принимает значение одного из пяти типов: boolean, integer, floating point, string или enum. Логические (boolean) значения могут быть заданы как on, off, true, false, yes, no, 1, 0 (вне зависимости от региста) или как их однозначное сокращение.</span><br />
<a name='more'></a><br />
<div style="text-align: justify;">
Некоторые настройки определяют значения памяти или времени. Каждая из них имеет свою единицу измерения: килобайты, блоки (обычно это 8 килобайт), миллисекунды, секунды или минуты. Единицы измерения по умолчанию можно увидеть в pg_settings.unit. Для удобства единицу измерения можно и явно указать. Допустимые значения объёмов памяти - kB (килобайты), MB (мегабайты), GB (гигабайты); для времени - ms (миллисекунды), s (секунды), min (минуты), h (часы) и d (дни). Обратите внимание, что для памяти используется множитель 1024, не 1000.</div>
<div style="text-align: justify;">
Параметр типа enum определяется так же, как и строковый параметр, но его доступные значения ограничены набором значений. Допустимые значения перечислены в pg_settings.enumvals. Эти параметры не зависят от регистра.</div>
<div style="text-align: justify;">
Один из способов задать эти параметры - отредактировать файл postgresql.conf, который скорее всего находится в каталоге с данными (Копия со значениями по умолчанию устанавливается при инициализации кластера БД). Вот как этот файл может выглядеть:<br />
# Комментарий<br />
log_connections = yes<br />
log_destination = 'syslog'<br />
search_path = '"$user", public'<br />
shared_buffers = 128MB<br />
На строке можно указать только один параметр. Знак равенства между именем параметра и значением не обязателен. Пробелы не важны, пустые строки игнорируются. # помечает остаток строки как комментарий. Значения параметров, которые не являются простым идентификатором или числом, должны быть заключены в одинарные кавычки. Для того, чтобы добавить к значению параметра одинарную кавычку используйте либо двойную кавычку (предпочтительнее), либо экранируйте обратным слешом.<br />
Кроме настроек файл postgresql.conf может содержать <i>директивы include</i>, указывающие, что надо прочитать другой файл и обработать его, как если бы его содержимое находилось в этом месте файла настроек. Эти директивы выглядят очень просто:<br />
include 'filename'<br />
Если указан не абсолютный путь, то он вычисляется относительно каталога, содержащего ссылающийся конфигурационный файл. Включения могут быть вложенными.<br />
Конфигурационный файл перечитывается когда главный процесс сервера получает сигнал SIGHUP (который проще всего послать при помощи pg_ctl reload). Основной серверный процесс распространит этот сигнал на все запущенные процессы сервера так что все существующие сессии тоже получат новые значения. Кроме того, Вы можете послать сигнал определённому процессу напрямую. Некоторые параметры можно изменить только при запуске сервера, до перезагрузки будут использоваться их старые значения.<br />
Другой способ задать параметры конфигурации - передать их в качестве аргументы командной строки команду postgres:<br />
postgres -c log_connections=yes -c log_destination='syslog'<br />
В таком случае переданные значения переопределят конфликтующие настройки из postgresql.conf. Обратите внимание, что в таком случае Вы не сможете изменить эти значения "на лету" редактируя postgresql.conf, так что хоть это и более удобный метод, он не очень гибкий.<br />
Иногда бывает полезно использовать аргументы командной строки только для одной сессии. Переменная окружения PGOPTIONS на стороне клиента может быть использована для этого:<br />
env PGOPTIONS='-c geqo=off' psql<br />
(Такой метод работает для всех клиентских приложений, основанных на libpq, не только psql.) Обратите внимание, что этот метод не будет работать для параметров, определённых при запуске сервера или в postgresql.conf.<br />
Более того, можно привязать набор параметров к пользователю или БД. Команды ALTER <a href="http://postgresql-lab.blogspot.com/2013/01/alter-role.html" target="_blank">ROLE</a> и ALTER <a href="http://postgresql-lab.blogspot.com/2013/01/alter-database.html" target="_blank">DATABASE</a> соответственно используются для такой настройки. Настройки БД переопределяют все настройки командной строки и конфигурационного файла, но, в свою очередь, могут быть переопределены настройками для пользователя. Оба эти варианта переопределяются настройками сессии.<br />
Некоторые параметры могут быть изменены в конкретной SQL сессии при помощи команды <a href="http://postgresql-lab.blogspot.com/2013/01/set.html" target="_blank">SET</a>:<br />
SET ENABLE_SEQSCAN TO OFF;<br />
Если SET разрешено использовать, то он переопределяет все остальные источники значений параметров. Некоторые параметры не могут быть заданы через SET, например, если эти параметры определяют поведение, которое может быть изменено только при перезапуске всего сервера. Кроме того команды SET и ALTER требуют прав суперпользователя.<br />
Команда <a href="http://postgresql-lab.blogspot.com/2013/01/show.html" target="_blank">SHOW</a> позволяет посмотреть текущие значения параметров.<br />
Виртуальная таблицы pg_settings так же позволяет посмотреть и изменить параметры текущей сессии; более подробно описание доступных настроек и их изменений приведено в <a href="http://postgresql-lab.blogspot.com/2013/01/4562-pgsettings.html" target="_blank">разделе 45.62</a>. pg_settings эквивалентно SHOW и SET, но может оказаться более удобной в использовании, так как она может быть объединена с другими таблицами и из неё можно выбирать элементы по условиям. Кроме того, она содержит больше информации о доступных значениях параметров.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-29786507060648720552013-01-08T01:54:00.002-08:002013-01-10T06:25:18.912-08:0017.10. Безопасные TCP/IP соединения при помощи SSHTunnels<br />
<div style="text-align: justify;">
Возможно использовать SSH для шифрования сетевых соединений между клиентом и сервером PostgreSQL. Если это сделано правильно, что мы поучаем адекватный уровень сетевой безопасности даже для клиентов, не поддерживающих SSL.<br />
<a name='more'></a></div>
<div style="text-align: justify;">
Для начала убедитесь, что SSH сервер работает на той же машине, что и сервер PostgreSQL и что Вы можете залогиниться на сервер при помощи ssh. После этого установите безопасный тунель с клиентской машины:</div>
<div style="text-align: justify;">
ssh -L 63333:localhost:5432 joe@foo.com</div>
<div style="text-align: justify;">
Первое число аргумента L - 63333 - номер порта на вашем конце туннеля; это может быть любой свободный порт (IANA резервирует порты с 49152 по 65535 для частного использования). Второе число, 5432 - это номер порта на удалённом конце тунеля, номер порта, который использует ваш сервер. Имя или IP адрес между номерами портов - это машина, на которой запущен сервер БД, как её адрес выглядит с машины, с которой Вы хотите подключиться, в нашем примере - с foo.com. Для того, чтобы подключиться к серверу БД при помощи туннеля, Вы должны использовать порт 63333 на локальной машине:</div>
<div style="text-align: justify;">
psql -h localhost -p 63333 postgres</div>
<div style="text-align: justify;">
Для сервера БД это будет выглядеть как будто Вы пользователь joe c хоста foo.com и подключаетесь к localhost и, соответственно, сервер будет использовать подходящие процедуры аутентификации для этого пользователя и этого хоста. Обратите внимание, что сервер не будет рассматривать соединение как SSL-шифрованное, так как оно не шифруется между SSH сервером и PostgreSQL. Это не должно понижать уровень безопасности, так как оба они находятся на одной машине.</div>
<div style="text-align: justify;">
Для того, чтобы туннель был создан, Вы должны разрешить подключения через ssh для joe@foo.com как если бы Вы использовали ssh для создания удалённой сессии.</div>
<div style="text-align: justify;">
Кроме того, Можно использовать перенаправление портов:</div>
<div style="text-align: justify;">
ssh -L 63333:foo.com:5432 joe@foo.com</div>
<div style="text-align: justify;">
но в таком случае сервер БД будет рассматривать соединение как приходящее с интерфейса foo.com, которое не открыто при настройках по умолчанию: listen_addresses = 'localhost'. Скорее всего это не то, что Вы бы хотели.</div>
<div style="text-align: justify;">
Если Вы должны "прыгнуть" на сервер БД через какой-то хост для логина, можно попробовать сделать так:</div>
<div style="text-align: justify;">
ssh -L 63333:db.foo.com:5432 joe@shell.foo.com</div>
<div style="text-align: justify;">
Обратите внимание, что в этом случае соединение с shell.foo.com на db.foo.com не будет зашифровано туннелем. SSH предоставляет и другие возможности настройки при сетевых ограничениях. Подробнее это описано в документации по SSH.</div>
<div style="text-align: justify;">
<b>Совет: </b>некоторые другие приложения могут предоставлять схожую функциональность</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-21024296887311648082013-01-08T01:03:00.002-08:002013-01-10T06:25:48.164-08:0017.9. Безопасные TCP/IP соединения посредством SSL<div style="text-align: justify;">
PostgreSQL поддерживает использование SSL соединений для шифрования общения клиент/сервер, обеспечивая более высокий уровень безопасности. Для этого требуется, чтобы OpenSSL был установлен как на клиенте, так и на сервере и чтобы поддержка SSL была включена в момент сборки PostgreSQL (см <a href="http://postgresql-lab.blogspot.com/2013/01/154-installation-procedure.html" target="_blank">главу 15</a>).<br />
<a name='more'></a></div>
<div style="text-align: justify;">
Со включённой поддержкой SSL PostgreSQL сервер может быть запущен с параметром, активирующем SSL. Для этого задайте значение <a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" target="_blank">ssl</a> равное on в postgresql.conf. Сервер будет слушать как нормальные, так и SSL подключения на одном и том же TCP порту и будет взаимодействовать с любыми клиентами, вне зависимости, использует ли он SSL. По умолчанию это зависит от настроек клиента; смотрите <a href="http://postgresql-lab.blogspot.com/2013/01/191-pghbaconf-file_7.html" target="_blank">раздел 19.1</a>, где говорится о том, как настроить сервер на приём SSL соединений ото всех пользователей или ото всех.</div>
<div style="text-align: justify;">
PostgreSQL считывает системные настройки файла конфигурации OpenSSL. По умолчанию это файл называется openssl.cnf и он расположен в каталоге, узнать который можно при помощи команды openssl version -d. Это значение по умолчанию может быть переопределено, задав имя файла настройки в качестве переменной окружения OPENSSL_CONF.</div>
<div style="text-align: justify;">
OpenSSL поддерживает широкий спектр алгоритмов шифрования и аутентификации разной степени надёжности. Хотя список шифров может быть определён в файлах настройки OpenSSL, Вы можете перечислить список доступных шифров для использования сервером изменив <a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" target="_blank">ssl_ciphers</a> в postgresq.conf.</div>
<div style="text-align: justify;">
<b>Примечание:</b> Возможно проводить аутентификацию без шифрования при помощи шифров NULL-SHA или NULL-MD5. Но в таком случае <a href="http://ru.wikipedia.org/wiki/%D0%A7%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA_%D0%BF%D0%BE%D1%81%D0%B5%D1%80%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5" target="_blank">MitM</a> может вмешаться в коммуникацию между клиентом и сервером. Кроме того, расходы на шифрование малы, по сравнению с накладными расходами на аутентификацию. По этим причинам использовать NULL шифры не рекомендуется.</div>
<div style="text-align: justify;">
Для того, чтобы начать режим SSL, файлы server.crt и server.key должны существовать с каталоге с данными сервера. Эти файлы должны содержать сертификат сервера и его закрытый ключ соответственно. На системах UNIX разрешения на server.key не должны разрешать доступ группе и остальным; этого можно добиться командой shmod 0600 server.key. Если закрытый ключ защищён паролем, то сервер запросит пароль и не запустится, пока его не получит.</div>
<div style="text-align: justify;">
В некоторых случаях сертификат сервера может быть подписан промежуточным центром сертификации, а не напрямую доверенным центром. Чтобы использовать этот сертификат, добавьте все промежуточные сертификаты вплоть до корневого центра сертификации к файлу server.crt. Корневой сертификат должен быть добавлен в server.crt в любом случае, если он содержит больше чем один сертификат.</div>
<h4>
17.9.1 Использование сертификата клиента</h4>
<div style="text-align: justify;">
Для того, чтобы клиент предоставил доверенный сертификат, разместите сертификат центров сертификации (СА), которым Вы доверяете, в файл root.crt в каталоге с данными и установите параметр hostssl соответствующего хоста в 1 в файле pg_hba.conf. В этом случае при установке SSL соединения у клиента будет запрошен сертификат. (В <a href="http://postgresql-lab.blogspot.com/2013/01/31.html" target="_blank">разделе 31.17</a> описано как установить сертификат на клиенте). Сервер проверит, что сертификат клиента подписан одним из доверенных центров сертификации. Кроме того, если присутствует файл root.crl, проверяется список отозванных сертификатов (CRL). (<a href="http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s02.html" target="_blank">Здесь</a> есть диаграмма, показывающая использование SSL сертификатов).</div>
<div style="text-align: justify;">
Опция clientcert в pg_hba.conf доступна для всех методов аутентификации, но только для строк, отмеченных как hostssl. Если clientcert не определён или равен 0, то сервер будет проверять клиентский сертификат при помощи root.crt, но не будет настаивать на предоставлении ему клиентом сертификата.</div>
<div style="text-align: justify;">
Обратите внимание, что список root.crt содержит корневые центры сертификации для подписи клиентских сертификатов; указывать там корневой сервер сертификации для сертификата сервера нет необходимости.</div>
<div style="text-align: justify;">
Если Вы настраиваете сертификаты клиентов, Вы можете захотеть использовать метод аутентификации cert, чтобы сертификаты использовались не только для обеспечения безопасности, но и для аутентификации клиента. Подробнее об этом написано в <a href="http://postgresql-lab.blogspot.com/2013/01/193-authentication-methods.html" target="_blank">разделе 19.3.10</a>.</div>
<h3>
17.9.2 Использование файлов SSL сервером</h3>
<div style="text-align: justify;">
Таблица 17-3 перечисляет файлы, относящиеся к настройке SSL на сервере.</div>
<div style="text-align: center;">
<b>Таблица 17-3 Использование файлов SSL сервером</b></div>
<table border="1"><thead>
<tr><th>Файл</th><th>Содержание</th><th>Использование</th></tr>
</thead><tbody>
<tr><td><tt>$PGDATA/server.crt</tt></td><td>сертификат сервера</td><td>посылается клиенту для идентификации сервера</td></tr>
<tr><td><tt>$PGDATA/server.key</tt></td><td>закрытый ключ сервера</td><td>подтверждает, что сертификат сервера был послан именно им; не подтвеждает доверенность владельца сертификата</td></tr>
<tr><td><tt>$PGDATA/root.crt</tt></td><td>сертификаты доверенных центров сертификации</td><td>проверяет, что сертификат клиента подписан одним из доверенных центров сертификации</td></tr>
<tr><td><tt>$PGDATA/root.crl</tt></td><td>сертификаты, отозванные центрами сертификации</td><td>сертификат клиента не должен быть здесь</td></tr>
</tbody></table>
<div style="text-align: justify;">
Файлы server.key, server.crt, root.crt и root.crl проверяются только при запуске сервера, так что при их изменении сервер должен быть перезапущен.<br />
<h3>
17.9.3 Создание самозаверенного сертификата</h3>
Для того, чтобы быстро создать самозаверенный сертификат для сервера, используйте следующую команду OpenSSL:<br />
openssl req -new -text -out server.req<br />
Сообщите всю информацию, запрашиваемую openssl. Убедитесь, что в имени хоста Вы указали "Common Name"; пароль можно не указывать. Программа создаст ключ, защищённый паролем; пароль меньше чем 4 символа не будет принят. Для того, чтобы удалить пароль (так как иначе Вы должны будете вводить его при запуске сервера), выполните команду:<br />
openssl rsa -in privkey.pem -out server.key<br />
rm privkey.pem<br />
Введите старый пароль чтобы разблокировать существующий ключ. После чего выполните:<br />
openssl req -x509 -in server.req -test -key server.key -out server.crt<br />
Теперь ваш сертификат стал самозаверенным и осталось скопировать его туда, где сервер будет его искать. После чего останется лишь изменить права доступа к нему:<br />
chmod og-rwx server.key<br />
Так как иначе сервер просто не будет его использовать. Более подробно о создании закрытого ключа и сертификата написано в документации по OpenSSL.<br />
Самозаверенный сертификат может быть использован для тестирования, но для продакшена должен быть использован сертификат, подписанный доверенным центром сертификации (СА) (глобальным или локальным), чтобы клиент мог убедиться в идентичности сервера. Если все клиенты находятся в одной организации, то предпочтительнее использовать локальные центры сертификации.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-38328267341673567822013-01-07T22:58:00.001-08:002013-01-10T06:25:48.169-08:0017.8. Опции шифрования<br />
<div class="SECT1" style="margin: 0px; padding: 0px;">
<div style="text-align: justify;">
PostgreSQL предоставляет возможность шифрования на разных уровнях, что позволяет защитить данные от кражи БД с сервера, недобросовестного администратора и небезопасной сети. Шифрование так же может использоваться для обеспечения тайны данных, таких как медицинская информация или финансовые транзакции.<a name='more'></a></div>
<h4>
Шифрование хранилища паролей</h4>
<div style="text-align: justify;">
По умолчанию пароли пользователей БД хранятся как хеши md5, так что администратор не может посмотреть пароль какого-либо пользователя. Если md5 шифрование используется для аутентификации клиентов, то незашифрованный пароль даже временно не будет присутствовать на сервере, так как пароль будет зашифрован ещё до того, как он будет передан по сети.</div>
<h4>
Шифрование определённых колонок</h4>
<div style="text-align: justify;">
Модуль <a href="http://postgresql-lab.blogspot.com/2013/01/f28-pgcrypto.html" target="_blank">pgcrypto</a> позволяет зашифровать определённые поля. Это полезно в случае, когда лишь некоторые ваши данные не должны попасть в чужие руки. Клиент предоставлет ключ для расшифровки, данные дешифруются на сервере и посылаются клиенту.</div>
<div style="text-align: justify;">
Дешифрованные данные и ключ для дешифровки находятся на сервере короткое время, необходимое для того, чтобы данные были дешифрованы и посланы клиенту. Только в это время они могут быть перехвачены кем-то с полным доступом к серверу, например, администратором.</div>
<h4>
Шифрование раздела данных</h4>
<div style="text-align: justify;">
На Linux шифрование может быть настроено поверх ФС при помощи "loopback device". Таким образом можно зашифровать весь раздел данных при помощи ОС. На FreeBSD эквивалентную функциональность предоставляет GEOM Based Disk Ecryption (gbde). Такую же функциональность поддерживают и многие другие ОС, включая Windows.</div>
<div style="text-align: justify;">
Этот механизм не позволяет прочитать данные с диска, если был украден диск или сервер целиком. Такой способ не даёт защиты после того, как ФС уже смонтирована, так как в таком случае появляется доступ к незашифрованным данным. Кроме того, для того, чтобы смонтировать ФС Вам нужно предоставить ОС ключ шифрования, и, иногда, этот ключ хранится на том же хосте, где и монтируется сам диск.</div>
<h4>
Шифрование паролей передаваемых по сети</h4>
<div style="text-align: justify;">
Метод аутентификации md5 дважды шифрует пароли на клиенте перед тем, как они будут переданы на сервер. Сперва происходит вычисление md5 хеша на основе имени пользователя, а затем на основе случайной соли, посланной сервером при установлении соединения. Это дважды зашифрованное значение и передаётся по сети серверу. Таким образом предотвращается раскрытие пароля и это не позволяет другому соединению использовать тот же самый зашифрованный пароль для подключения к базе позже.</div>
<h4>
Шифрование данных передаваемых по сети</h4>
<div style="text-align: justify;">
SSL соединения шифруют все данные, передаваемые по сети: пароли, запросы и результаты запросов. Файл pg_hba.conf позволяет администратору определить, какие хосты могут использовать нешифрованное соединение (host), а какие требуют шифрованного подключения (hostssl). Кроме того, клиенты сами могут быть настроены на подключение только по SSL. Stunel или SSH так же могут быть использованы для шифрования передаваемых данных.</div>
<h4>
Аутентификация хоста по SSL</h4>
<div style="text-align: justify;">
Возможно сделать так, чтобы сервер и хост имели сертификаты друг друга. Для этого потребуется дополнительная настройка на каждой стороне, но зато это обеспечивает надёжную верификаци или идентификацию, чем простые пароли. В таком случае компьютер не сможет притвориться сервером на достаточное время, чтобы получить пароль клиента. Кроме того, это позволяет избавиться от атаки "man in the middle", где атакующий встревает в диалог клиента и сервера и читает передаваемые по сети между ними данные.</div>
<h4>
Шифрование на стороне клиента</h4>
<div style="text-align: justify;">
Если системному администратору на сервере нельзя доверять, то клиент должен шифровать свои данные. Таким образом не шифрованные данные даже не будут попадать на сервер БД. Данные шифруются на клиенте, хранятся в БД, передаются зашифрованными клиенту и он уже расшифровывает их обратно перед использованием</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-8870904907009897332013-01-07T02:46:00.004-08:002013-01-10T06:25:48.210-08:0017.7. Предотвращение спуфинга сервера<div style="text-align: justify;">
Всё то время, что сервер запущен, никто не может занять его место в качестве сервера-злоумышленника БД. Однако, пока сервер выключен, локальный пользователь может занять его место, запустив свой сервер. Такой сервер может читать пароли пользователей и их запросы, но не может возвращать данные, так как каталог PGDATA недоступен ему из-за разрешений ФС. Спуфинг возможен, так как любой пользователь может запустить свой сервер БД; клиент не может отличить настоящий сервер от злоумышленника, если он не сконфигурирован должным образом.</div>
<div style="text-align: justify;">
Самый простой способ предотвратить спуфинг для локальных подключений - использовать каталог <a href="http://ru.wikipedia.org/wiki/Unix_domain_socket" target="_blank">Unix domain socket</a> (<a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" target="_blank">unix_socket_directory</a>), который имеет права на запись только для доверенного локального пользователя. Это не позволит злоумышленнику создать свой собственный сокет в этой директории. Если Вы обеспокоены тем, что некоторые приложения могут всё ещё ссылаться на /tmp в поисках файла сокета и потому быть уязвимы для спуфинга, создайте при запуске ОС символическую ссылку /tmp/.s.PGSQL.5432, которая будет вести к файлу сокета в другом месте. Кроме того, возможно, Вам потребуется изменить скрипт отчистки /tmp, чтобы он не удалял эту ссылку.</div>
<div style="text-align: justify;">
Для того, чтобы предотвратить спуфинг через TCP соединения, лучше всего использовать SSL сертификаты и убедиться, что клиент проверяет сертификат сервера. Для этого сервер должен быть настроен на приём только hostssl соединений (<a href="http://postgresql-lab.blogspot.com/2013/01/191-pghbaconf-file.html" target="_blank">раздел 19.1</a>) и иметь SSL файлы server.key (ключ) и server.crt (сертификат) (<a href="http://postgresql-lab.blogspot.com/2013/01/179-secure-tcpip-connections-with-ssl.html" target="_blank">раздел 17.9</a>). TCP клиенты должны подключаться при помощи sslmode=verify-ca или verify-full и иметь установленные соответствующие корневые сертификаты (<a href="http://postgresql-lab.blogspot.com/2013/01/311-database-connection-control.html" target="_blank">раздел 31.1</a>)</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-44296867804302779122013-01-07T01:10:00.000-08:002013-01-10T06:25:48.171-08:0017.6. Обновление PostgreSQL кластера<br />
<h1 class="SECT1" style="font-family: Verdana, Georgia, 'Times New Roman', Times, serif; font-weight: normal; margin: 0px; padding: 0px; text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: small;">В этом разделе будет рассказано о том, как перевести вашу БД с одного PostgreSQL релиза на более новый.</span></h1>
<div>
<a name='more'></a><div style="font-family: verdana, sans-serif; text-align: justify;">
Мажорные версии PostgreSQL определяются первыми двумя группами цифр номера версии, например 8.4; минорные - третьей группой, например 8.4.2 - второй минорный релиз мажорной версии 8.4. При изменении минорного релиза формат внутреннего хранилища не изменяется и он всегда совместим с более ранними и поздними минорными релизами того же мажорного релиза; другими словами 8.4.2 совместим с 8.4, 8.4.1 и 8.4.6. Для того, чтобы провести обновление между совместимыми версиями, Вы просто замещаете выполняемые файлы на выключенном сервере и затем запускаете его. Каталог данных остаётся прежним - минорные обновления очень просты.</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Для <i>мажорных</i> релизов PostgreSQL формат внутреннего хранилища может быть изменён и это усложняет обновления. Традиционный метод перемещения данных между мажорными версиями - создать дамп и перезагрузить БД. Но есть и другие методы, описанные ниже.<i></i></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Кроме того, новые мажорные релизы обычно содержат несовместимость заметную для пользователя, так что может потребоваться изменение клиентского ПО. Все такие изменения перечислены в примечаниях к релизу (<a href="http://www.postgresql.org/docs/9.2/static/release.html" target="_blank">Приложение Е</a>); особое внимание уделите разделу "Миграция". Если Вы производите обновления между мажорными версиями, обязательно прочитайте все примечания к релизу для промежуточных версий.</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Осторожные пользователи могут захотеть протестировать клиентские приложения на новой версии перед тем, как переключаться на неё окончательно. Поэтому зачастую является хорошей идеей установить параллельно новую версию для тестирования. Когда Вы производите тестирование мажорной версии PostgreSQL, обратите внимание на изменения в следующих категориях:</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
<b>Администрирование</b></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Возможности управления и мониторинга сервера зачастую меняются и улучшаются в каждом мажорном релизе</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
<b>SQL</b></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Обычно добавляются новые команды SQL и не меняется поведение существующих, если это специально не оговорено</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
<b>API библиотеки</b></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Обычно в библиотеках лишь добавляется новая функциональность, если что-то другое не указано в примечаниях к релизу</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
<b>Системные каталоги</b></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Изменение системных каталогов обычно затрагивает только инструменты управления БД</div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
<b>C-API сервера</b></div>
<div style="font-family: verdana, sans-serif; text-align: justify;">
Сюда относятся изменения в API бэкенда, написанного на C. Эти изменения влияют на код функций глубоко в сервере.</div>
<h3 style="font-family: verdana, sans-serif;">
<span style="font-size: small;">
17.6.1 Обновление данных посредством pg_dump</span></h3>
<div style="font-family: verdana, sans-serif;">
Для того, чтобы задампить данные с одной мажорной версии PostgreSQL и загрузить их в другую, Вы должны использовать pg_dump; резервное копирование на уровне ФС не будет работать. (Более того, есть проверки, которые не позволят Вам использовать каталог данных из несовместимой версии PostgreSQL. Так что ничего страшного не случится, если Вы запустите сервер на другом каталоге данных).</div>
<div style="font-family: verdana, sans-serif;">
Рекомендуется использовать программы pg_dump и pg_dumpall более новой версии PostgreSQL чтобы воспользоваться новыми возможностями, которые могли в них появиться. Текущие релизы программ дампа могут считывать данные с серверов начиная с версии 7.0.</div>
<div style="font-family: verdana, sans-serif;">
Следующие инструкции предполагают что ваша текущая версия установлена в /usr/local/pgsql, а данные хранятся в /usr/local/pgsql/data:</div>
<div>
<ol>
<li style="text-align: justify;"><span style="font-family: verdana, sans-serif;">Перед тем, как создать резервную копию данных, убедитесь, что данные вашей БД не будут обновлены. Обновление не повлияет на целостность бакупа, но новые данные в него просто не войдут. Если необходимо, отредактируйте разрешения в файле /usr/local/pgsql/data/pg_hba.conf (или соответствующий файл) для того, чтобы закрыть доступ всем, кроме Вас. В <a href="http://postgresql-lab.blogspot.com/2013/01/chapter-19-client-authentication.html" target="_blank">главе 19</a> о контроле доступа говорится более подробно.<br />Для того, чтобы сделать резервную копию вашей БД выполните:<br />pg_dumpall > <i>outputfile</i><br />Если Вам нужно сохранить OID'ы (например, если Вы используете их как внешние ключи), используйте опцию -о<br />Для того, чтобы сделать резервную копию, можно использовать pg_dumpall используемой версии. Но лучших результатов можно добиться используя комманду pg_dumpall для PostgreSQL 9.1.1, так как эта версия содержит исправления ошибок и некоторые улучшения по отношению к прошлой версии. Хотя этот совет может казаться странным, ведь Вы же ещё не установили новую версию, им можно воспользоваться, если Вы хотите использовать новую версию параллельно со старой. В этом случае Вы можете сперва установить новую версию, после чего перенести данные. Кроме того, это сократит время недоступности сервера.</span></li>
<li style="text-align: justify;"><span style="font-family: verdana, sans-serif;">Выключите старый сервер:<br />pg_ctl stop<br />На системах, где PostgreSQL запускается при запуске, скорее всего есть файл, который делает то же самое. Например, на Red Hat Linux это можно сделать так:<br />/etc/rc.d/init.d/postgresql stop<br />В главе 17 подробнее говорится о <a href="http://postgresql-lab.blogspot.ru/2013/01/173.html" target="_blank">запуске</a> и <a href="http://postgresql-lab.blogspot.ru/2013/01/175.html" target="_blank">остановке</a> сервера.</span></li>
<li style="text-align: justify;"><span style="font-family: verdana, sans-serif;">Если Вы восстанавливаете данные из резервной копии, то переименуйте или удалите старую папку установки. Лучше всего, конечно, её переименовать, а не удалить, так что в случае какой-либо проблемы Вы сможете быстро её восстановить. Однако помните, что она может занимать значительное место на диске. Для того, чтобы переименовать каталог, воспользуйтесь командой вроде этой:<br />mv /usr/local/pgsql /usr/local/pgsql.old<br />(Убедитесь, что Вы перемещаете каталог целиком, чтобы сохранить относительные пути)</span></li>
<li style="text-align: justify;"><span style="font-family: verdana, sans-serif;">Установите новую версию PostgreSQL, как это описано в <a href="http://postgresql-lab.blogspot.com/2013/01/154-installation-procedure.html" target="_blank">разделе 15.4</a></span></li>
<li style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">Создайте новый кластер БД, если это необходимо. Помните, что Вы должны выполнить это, зайдя под пользователем БД (в принципе, Вы под ним уже должны быть, если Вы обновляетесь):<br />/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data</span></li>
<li style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">Восстановите предыдущую версию pg_hba.conf и изменений в postgresql.conf</span></li>
<li style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">Запустите сервер БД из под пользователя БД:<br />/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data</span></li>
<li style="text-align: justify;"><span style="font-family: Verdana, sans-serif;">И, наконец, восстановите данные из резервной копии:<br />/usr/local/pgsql/bin/psql -d postgres -f <i>outputfile</i><br />используя <i>новую </i>версию psql</span></li>
</ol>
<div style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">Сократить время недоступности сервера можно установив новый сервер в другой каталог и запустив параллельно оба сервера на разных портах. После чего можно сделать что-то вроде этого для передачи данных:</span></div>
</div>
<div style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">pg_dumpall -p 5432 | psql -d postgres -p 5433</span></div>
</div>
<h3>
<span style="font-family: Verdana, sans-serif;">17.6.2 Обновление без дампа</span></h3>
<div style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">Модуль <a href="http://postgresql-lab.blogspot.com/2013/01/f36-pgupgrade.html" target="_blank">pg_upgrade</a> позволяет переместить данные с одной мажорной версии PostgreSQL на следующую. Сделать это можно за несколько минут.</span></div>
<div style="text-align: justify;">
<span style="font-family: Verdana, sans-serif;">Кроме того, можно использовать методы репликации, вроде Slony, для создания резервного сервера с обновлённой версией PostgreSQL. Это возможно, поскольку Slony поддерживает репликацию между разными мажорными версиями PostgreSQL. Резервный сервер может быть как на той же машине, так и на другой. Как только он синхронизирован с мастером (где запущена старая версия PostgreSQL), Вы можете изменить его роль на мастера и выключить старый сервер. Такой метод позволяет сократить время недоступности сервера до нескольких секунд.</span></div>
<div class="SECT2" style="font-family: verdana, sans-serif; font-size: 12px; margin: 0px; padding: 0px;">
<div style="margin-bottom: 1.2em; margin-top: 0.6em; padding: 0px;">
<br /></div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-16057506159460704472013-01-06T22:19:00.004-08:002013-01-10T06:25:48.161-08:0017.5. Остановка сервера<br />
<h1 class="SECT1" style="font-family: Verdana, Georgia, 'Times New Roman', Times, serif; font-size: 2.5em; font-weight: normal; margin: 0px; padding: 0px; text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;">Есть несколько способов выключить сервер БД. Вы можете определить способ остановки сервера, посылая разные сигналы главному процессу postgres.</span></h1>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;"><b>SIGTERM</b></span></div>
<blockquote class="tr_bq">
<span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;">Это режим "умного выключения" (smart shutdown). После получения сигнала SIGTERM сервер запрещает создание новых подключений, но уже существующие работают нормально. Выключение происходит только после того, как разорваны все соединения. Если сервер находится в режиме online backup, то новые подключения всё ещё можно создать, но только для суперпользователя (это позволит суперпользователю подлкючиться и остановить процесс создания резервной копии). Если сервер находится в режиме восстановления, то восстановление и потоковая репликация останавливаются только после того, как завершаются все сессии</span></span></blockquote>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;"><b>SIGINT</b></span></div>
<blockquote class="tr_bq">
<span style="font-family: verdana, sans-serif;"><span style="font-size: 12px;">Это режим "быстрого выключения" (fast shutdown). Сервер запрещает создание новых подключений и посылает всем существующим процессам сервера сигнал SIGTERM, что завершает их работу. После того, как все процессы завершат свою работу, останавливается и главный процесс. </span></span><span style="font-family: verdana, sans-serif; font-size: 12px;">Если сервер находится в режиме online backup,</span><span style="font-family: verdana, sans-serif; font-size: 12px;"> то оно тут же прерывается.</span></blockquote>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;"><b>SIGQUIT</b></span></div>
<blockquote class="tr_bq">
<span style="font-family: verdana, sans-serif; font-size: 12px;">Это режим "немедленного выключения" (immediate shutdown). Главный процесс postgres посылает сигнал SIGQUIT всем дочерним процессам и завершается сам, не дожидаясь их завершения. Дочерние процессы так же завершаются сразу же по получении сигнала. Это приведёт к восстановлению (воспроизведению WAL логов) при следующем запуске. Рекомендуется только в крайних случаях.</span></blockquote>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;">Программа <a href="http://postgresql-lab.blogspot.ru/2012/12/pgctl.html" target="_blank">pg_ctl</a> предоставляет удобный способ посылки сигналов для остановки сервера. Кроме того Вы можете послать сигнал напрямую при помощи команды kill, если Вы не используете Windows. PID процесса postgres может быть найден при помощи программы ps, или его можно узнать из файла postmaster.pid в директории с данными. Вот пример быстрого выключения:</span></div>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;">$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</span></div>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;"><b>Важно: </b>Лучше не использовать SIGKILL для выключения сервера. Такой способ не позволяет серверу освободить память и семафоры, так что это должно будет сделано вручную перед запуском нового процесса сервера. Более того, SIGKILL убивает процесс postgres не позволяя переслать сигнал дочерним процессам, так что каждый из них придётся убивать вручную.</span></div>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px;">Для того, чтобы прервать индивидуальную сессию, оставив остальные рабочими, используйте pg_terminate_backend() (см <a href="http://postgresql-lab.blogspot.com/2013/01/924-system-administration-functions.html" target="_blank">таблицу 9-55</a>) или пошлите SIGTERN дочернему процессу, связанному с этой сессией.</span></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-6083046410567211282013-01-06T03:11:00.001-08:002013-01-10T06:25:48.173-08:0017.4. Управление ресурсами ядра<div style="text-align: justify;">
Большая установка PostgreSQL может быстро исчерпать ресурсы вашей системы (на некоторых системах объём доступных ресурсов так мал, что для этого даже не нужна "большая" установка). Если и Вы столкнулись с этой проблемой - читайте дальше.<br />
<a name='more'></a></div>
<h4>
17.4.1 Разделяемая память и семафоры</h4>
<div style="text-align: justify;">
Разделяемая память и семафоры относятся к "System V IPC" (так же как и очереди сообщений, которые не относятся к PostgreSQL). Почти все современные ОС поддерживают эти возможности, но в некоторых из них они не активированы по умолчанию или не имеют достаточного их количества; особенно это касается оперативной памяти. (На Windows PostgreSQL предоставляет свои собственные реализации этой функциональности, так что большая часть этой главы может быть пропущена.)</div>
<div style="text-align: justify;">
Полное отсутствие этих возможностей обычно проявляется в ошибках вроде Illegal system call при запуске сервера. В этом случае единственное, что можно сделать - переконфигурировать сервер. Без них PostgreSQL не работает. Но это достаточно редкая ситуация на современных ОС.</div>
<div style="text-align: justify;">
Когда потребности PostgreSQL превышают лимиты IPC, сервер тоже не запустится и оставит Вам сообщение, описывающее проблему и дающее совет, что стоит сделать (см <a href="http://postgresql-lab.blogspot.ru/2013/01/173.html" target="_blank">раздел 17.3.1</a>). Нужные параметры ядра имеют одинаковые имена на разных системах; их обзор приведён в таблице 17-1. А вот методы для их установки отличаются на разных системах. Предположения для некоторых платформ высказаны ниже.</div>
<div style="text-align: center;">
<b>Таблица 17-1. Параметры System V IPC</b></div>
<table border="1">
<colgroup>
<col></col>
<col></col>
<col></col>
</colgroup>
<thead>
<tr>
<th>Имя</th>
<th>Описание</th>
<th>Разумные значения</th>
</tr>
</thead>
<tbody>
<tr><td><tt>SHMMAX</tt></td><td>Максимальное значение сегмента разделяемой памяти (байты)</td><td>как минимум несколько мегабайт (см далее)</td></tr>
<tr><td><tt>SHMMIN</tt></td><td>Минимальное значение сегмента разделяемой памяти (байты)</td><td>1</td></tr>
<tr><td><tt>SHMALL</tt></td><td>Общее количество доступной разделяемой памяти (байты или страницы)</td><td>если байты - то же, что и <tt>SHMMAX</tt>; если страницы - <tt>ceil(SHMMAX/PAGE_SIZE)</tt></td></tr>
<tr><td><tt>SHMSEG</tt></td><td>Максимальное количество сегментов разделяемой памяти на процесс</td><td>нужен только один сегмент, но значение по умолчанию значительно больше</td></tr>
<tr><td><tt>SHMMNI</tt></td><td>Максимальное количество сегментов разделяемой памяти в системе</td><td><tt>SHMSEG + объём для других приложений</tt></td></tr>
<tr><td><tt>SEMMNI</tt></td><td>Максимальное количество идентификаторов семафоров (т.е. наборы (sets))</td><td>как минимум <tt>ceil((max_connections + autovacuum_max_workers + 4) / 16)</tt></td></tr>
<tr><td><tt>SEMMNS</tt></td><td>Максимальное количество семафоров на систему</td><td><tt>ceil((max_connections + autovacuum_max_workers + 4) / 16) * 17</tt> + объём для других приложений</td></tr>
<tr><td><tt>SEMMSL</tt></td><td>Максимальное количество семафоров на набор</td><td>как минимум 17</td></tr>
<tr><td><tt>SEMMAP</tt></td><td>Количество экземпляров в карте семафоров</td><td>см в тексте</td></tr>
<tr><td><tt>SEMVMX</tt></td><td>Максимальное количество семафоров</td><td>как минимум 1000 (Обычно значение по умолчанию 32767; не меняйте его, пока не требуется)</td></tr>
</tbody></table>
<div style="text-align: center;">
<br /></div>
<div style="text-align: justify;">
Наиболее важный параметр разделяемой памяти - SHMMAX; максимальный размер, в байтах, сегмента разделяемой памяти. Если Вы получаете сообщение об ошибке от shmget вроде "Invalid argument", то скорее всего Вы превысили лимит. Размер требуемого сегмента разделяемой памяти зависит от различных конфигурационных параметров, как показано в таблице 17-2 (см в конце раздела). (Любое сообщение об jib,rt6 которое Вы получите, будет содержать точное значение неудачного запроса.) Вы можете, в качестве временного решения, понизить некоторые из этих настроек, чтобы избежать падения сервера. Хотя и можно запустить PostgreSQL со значением SHMMAX меньшим, чем 2Мб, для приемлемой производительности Вам потребуется значительно больший объём. Рекомендуемое количество находится в интервале от ста мегабайт до нескольких гигабайт.<br />
Некоторые системы содержат лимит на общее количество разделяемой памяти в системе (SHMALL). Убедитесь, что это значение достаточно велико, чтобы его хватило н PostgreSQL и другие приложения, использующие разделяемую память. Обратите внимание, что SHMALL на большинстве систем измеряется в страницах, а не в байтах.<br />
Менее вероятно, что проблема возникнет с минимальным размером разделяемой памяти (SHMMIN), который должен быть где-то 500kB для PostgreSQL (обычно это лишь 1). Максимальное количество сегментов на систему (SHMMNI) или на процесс (SHMSEG) тоже маловероятно приведут к появлению проблемы, если они не равны 0.<br />
PostgreSQL использует один семафор на разрешённое подключение (<a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" target="_blank">max_connections</a>) и на позволенный рабочий процесс autovacuum (<a href="http://postgresql-lab.blogspot.com/2013/01/1810-automatic-vacuuming.html" target="_blank">autovacuum_max_workers</a>) в наборах по 16. Каждый такой набор так же содержит 17ый семафор, который содержит "магическое число", чтобы определять коллизии между наборами семафоров, которые используют другие приложения. Максимальное количество семафоров в системе устанавливается значением SEMMNS, которое следовательно должны быть равно как минимум max_xonnections + max_autovacuum_max плюс ещё по одному на каждые 16 разрешённых соединений и рабочих процессов autovacuum (см формулу в таблице 17-1). Параметр SEMMNI определяет предел набору семафоров, которые могут присутствовать в системе одновременно. Этот параметр должен быть равен как минимум ceil((max_connections + autovacuum_max_workers + 4) / 16). Уменьшение количества разрешённых подключений может временно решить проблему с запуском сервера, которая обычно звучит как "No space left on device" от semget.<br />
В некоторых случаях может быть необходимо увеличить SEMMAP чтобы он был одного порядка, что и SEMMNS. Этот параметр определяет размер карты ресурсов семафоров, где каждый смежный доступный блок семафоров должен иметь своё отображение. Когда освобождается набор семафоров, то он либо добавляется к существующей единице, отражающей соседний свободный блок, или же регистрируется как новая единица. Если карта заполнена, то свободные семафоры теряются (до перезагрузки). Фрагментация пространства семафором может раньше времени уменьшить количество доступных семафоров.<br />
Параметр SEMMSL, который определяет количество семафоров в наборе, для PostgreSQL должно быть как минимум 17.<br />
Другие настройки, относящиеся к "semaphore undo", вроде SEMMNU и SEMUME, не влияют на PostgreSQL.<br />
<b>AIX</b><br />
Как минимум с версии 5.1 для таких параметров, как SHMMAX не должно требоваться никакой настройки, так как он по умолчанию позволяет использовать всю память как разделяемую. Такой тип настройки обычно используется для других БД, таких как DB/2<br />
Тем не менее может потребоваться изменить глобальную информацию ulimit в /etc/security/limits, так как значения лимитов по умолчанию для размеров файлов (fsize) и количества файлов (nofiles) может быть слишком маленьким.<br />
<b>BSD/OS</b><br />
<u>Разделяемая память</u>. По умолчанию поддерживается всего 4Мб разделяемой памяти. Помните, что эта разделяемая память не делится на страницы, она залочена в RAM. Для того, чтобы увеличить количество разделяемой памяти, поддерживаемое вашей системой, добавьте что-то вроде этого в файл конфигурации ядра:<br />
options "SHMALL=8192"<br />
option "SHMMAX=\(SHMALL*PAGE_SIZE\)"<br />
SHMALL измеряется в 4Кб страницах, так что значение 1024 означает 4Мб разделяемой памяти. Так что в нашем примере мы увеличили его до 32Мб. Тем, кто использует версии 4.3 и старше, скорее всего придётся задать значение KRENEL_VIRTUAL_MB большее, чем значение по умолчанию в 248. После того, как изменения внесены, перекомпилируйте ядро и перезагрузитесь.<br />
<u>Семафоры:</u> Скорее всего Вы захотите увеличить число доступных семафоров, так как общее значение в 60 позволит только около 50 подключений PostgreSQL. Задайте желательное значение в файле конфигурации ядра:<br />
options "SEMMNI=40"<br />
options "SEMMNS=240"<br />
<b>FreeBSD</b><br />
Значения по умолчанию подходят только для небольших установок (например, значение по умолчанию для SHMMAX - 32Мб). Изменения могут быть внесены либо через sysctl, либо через интерфейс loader. Эти параметры могут быть установлены при помощи sysctl:<br />
$sysctl -w kern.ipc.shmall=32768<br />
$sysctl -w kern.ipc.shmmax=134217728<br />
$sysctl -w kern.ipc.semmap=256<br />
Для того, чтобы эти настройки сохранились после перезагрузки, измените /etc/sysctl.conf<br />
Остальные настройки семафоров доступны только для чтения, но могут быть изменены перед загрузкой при помощи loader:<br />
(loader) set kern.ipc.semmni=256<br />
(loader) set kern.ipc.semmns=512<br />
(loader) set kern.ipc.semmnu=256<br />
И они тоже могут быть сохранены в /boot/loader.conf<br />
Кроме того, Вы можете захотеть сконфигурировать своё ядро так, чтобы оно хранило разделяемую память только в ОЗУ и не свопила её. Это можно сделать при помощи настройки sysctl kern.ipc.shm_use_phys<br />
Если Вы запускаете сервер в тюрьме FreeBSD, то Вам надо активировать настройку sysctl security.jail.sysvipc_allowed; кроме того, сервера, запущенные в разных тюрьмах, должны быть запущенны от разных пользователей ОС. Это обеспечивает больший уровень безопасности, так как не позволяет не-суперпользователю получить доступ к общей памяти или семафорам в другой тюрьме и, кроме того, это позволяет корректно работать коду уборщика PostgreSQL IPC. (В FreeBSD 6.0 и более поздних код уборщика IPC не может корректно определять процессы в разных тюрьмах, что не позволяет запустить сервера на одном и том же порту в разных тюрьмах).<br />
FreeBSD версии до 4.0 работает как NetBSD и OpenBSD (см ниже)<br />
<b>NetBSD</b><br />
<b>OpenBSD</b><br />
Опции SYSVSHM и SYSVSEM должны быть активированы при компиляции ядра (так и есть по умолчанию). Максимальный размер разделяемой памяти определяется опцией SHMMAXPGS (в страницах). Вот пример настройки параметров на NetBSD (OpenBSD использует option вместо options):<br />
<pre class="PROGRAMLISTING" style="padding: 0px;">options SYSVSHM
options SHMMAXPGS=4096
options SHMSEG=256
options SYSVSEM
options SEMMNI=256
options SEMMNS=512
options SEMMNU=256
options SEMMAP=256</pre>
Кроме того, Вы можете захотеть сконфигурировать своё ядро так, чтобы оно хранило разделяемую память только в ОЗУ и не свопила её. Это можно сделать при помощи настройки sysctl kern.ipc.shm_use_phys</div>
<div style="text-align: justify;">
<b>HP-UX</b></div>
<div style="text-align: justify;">
Значения по умолчанию подходят для нормальной установки. На HP-UX 10 значение по умолчанию для SEMMNS (равное 128) может быть недостаточным для больших БД.</div>
<div style="text-align: justify;">
Параметры IPC могут быть установлены в System Administration Manager (SAM) в Kernel Configuration -> Configurable Parametrs. Выберите Create A New Kernel после того, как закончите настройку.</div>
<div style="text-align: justify;">
<b>Linux</b></div>
<div style="text-align: justify;">
Значение по умолчанию для максимального размера сегмента - 32Мб, что подходит только для очень небольших БД. Значение по умолчанию для общего количества - 2097152 страниц. Страница, почти всегда, это 4Кб, кроме случаев, когда ядро сконфигурировано с "huge pages" (для проверки этого используйте getconf PAGE_SIZE). Таким образом предел по умолчанию будет 8Gb, что зачастую достаточно, но не всегда.</div>
<div style="text-align: justify;">
Размер разделяемой памяти может быть изменён через sysctl. Например, для того, чтобы использовать 16Gb воспользуйтесь следующими командами:</div>
<div style="text-align: justify;">
$ sysctl -w kernel.shmmax=17179869184</div>
<div style="text-align: justify;">
$ sysctl -w kernel.shmall=4194304</div>
<div style="text-align: justify;">
Эти настройки могут быть сохранены в /etc/sysctl.conf для их сохранения после перезагрузки. Сделать это крайне рекомендуется.</div>
<div style="text-align: justify;">
В старых дистрибутивах может не быть программы sysctl, в таком случае внести изменения можно при помощи ФС /proc:</div>
<div style="text-align: justify;">
$ echo 17179869184 >/proc/sys/kernel/shmmax</div>
<div style="text-align: justify;">
$ echo 4194304 >/proc/sys/kernel/shmall</div>
<div style="text-align: justify;">
Остальные значения по умолчанию менять практически никогда не требуется.</div>
<div style="text-align: justify;">
<b>Mac OS X</b></div>
<div style="text-align: justify;">
Рекомендуемый метод настройки разделяемой памяти в OS X - создать файл с именем /etc/sysclt.conf со следующим содержанием:</div>
<div style="text-align: justify;">
kern.sysv.shmmax=4194304</div>
<div style="text-align: justify;">
kern.sysv.shmmin=1</div>
<div style="text-align: justify;">
kern.sysv.shmmni=32</div>
<div style="text-align: justify;">
kern.sysv.shmseg=8</div>
<div style="text-align: justify;">
kern.sysv.shmall=1024</div>
<div style="text-align: justify;">
Обратите внимание, что в некоторых версиях OS X, <i>все пять</i> параметров разделяемой памяти должны быть сохранены в /etc/sysctl.conf, иначе они могут быть проигнорированы.</div>
<div style="text-align: justify;">
Кроме того, последние релизы OS C игнорируют попытки задать значение SHMMAX, которое не делится на 4096.</div>
<div style="text-align: justify;">
SHMAL измеряется в страницах по 4Кб.</div>
<div style="text-align: justify;">
В старых версиях OS X Вам потребуется перезагрузка для того, чтобы параметры разделяемой памяти были применены. В 10.5 можно изменить все значения, кроме SHMMNI на лету при помощи sysctl. Но всё же лучше внести их в /etc/sysctl.conf, чтобы значения были сохранены после перезагрузки.</div>
<div style="text-align: justify;">
Файл /etc/sysctl.conf учитывается только в OS X 10.3.9 и позже. Если Вы используете более ранние версии релиза 10.3.х, то Вам нужно редактировать файл /etc/rc и изменить значения при помощи следующих команд:</div>
<pre class="PROGRAMLISTING" style="padding: 0px;">sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall</pre>
<div style="text-align: justify;">
Обратите внимание, что /etc/rc обычно перезаписывается при обновлении OS X, так что будьте готовы повторить эти изменения после каждого обновления.<br />
В OS X 10.2 и более ранних версиях, вместо этих команд отредактируйте файл /System/Library/StartupItems/SystemTunng/SystemTuning.<br />
<b>SCO OpenServer</b><br />
В конфигурации по умолчанию доступно только 512Кб разделяемой памяти на сегмент. Для того, чтобы увеличить эти настройки, сначала перейдите в каталог /etc/conf/cf.d. Для того, что посмотреть текущее значение SHMMAX, выполните:<br />
./configure -y SHMMAX<br />
Для того, чтобы задать новое значение SHMMAX, выполните:<br />
./configure SHMMAX=value<br />
где value - новое значение (в байтах). После установки SHMMAX перестройте ядро:<br />
./link_unix<br />
и перезагрузитесь.<br />
<b>Solaris 2.6 - 2.9 (Solaris 6 - Solaris 9)</b><br />
Значение по умолчанию для максимального размера сегмента разделяемой памяти слишком мал для PostgreSQL. Эти настройки могут быть изменены в /etc/system, например:<br />
<pre class="PROGRAMLISTING" style="padding: 0px;">set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32</pre>
Вам потребуется перезагрузка для того, чтобы эти изменения возымели действие. Смотрите так же <a href="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html">http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html</a>, где говорится о разделяемой памяти на старых версиях Solaris.<br />
<b>Solaris 2.10 (Solaris 10)</b><br />
<b>OpenSolaris</b><br />
В Solaris 10 и OpenSolaris значения по умолчанию для разделяемой памяти и семафоров вполне хороши для большинства PostgreSQL приложений. По умолчанию SHMMAX равен 1/4 ОЗУ. Если Вам нужно увеличить это значение, Вы должны использовать настройки проекта, связанные с пользователем postgres. Например, запустите от имени суперпользователя:<br />
projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged, 8GB, deny)" -U postgres -G postgres user.postgres<br />
Эта команда добавляет проект user.postgres и увеличивает максимум разделяемой памяти для пользователя postgres до 8Gb и активируется после следующего раза, как пользователь входит в систему или когда Вы перезапустите PostgreSQL (не перезагрузите). Мы подразумеваем, что PostgreSQL запущен под пользователем postgres в группе postgres. Перезагрузка сервера не требуется.<br />
Другие рекомендуемые настройки ядра нужны для серверов с большим количеством подключений:<br />
<pre class="PROGRAMLISTING" style="padding: 0px;">project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)</pre>
Кроме того, если Вы запускаете PostgreSQL в зоне, Вам может потребоваться увеличить лимит ресурсов зоны. Смотрите главу 2 "Projects and Tasks" в Solaris 10 System Administrator's Guide, где содержится более подробная информация об projects и prctl.<br />
<b>UnixWare</b><br />
На UnixWare 7 максимальный размер сегмента разделяемой памяти всего 512 Кб в конфигурации по умолчанию. Для того, чтобы посмотреть текущее значение SHMMAX выполните:<br />
/etc/conf/bin/idtune -g SHMMAX<br />
что отобразит текущее значение, значение по умолчанию, минимальное и максимальное значения. Для того, чтобы задать новое значение SHMMAX выполните:<br />
/etc/conf/bin/idtune SHMMAX value<br />
где value - то значение, которые Вы хотите использовать (в байтах). После установки SHMMAX перестройте ядро:<br />
/etc/conf/bin/idbuild -B<br />
и перезагрузитесь.<br />
<div style="text-align: center;">
<b>Таблица 17-2. Использование разделяемой памяти PostgreSQL</b></div>
<table border="1"><thead>
<tr><th>Использование</th><th>Приблизительное значение требуемой разделяемой памяти в байтах (как в 8.3)</th></tr>
</thead><tbody>
<tr><td>Подключения</td><td>(1800 + 270 * <a href="http://postgresql-lab.blogspot.com/2013/01/1812-lock-management.html" style="color: #2e89bf; text-decoration: initial;">max_locks_per_transaction</a>) * <a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" style="color: #2e89bf; text-decoration: initial;">max_connections</a></td></tr>
<tr><td>Рабочие процессы autovacuum</td><td>(1800 + 270 * <a href="http://postgresql-lab.blogspot.com/2013/01/1812-lock-management.html" style="color: #2e89bf; text-decoration: initial;">max_locks_per_transaction</a>) * <a href="http://postgresql-lab.blogspot.com/2013/01/1810-automatic-vacuuming.html" style="color: #2e89bf; text-decoration: initial;">autovacuum_max_workers</a></td></tr>
<tr><td>Подготовленные транзакции</td><td>(770 + 270 * <a href="http://postgresql-lab.blogspot.com/2013/01/1812-lock-management.html" style="color: #2e89bf; text-decoration: initial;">max_locks_per_transaction</a>) * <a href="http://postgresql-lab.blogspot.com/2013/01/184-resource-consumption.html" style="color: #2e89bf; text-decoration: initial;">max_prepared_transactions</a></td></tr>
<tr><td>Разделяемые буферы дисков</td><td>(<a href="http://postgresql-lab.blogspot.com/2013/01/1815-preset-options.html" style="color: #2e89bf; text-decoration: initial;">block_size</a> + 208) * <a href="http://postgresql-lab.blogspot.com/2013/01/184-resource-consumption.html" style="color: #2e89bf; text-decoration: initial;">shared_buffers</a></td></tr>
<tr><td>WAL буферы</td><td>(<a href="http://postgresql-lab.blogspot.com/2013/01/1815-preset-options.html" style="color: #2e89bf; text-decoration: initial;">wal_block_size</a> + 8) * <a href="http://postgresql-lab.blogspot.com/2013/01/185-write-ahead-log.html" style="color: #2e89bf; text-decoration: initial;">wal_buffers</a></td></tr>
<tr><td>Фиксированное требуемое значение</td><td>770 kB</td></tr>
</tbody></table>
<div style="text-align: center;">
<b><br /></b></div>
<h4>
<b>17.4.2 Лимиты ресурсов</b></h4>
<div>
Unix-подобные ОС используют различные лимиты ресурсов, которые могут вмешиваться в работу вашего PostgreSQL сервера. Наиболее важны лимиты на число процессов на пользователя, число открытых файлов на процесс и количество доступной памяти на процесс. Каждый из этих показателей имеет "жёсткий" и "мягкий" лимит. Мягкий лимит учитывается, но при этом пользователь может его изменить вплоть до жёсткого лимита. Жёсткий лимит может быть изменён только суперпользователем. Системный вызов setrlimit отвечает за настройку этих параметров. Встроенные команды оболочки ulimit (в оболочке Борна) или limit (csh) используются для контроля этих параметров из командной строки. На BSD системах файл /etc/login.conf управляет лимитами ресурсов на этапе входа в систему. Более подробно об этом можно узнать в документации к вашей ОС. Интересующие нас параметры - maxproc, openfiles и datasize. Например:<br />
<pre class="PROGRAMLISTING" style="padding: 0px;">default:\
...
:datasize-cur=256M:\
:maxproc-cur=256:\
:openfiles-cur=256:\
...</pre>
(-cur это мягкий лимит. Для жёсткого лимита используйте -max)<br />
Ядра так же могут иметь системные ограничения на некоторые ресурсы.<br />
<blockquote class="tr_bq">
На Linux /proc/sys/fs/file-max определяет максимальное число открытых файлов, которое будет поддерживать система. Оно может быть изменено записыванием другого числа в этот файл или присвоением в /etc/sysctl.conf. Максимальное число faqkjd на процесс фиксируется в ядре на момент компиляции; см /usr/src/linux/Documentation/proc.txt где это описано подробнее</blockquote>
Сервер PostgreSQL использует один процесс на соединение, так что у Вас должна быть возможность создавать так много процессов, сколько нужно подключений, кроме остальных процессов, которые Вам нужны. Обычно это не проблема, но если Вы запускаете несколько серверов на одной машине, это может создать для Вас проблему.<br />
Лимит по умолчанию на открытые файлы зачастую имеют "дружественные" значения, что позволяет многим пользователям существовать на одной машине без использования неуместных системных ресурсов. Если Вы запускаете много серверов на машине, то, возможно, это то, что Вы хотите, но на выделенном сервере Вы можете захотеть повысить это ограничение.<br />
С другой стороны, некоторые системы позволяют отдельным процессам открывать большое число файлов; но если так пытаются вести себя несколько процессов, то лимит системы может быть запросто исчерпан. Если Вы обнаружили, что это и произошло и Вы не хотите изменять лимиты системы, Вы можете настроить параметр конфигурации <a href="http://postgresql-lab.blogspot.com/2013/01/184-resource-consumption.html">max_files_per_process</a>, чтобы ограничить количество открытых файлов процессом.<br />
<h4>
17.4.3 Linux Memory Overcommit</h4>
<div>
В Linux 2.4 и более поздних версиях поведение виртуальной памяти не оптимально для PostgreSQL. Из-за того, как ядро реализует распределение памяти, ядро может прервать процесс сервера PostgreSQL (мастер-процесс сервера) если память, требуемая другим процессом исчерпывает объём виртуальной памяти.</div>
<div>
Если это происходит, то Вы увидите сообщение ядра, которое будет выглядеть вроде этого (посмотрите в документацию вашей системы и в настройки конфигурации где искать это сообщение):</div>
<div>
Out of Memory: Killed process 12345 (postgres).</div>
<div>
Это означает, что процесс postgres был прерван из-за проблем с памятью. Уже существующие соединения БД будут работать нормально, но новые соединения не будут установлены. Для того, чтобы восстановить нормальную работу нужно перезапустить PostgreSQL.</div>
<div>
Один из способов избежать эту проблему - запустить PostgreSQL на машине, где Вы можете быть уверены, что другой процесс не потратит всё память машины. Если на машине туго с памятью, то можно увеличить пространство свопирования ОС, так как out-of-memory (OOM) убийца срабатывает только когда исчерпывается физическая <b>и</b> своп память.</div>
<div>
На Linux 2.6 и более поздних версиях возможно изменить поведение ядра, так что такой проблемы не возникнет. Хотя эти настройки не предотвращают запуск <a href="http://lwn.net/Articles/104179/" target="_blank">OOM убийцы</a>, но они существенно снижают шансы на это и потому возможно более разумное поведение системы. Это делается установкой режима strict overcommit посредством sysctl:</div>
<div>
sysctl -w vm.overcommit_memory=2</div>
<div>
или размещением соответствующей записи в /etc/sysctl.conf. Кроме того, Вы можете захотеть изменить связанную настройку vm.overcommit_ratio. Более подробно смотрите в документации файла Documentation/vm/overcommit-accounting.</div>
<div>
Другой подход, который можно использовать с или без изменения vm.overcommit_memory, это задать процесс-специфичное значение oom_adj для процесса postmaster равным -17, что гарантирует, что он не будет целью OOM убийцы. Самый простой способ добиться этого:</div>
<div>
echo -17 > /proc/self/oom_adj</div>
<div>
в скрипте запуска postmaster прямо перед тем, как будет запущен сам postmaster. Обратите внимание, что выполнить это действие нужно из под суперпользователя или это не будет иметь никакого эффекта; так что суперпользовательский скрипт запуска самое лучшее для этого место. Если Вы так и поступите, то, наверно, Вы захотите собрать PostgreSQL c -DLINUX_OOM_ADJ=0, добавленным к CFLAGS. В этом случае дочерние процессы postmaster ,elen запущены со значением oom_adj = 0, так что OOM убийца всё ещё может использовать их как цели при необходимости.</div>
<div>
<b>Обратите внимание:</b> некоторые ядра Linux 2.4 могут иметь ранние версии параметра sysctl версии 2.6. Но, если Вы установите vm.overcommit_memory = 2 на ядре 2.4, которое не имеет нужного кода, это лишь ухудшит ситуацию, не улучшит её. Так что рекомендуется проверить исходники ядра (смотрите функцию vm_enough_memory в mm/mmap.c) чтобы убедиться, что эта опция поддерживает нужную Вам функциональность перед тем, как Вы её попробуете. Наличие файла документации overcommit-accounting <i>не</i> должно быть расценено как указание на поддержку этой возможности. Если есть сомнения - проконсультируйтесь со знатоками ядра или поставщиком ядра.</div>
</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-64770713325786352872013-01-02T04:38:00.000-08:002013-01-21T21:43:54.481-08:0017.3. Запуск сервера БД<br />
<div style="text-align: justify;">
Перед тем, как кто-нибудь сможет получить доступ к БД, Вы должны запустить сервер БД. Программа сервер называется postgres. Эта программа должна знать где найти необходимые ей для работы данные. Для этого используется опция -D. Так что самый простой способ запуска сервера:<br />
<a name='more'></a></div>
<div style="text-align: justify;">
$ postgres -D /usr/local/pgsql/data</div>
<div style="text-align: justify;">
В этом случае сервер будет запущен как активный процесс (не в фоне). Это должно быть сделано из под аккаунта пользователя PostgreSQL. Без опции -D сервер попытается найти данные в каталоге из переменной окружения PGDATA. Если же и этой переменной нет - то сервер не запустится.</div>
<div style="text-align: justify;">
Обычно гораздо удобнее запустить сервер в фоне. Для этого используйте обычный синтаксис оболочки Unix:</div>
<div style="text-align: justify;">
$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &</div>
<div style="text-align: justify;">
Очень важно где-то хранить вывод сервера и вывод ошибок, как показано выше. Это поможет в диагностике проблем. (См <a href="http://postgresql-lab.blogspot.com/2013/01/233-log-file-maintenance.html" target="_blank">раздел 23.3</a> где говорится об обработке лог файлов).</div>
<div style="text-align: justify;">
Программа postgres так же принимает опции командной строки. Более подробно об этом говорится в странице руководства <a href="http://postgresql-lab.blogspot.com/2013/01/postgres.html" target="_blank">postgres</a> и в главе 18.</div>
<div style="text-align: justify;">
Однако эти команды оболочки могут быстро надоесть. Поэтому есть программа-обёртка pg_ctl, которая позволяет сделать всё то же самое, но гораздо проще. Например</div>
<div style="text-align: justify;">
pg_ctl start -l logfile</div>
<div style="text-align: justify;">
запустит фоновый процесс сервера и направит вывод в указаный файл. Опция -D здесь имеет то же значение. Кроме того, pg_ctl может и остановить сервер.</div>
<div style="text-align: justify;">
Обычно Вам нужно запустить сервер БД при загрузке компьютера. Скрипты для автозапуска зависят от системы. Некоторые варианты Вы можете найти в каталоге contrib/start-scripts. Для их установки могут потребоваться права суперпользователя.</div>
<div style="text-align: justify;">
Разные системы умеют разные условия для запуска демона при загрузке. Многие системы имеют файл /etc/rc.local или /etc/rc.d/rc.local. Другие системы используют каталоги init.d или rc.d. Как бы то ни было, сервер должен быть запущен от имени пользователя PostgreSQL, а <i>не от имени</i> суперпользователя или другого пользователя. Поэтому, возможно, Вы должны использовать такую форму команды su -c '...' postgres. Например:</div>
<div style="text-align: justify;">
su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres</div>
<div style="text-align: justify;">
Вот несколько предположений для разных ОС (В любом случае будьте уверены, что Вы указываете правильную папку установки и имя пользователя):</div>
<div style="text-align: justify;">
<ul>
<li><b>FreeBSD </b>смотрите на файл /contrib/start-scripts/freebsd в папке с исходниками</li>
<li><b>OpenBSD</b> добавьте следующие строки в /etc/rc.local</li>
<pre class="PROGRAMLISTING" style="padding: 0px;">if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ];</pre>
<pre class="PROGRAMLISTING" style="padding: 0px;">then</pre>
<pre class="PROGRAMLISTING" style="padding: 0px;"> su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
echo -n ' postgresql'
fi</pre>
<li><b>Linux </b>добавьте </li>
<pre class="PROGRAMLISTING" style="padding: 0px;">/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data</pre>
<li><b>NetBSD </b>используйте либо подход FreeBSD либо Linux, в зависимости от предпочтений</li>
<li><b>Solaris</b> создайте файл с названием /etc/init.d/postgresql со следующей строкой</li>
<pre class="PROGRAMLISTING" style="padding: 0px;">su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"</pre>
</ul>
</div>
<div style="text-align: justify;">
Пока сервер запущен его PID хранится в postmaster.pid в каталоге с данными. Это используется для того, чтобы несколько экземпляров сервера не были запущены в одном и том же каталоге с данными. Его же можно использовать для остановки сервера.<br />
<h4>
17.3.1 Ошибки запуска сервера</h4>
<div>
Есть несколько общих ошибок из-за которых сервер может не запуститься. В поисках сообщения об ошибках обратитесь к логу сервера или запустите его вручную (без перенаправления стандартного вывода и вывода ошибок). Ниже мы объясним некоторые наиболее часто встречающиеся сообщения об ошибках:</div>
<div>
<b>LOG: could not bind IPv4 socket: Address already in use</b></div>
<div>
<b>HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.</b></div>
<div>
<b>FATAL: could not create TCP/IP listen socket</b></div>
<div>
Обычно это значит именно то, что и написано: Вы пытаетесь запустить другой сервер на том же порту, на котором уже запущен другой сервер. Однако, если порт не используется, то причина может быть в другом. Например, попытка запустить сервер на зарезервированном порту тоже приведёт к похожей ошибке.</div>
<div>
$ postgres -p 666</div>
<div>
<div>
LOG: could not bind IPv4 socket: Permission denied</div>
<div>
HINT: Is another postmaster already running on port 666? If not, wait a few seconds and retry.</div>
<div>
FATAL: could not create TCP/IP listen socket</div>
</div>
<div>
Сообщение вида</div>
<div>
<b>FATAL: could not create shared memory segment: Invalid argument</b></div>
<div>
<b>DETAIL: Failed system call was shmget (key=5440001, size=4011376640, 03600).</b></div>
<div>
обычно означает, что предел разделяемой памяти ядра меньше, чем пытается создать рабочая область PostgreSQL (в нашем примере 4011376640 байт). Или это может значить что ваше ядро не сконфигурировано на поддержку разделяемой памяти в стиле System-V. В качестве "костыля" Вы можете попробовать запустить сервер с меньшим количеством буферов (<a href="http://postgresql-lab.blogspot.com/2013/01/184-resource-consumption.html" target="_blank">shared_buffers</a>). В конечном счёте Вы захотите переконфигурировать ядро для увеличения объёма разрешённой разделяемой памяти. Кроме того, Вы можете увидеть это сообщение в том случае, когда Вы пытаетесь запустить несколько экземпляров сервера на одной и той же машине, если их общие потребности в памяти превышают пределы ядра.</div>
<div>
Ошибка вроде</div>
<div>
<b>FATAL: could not create semaphores: No space left on device</b></div>
<div>
<b>DETAIL: Failed system call was semget(5440126, 17, 03600).</b></div>
<div>
<i>не </i>означает, что у Вас кончилось место на диске. Это означает, что лимит ядра на число System V семафоров меньше, чем то, сколько хочет создать PostgreSQL. Как и в предыдущем случае, можно воспользоваться "костылём" и запустить сервер с уменьшенным количеством разрешённых подключений (<a href="http://postgresql-lab.blogspot.com/2013/01/183-connections-and-authentication.html" target="_blank">max_connections</a>), но в конце концов Вы всё равно просто переконфигурируете своё ядро.</div>
<div>
Если Вы получили ошибку "<b>illegal system call</b>", то, скорее всего, разделяемая память и семафоры вообще не поддерживаются вашим ядром. В этом случае Вам остаётся только переконфигурировать ядро для включения поддержки этих возможностей.</div>
<div>
Информация о том, как сконфигурировать возможности System V IPC находится в <a href="http://postgresql-lab.blogspot.com/2013/01/174-managing-kernel-resources.html" target="_blank">разделе 17.4.1</a></div>
<h4>
17.3.2 Проблемы с подключением клиента</h4>
<div>
Хотя ошибки подключения на стороне клиента имеют разные причины и зависят от конкретного приложения, тем не менее, некоторые из них связаны напрямую с тем, запущен ли сервер. Ошибки, отличные от приведённых ниже, должны решаться с конкретным приложением.</div>
<div>
<b>psql: could not connect to server: Connection refused</b></div>
<div>
<b> Is the server running on host "server.joe.com" and accepting</b></div>
<div>
<b> TCP/IP connections on port 5432?</b></div>
<div>
Это стандартная ошибка "Я не могу найти сервер, с которым я должен говорить". Она похоже на ошибку выше про TCP/IP. Скорее всего сервер забыли настроить на приём TCP/IP соединений.</div>
<div>
Кроме того, Вы можете увидеть такую ошибку при попытке соединиться с локальным сервером через unix сокеты:</div>
<div>
<b>psql: could not connect to server: No such file or directory</b></div>
<div>
<b> Is the server running locally and accepting</b></div>
<div>
<b> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?</b></div>
<div>
По последней строке Вы можете проверить, что клиент пытается подключиться туда, куда надо. Если там и правда нет сервера, то сообщение об ошибке от ядра будет либо <b>Connection refused </b>либо <b>No such file or directory</b> как в нашем примере. (Важно отметить, что <b>Connection refused </b>в данном случае не означает, что сервер получил ваш запрос на подключение и отклонил его. Такая ситуация приведёт к другому сообщению об ошибке, как показано в <a href="http://postgresql-lab.blogspot.com/2013/01/194-authentication-problems.html" target="_blank">разделе 19.4</a>). Другие сообщения об ошибках вроде <b>Connection timed out</b> могут означать наличие более серьёзных проблем, таких как задержки в сети.</div>
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-64666335761140909552013-01-02T00:24:00.002-08:002013-01-10T06:26:45.923-08:0029.4. Настройка WAL<div style="text-align: justify;">
Есть несколько связанных с WAL параметров конфигурации, которые влияют на производительность БД. Этот раздел объясняет как их использовать. По поводу настройки сервера обращайтесь к <a href="http://postgresql.ru.net/manual/runtime-config.html" target="_blank">главе 18</a>.</div>
<div style="text-align: justify;">
<i>Checkpoints </i>- это точки в последовательности транзакций в которых гарантируется, что файлы данных heap и index содержат всю информацию, записанную до этой точки. На момент чекпойнта все страницы грязных данных записаны на диск и в лог-файл записана специальная запись чекпойнта. (Изменения перед этим записаны в WAL файлы). Если происходит падение, то процесс восстановления смотрит на последний чекпойнт, чтобы определить место в логах (известное как redo record), откуда должна быть начата операция REDO. Все изменения, сделанные до этого момента гарантированно записаны на диск. По этой причине все сегменты, расположенные до чекпойнта могут быть удалены или перезаписаны. (Когда происходит архивирование WAL - сегменты лога должны быть заархивированы <i>до</i> того, как они будут удалены или перезаписаны.)<br />
<a name='more'></a></div>
<div style="text-align: justify;">
Необходимость того, что все страницы грязных данных до создания чекпойнта должны быть записаны на диск может создать значительную I/O нагрузку. По этой причине эта нагрузка растягивается до начала следующего чекпойнта, что снижает влияние на производительность.</div>
<div style="text-align: justify;">
Фоновый процесс записи автоматически создаёт чекпойнты. Чекпойнт создаётся каждый <a href="http://postgresql-lab.blogspot.com/2013/01/185-write-ahead-log.html" target="_blank">checkpoint_segments</a> сегмент логов или каждую <a href="http://postgresql-lab.blogspot.com/2013/01/185-write-ahead-log.html" target="_blank">checkpoint_timeout</a> секунду, смотря что раньше. Значения по умолчанию - 3 сегмента и 300 секунд (5 минут). Кроме того, создать чекпойнт можно при помощи SQL команды CHECKPOINT.</div>
<div style="text-align: justify;">
Сокращение checkpoint_segments и / или checkpoint_timeout увеличивает частоту создания чекпойнтов. Такой подход позволяет ускорить восстановление после краха (так как меньше работы придётся делать); с другой же стороны это увеличивает нагрузку на диск. Если установлен <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">full_page_writes</a> (как и есть по умолчанию), то появляется ещё один фактор, который надо учитывать. В таком случае, чтобы быть уверенным в последовательности страниц данных, первое изменение страницы данных после каждого чекпойнта отражается в логе записью всей страницы. Теперь небольшой интервал между чекпойтами увеличивает объём WAL логов, частично снижая цель установки небольшого интервала, и, в любом случае, повышает нагрузку на диск.</div>
<div style="text-align: justify;">
Чекпойты относительно дороги. Во-первых, потому что они требуют записи всех текущих грязных буферов; а во-вторых, потому что они увеличивают WAL трафик, как говорилось выше. Таким образом лучше всего установить параметры чекпойнта достаточно большими, чтобы они происходили не так часто. Здравым способом проверить ваши параметры чекпойнтов является установка параметра <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">checkpoint_warning</a>. Если чекпойнты создаются чаще, чем checkpoint_warning секунд, сообщение в логах сервера порекомендует увеличить checkpoint_segments. Редкое появление таких сообщений не повод для тревоги, однако при их частом появлении следует увеличить параметры чекпойнтов. Объёмные операции, такие как объёмное копирование, могут увеличить число таких сообщений, если значение checkpoint_segments недостаточно высоко.</div>
<div style="text-align: justify;">
Чтобы избежать перегрузки системы ввода / вывода, запись грязных буферов при создании чекпойнта распределена во времени. Время, выделенное на эту запись контролируется параметром <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">checkpoint_completion_target</a>, который задаёт часть интервала чекпойнта. Интенсивность записи подгоняется таким образом, чтобы чекпойнт был записан по достижении указанной части WAL сегментов, созданных между чекпойнтами, или секунд между ними, смотря что быстрее. При значении по умолчанию в 0.5 PostgreSQL будет завершать запись каждого чекпойнта за половину времени до создания нового чекпойнта. На системах с большой нагрузкой на систему ввода/вывода имеет смысл увеличить значение checkpoint_completion_targt для снижения нагрузки от создания чекпойнтов. Обратная сторона такого решения заключается в том, что это увеличит время восстановления, так как придётся хранить больше WAL сегментов. Хотя checkpoint_completion_target может иметь значение и больше 1, всё же лучше бы оно было меньше 1 (например, 0.9), так как создание чекпойнта включает ещё некоторую деятельность, кроме записи грязных буферов. Если же значение checkpoint_completion_target будет 1.0, то практически наверняка создание чекпойнта не будет завершено вовремя, что приведёт к падению производительности из-за неожиданного изменения числа необходимых WAL сегментов.</div>
<div style="text-align: justify;">
Всегда должен быть как минимум один файл WAL сегмента, и их обычно не больше чем (2 + checkpoint_completion_target) * checkpoint_segments + 1 или checkpoint_segments + <a href="http://postgresql-lab.blogspot.com/2013/01/186-replication.html" target="_blank">wal_keep_segments</a> + 1 файл. Каждый файл сегмента обычно занимает 16Мб (хотя это значение может быть изменено при компиляции сервера). Используя это значение Вы можете подсчитать объём, необходимый для хранения WAL. Обычно, когда старые лог-файлы уже не нужны, они перезаписываются (и переименовываются, чтобы соответствовать новому номеру сегмента). Если (по причине всплеска создания лог-файлов) у Вас больше чем 3 * checkpoint_segments + 1 файл, то ненужные файлы будут просто удалены, чтобы не превышать установленный лимит.</div>
<div style="text-align: justify;">
В archive recovery или standby сервер периодически выполняет restartpoints (т.е. практически отметка, что чекпойнт был восстановлен), что похоже на checkpoint в обычном режиме: сервер сохраняет всё свое состояние на диск, обновляет pg_control файл, чтобы сообщить, что уже обработанные WAL данные не требуют повторной обработки, после чего рециркулируются все старые лог-файлы в каталоге pg_xlog. restartpoint срабатывает, если как минимум один чекпойнт был восстановлен и прошло checkpoint_timeout секунд с последнего restartpoint. В standby режиме restartpoint так же срабатывает если checkpoint_segments сегментов было восстановлено с последней restartpoint и был восстановлен хоть один чекпойнт. Restartpoint не может быть чаще, чем чекпойнты на мастере, так как restartpoint могут быть выполнены только для записей чекпойнтов.</div>
<div style="text-align: justify;">
Есть две часто используемые внутренние WAL функции: LogInsert и LogFlush. LogInsert используется для помещения новой записи в WAL буфер в общей памяти. Если там нет места для новой записи, LogInsert будет должен записать (переместив в кеш ядра) несколько заполненных WAL буферов. Это нежелательно, так как LogInsert используется для низкоуровневых модификаций БД (например, вставки строк) когда на нужных страницах памяти установлена эксклюзивная блокировка, так что эта операция должна быть проведена быстро. Что ещё хуже, запись WAL буферов может так же привести к созданию нового сегмента лога, что занимает ещё больше времени. Обычно WAL буферы должны быть записаны и скинуты на диск по запросу LogFlush, который обычно вызывается при завершении транзакции, чтобы убедиться, что записи транзакции сохранены в постоянное хранилище. На системах с большим количеством логов запросы LogFlush могут возникать не так часто, чтобы предотвратить создание записей LogInsert. На таких системах необходимо увеличить число WAL буферов, изменив параметр конфигурации wal_buffers. Значение по умолчанию - 8. Увеличение этого параметра приведёт к увеличению использования общей памяти. Если full_page_writes установлен и система очень занята, то увеличение этого параметра поможет сгладить время отклика в период непосредственно после каждой контрольной точки.</div>
<div style="text-align: justify;">
Параметр <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">commit_delay</a> определяет сколько микросекунд серверный процесс должен сделать паузу после записи подтверждения в лог при помощи LogInsert до выполнения LogFlush. Эта пауза позволяет другим серверным процесса добавить свои записи подтверждения в лог, чтобы потом все их вместе выгрузить на диск. Работа без паузы может возникнуть при отключённом <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">fsync</a> или если в активной транзакции меньше чем <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">commit_siblings</a> других сессий; в таком случае маловероятно что другие сессии сделают в ближайшее время подтверждение. Обратите внимание, что на большинстве платформ время паузы детализируется с точностью до миллисекунд, так что любое ненулевое значение commit_delay между 1 и 10000 (1000 наверно - прим. переводчика) микросекунд будет иметь один и тот же эффект. Хорошее значение этого параметра до сих пор не известно, так что экспериментируйте.</div>
<div style="text-align: justify;">
Параметр <a href="http://postgresql-lab.blogspot.ru/2013/01/185-write-ahead-log.html" target="_blank">wal_sync_method</a> определяет как PostgreSQL будет просить ядро записать обновления WAL на диск. Все параметры должны быть одинаковы с точки зрения надежности, за исключением fsync_writethrough, который иногда может принудительно писать на диск из кеша, даже если другие опции не указывают на это. Тем не менее в достаточной степени зависит от платформы то, какая из опций будет быстрее; проверить их скорости можно при помощи модуля <a href="http://postgresql-lab.blogspot.com/2013/01/f34-pgtestfsync.html" target="_blank">pg_test_fsync</a> модуля. Обратите внимание, что этот параметр не обращает внимание на iffsync.</div>
<div style="text-align: justify;">
Включение параметра конфигурации <a href="http://postgresql-lab.blogspot.com/2013/01/1817-developer-options.html" target="_blank">wal_debug</a> (доступен в PostgreSQL, который был скомпилирован с поддержкой этого) приведёт к тому, что каждый вызов LogInsert и LogFlush будет занесён в лог. Эта опция может быть в поздних версиях заменена на более общий механизм.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-21250546418294731442012-12-31T22:04:00.003-08:002013-01-01T01:27:21.156-08:00Инициализация Postgres в FreeBSD Jail и в Warden<div style="text-align: justify;">
Когда я попробовал вызвать скрипт Postgres rc.d c аргументом initdb, я получил сообщение об ошибке, связанное, как я потом понял, с тем, что я пытался сделать это в тюрьме. Ошибка была связана с общей памятью:<br />
<a name='more'></a></div>
<pre style="background-color: #f9f9f9; border: 1px dashed rgb(47, 111, 171); line-height: 1.1em; padding: 1em;">creating template1 database in /usr/local/pgsql/data/base/1 ... FATAL: could not create shared memory segment: Function not implemented
</pre>
<div style="text-align: justify;">
Решение было найдено на замечательном <a href="http://www.freebsddiary.org/jail-multiple.php" target="_blank">FreeBSD Diary</a>. Оказывается, мне нужно было изменить настройки sysctl на хосте, не в самой тюрьме, для того, чтобы разрешить операции с общей памятью. Для этого выполните</div>
<pre style="background-color: #f9f9f9; border: 1px dashed rgb(47, 111, 171); line-height: 1.1em; padding: 1em;">[tykling@wackbox ~]$ sudo sysctl security.jail.sysvipc_allowed=1
</pre>
<div style="text-align: justify;">
чтобы изменить текущее значение, и добавьте</div>
<pre style="background-color: #f9f9f9; border: 1px dashed rgb(47, 111, 171); line-height: 1.1em; padding: 1em;">security.jail.sysvipc_allowed=1
</pre>
<div style="text-align: justify;">
в /etc/sysctl.conf, чтобы это изменение сохранилось и после перезагрузки. Мне не потребовалось перезапускать тюрьму или делать ещё что-то после этих изменений, всё тут же сразу заработало. Кроме того, я добавил в этот rc.conf строку jail_sysvipc_allow="YES", чтобы разрешить PostgreSQL использовать общую память в тюрьме.<br />
Позже я обнаружил, что если я запускаю несколько Postgres серверов в разных тюрьмах на одном и том же физическом хосте FreeBSD, я должен внести ещё несколько изменений. Во-первых, опять же из той же статьи на <a href="http://www.freebsddiary.org/jail-multiple.php" target="_blank">FreeBSD Diary</a>, я узнал, что uid pgsql пользователя в тюрьмах должен отличаться или различные Postgres процессы будут повреждать общую память. Так что я использовал vipw для изменения uid, чтобы он был уникальным в каждой тюрьме:<br />
<pre style="background-color: #f9f9f9; border: 1px dashed rgb(47, 111, 171); line-height: 1.1em; padding: 1em;">$ cat /usr/jails/*/etc/passwd | grep pgsql
pgsql:*:2070:2070:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh
pgsql:*:1070:1070:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh
pgsql:*:70:70:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh
</pre>
Тут у меня есть три разные тюрьмы на одной машине, в каждой запущен Postgres и никто никому не мешает.<br />
Ещё проблемы с общей памятью. Когда я запускаю несколько экземпляров Postgres на одном сервере в тюрьмах, то количество общей памяти, выделяемой FreeBSD для этого оказывается недостаточным. Вот решение, которое я нашёл. Я не люблю просто копипастить всё, что пишут в интернете в свои конфиги; я стараюсь понять смысл каждой строки, перед тем, как t/ использовать. Но в этом случае я не имею никакого представления о том, правильно ли то, что тут указано и что вообще это делает (кроме того факта, что это связано с общей памятью). Часть этого из <a href="http://www.freebsddiary.org/jail-multiple.php" target="_blank">FreeBSD Diary</a>, что-то из рассылок и блогов:<br />
<pre style="background-color: #f9f9f9; border: 1px dashed rgb(47, 111, 171); line-height: 1.1em; padding: 1em;">$ cat /etc/sysctl.conf | egrep -i "ipc|postgres"
# for more shared memory for jails/PostgreSQL
kern.ipc.shmall=65536
kern.ipc.shmmax=134217728
kern.ipc.semmap=4096
$ cat /boot/loader.conf | egrep -i "ipc|postgres"
#for shared memory for postgresql
kern.ipc.shmmni=2048
kern.ipc.shmseg=2048
kern.ipc.semaem=32767
kern.ipc.semvmx=65534
kern.ipc.semusz=184
kern.ipc.semume=80
kern.ipc.semopm=200
kern.ipc.semmsl=120
kern.ipc.semmnu=4096
kern.ipc.semmns=8192
kern.ipc.semmni=32767
kern.ipc.semmap=60
</pre>
Всё это касается хоста, не тюрем. После этих манипуляций у меня получилось запустить initdb без каких-либо проблем.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<a href="http://wiki.tyk.nu/index.php?title=Installing_Postgres" target="_blank">Источник</a><br />
<br />
<h4>
Для тех, кто использует Warden</h4>
<div style="text-align: justify;">
Так как вчера вышла версия 9.1-RC3, у нас появились новые возможности относительно jail / warden. И одна из этих возможностей - устанавливать некоторые переменные для окружения jail. Что позволяет нам легко решить нашу проблему. Вот наши действия по шагам:</div>
<div style="text-align: justify;">
<ol>
<li>Обновляем настройки хоста, чтобы jail мог работать с raw socket</li>
<ol>
<li>Создаём или редактируем /etc/sysctl.conf:</li>
<table cellspacing="0" class="bbcode-rounded bbcode-rounded-code" style="background-color: #fafafa; background-position: 100% 0%; background-repeat: no-repeat no-repeat; color: black; font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif; font-size: 13px; margin: 3px auto 3px 20px; text-align: start;"><tbody>
<tr><td class="bbcode-rounded-header" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-top-color: rgb(204, 204, 204); border-top-style: solid; border-top-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
<tr><td class="bbcode-rounded-author" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; color: #666666; font-size: 10px; padding: 0px 4px 4px;"><div class="smallfont" style="font-size: 11px;">
Code:</div>
</td></tr>
<tr><td class="bbcode-rounded-content bbcode-rounded-content-code" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; font-size: 10pt; padding: 0px;"><pre dir="ltr" style="overflow: auto; padding: 0px 3px; width: 510px;"># for postgresql jail
security.jail.allow_raw_sockets=1
kern.ipc.shmall=65536
kern.ipc.shmmax=134217728
kern.ipc.semmap=4096</pre>
</td></tr>
<tr><td class="bbcode-rounded-footer" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-bottom-color: rgb(204, 204, 204); border-bottom-style: solid; border-bottom-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
</tbody></table>
<li>Перезагружаемся</li>
</ol>
<li>Создаём нашу тюрьму при помощи warden</li>
<ol>
<li>Используем новую возможность "установить" флаг</li>
<table cellspacing="0" class="bbcode-rounded bbcode-rounded-code" style="background-color: #fafafa; background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box_code.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; color: black; font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif; font-size: 13px; margin: 3px auto 3px 20px; text-align: start;"><tbody>
<tr><td class="bbcode-rounded-header" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-top-color: rgb(204, 204, 204); border-top-style: solid; border-top-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
<tr><td class="bbcode-rounded-author" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; color: #666666; font-size: 10px; padding: 0px 4px 4px;"><div class="smallfont" style="font-size: 11px;">
Code:</div>
</td></tr>
<tr><td class="bbcode-rounded-content bbcode-rounded-content-code" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; font-size: 10pt; padding: 0px;"><pre dir="ltr" style="overflow: auto; padding: 0px 3px; width: 510px;"># warden set flags xxx.yyy.zzz.ttt allow.raw_sockets=true,allow.sysvipc=true</pre>
</td></tr>
<tr><td class="bbcode-rounded-footer" style="background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-bottom-color: rgb(204, 204, 204); border-bottom-style: solid; border-bottom-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
</tbody></table>
<li>Заходим в тюрьму и устанавливаем postgresql (или делаем это через GUI)</li>
<table cellspacing="0" class="bbcode-rounded bbcode-rounded-code" style="background-color: #fafafa; background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box_code.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; color: black; font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif; font-size: 13px; margin: 3px auto 3px 20px; text-align: start;"><tbody>
<tr><td class="bbcode-rounded-header" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-top-color: rgb(204, 204, 204); border-top-style: solid; border-top-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
<tr><td class="bbcode-rounded-author" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; color: #666666; font-size: 10px; padding: 0px 4px 4px;"><div class="smallfont" style="font-size: 11px;">
Code:</div>
</td></tr>
<tr><td class="bbcode-rounded-content bbcode-rounded-content-code" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; font-size: 10pt; padding: 0px;"><pre dir="ltr" style="overflow: auto; padding: 0px 3px; width: 510px;"># cd /usr/ports/databases/postgresql
# make install clean</pre>
</td></tr>
<tr><td class="bbcode-rounded-footer" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-bottom-color: rgb(204, 204, 204); border-bottom-style: solid; border-bottom-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
</tbody></table>
<li>Добавляем автозапуск</li>
<table cellspacing="0" class="bbcode-rounded bbcode-rounded-code" style="background-color: #fafafa; background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box_code.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; color: black; font-family: verdana, geneva, lucida, 'lucida grande', arial, helvetica, sans-serif; font-size: 13px; margin: 3px auto 3px 20px; text-align: start;"><tbody>
<tr><td class="bbcode-rounded-header" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box1.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-top-color: rgb(204, 204, 204); border-top-style: solid; border-top-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
<tr><td class="bbcode-rounded-author" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; color: #666666; font-size: 10px; padding: 0px 4px 4px;"><div class="smallfont" style="font-size: 11px;">
Code:</div>
</td></tr>
<tr><td class="bbcode-rounded-content bbcode-rounded-content-code" style="border-left-color: rgb(204, 204, 204); border-left-style: solid; border-left-width: 1px; border-right-color: rgb(204, 204, 204); border-right-style: solid; border-right-width: 1px; font-size: 10pt; padding: 0px;"><pre dir="ltr" style="overflow: auto; padding: 0px 3px; width: 510px;">postgresql_enable="YES"</pre>
</td></tr>
<tr><td class="bbcode-rounded-footer" style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 100% 0%; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; line-height: 1px; margin: 0px; overflow: hidden; padding: 0px;"><div style="background-image: url(http://forums.pcbsd.org/images/ca_evo2_red/misc/bg_box2.gif); background-position: 0px -5px; background-repeat: no-repeat no-repeat; font-size: 1px; height: 5px; margin: 0px; overflow: hidden; padding: 0px 5px;">
<span style="border-bottom-color: rgb(204, 204, 204); border-bottom-style: solid; border-bottom-width: 1px; display: block; font-size: 1px; height: 4px; margin: 0px; overflow: hidden; padding: 0px;"></span></div>
</td></tr>
</tbody></table>
</ol>
</ol>
<div>
Готово!</div>
</div>
<div>
<a href="http://forums.pcbsd.org/showthread.php?t=16336" target="_blank">Источник</a></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-44866924684279991722012-12-31T05:13:00.000-08:002012-12-31T05:13:03.207-08:00pg_ctl<h4>
Имя</h4>
<div>
pg_ctl - инициализирует, запускает, останавливает и управляет PostgreSQL сервером</div>
<h4>
Краткий обзор</h4>
<div>
pg_ctl init[db] [-s] [-D <i>datadir</i>] [-o <i>initdb-options</i>]</div>
<div>
pg_ctl start [-w] [-t <i>seconds</i>] [-s] [-D <i>datadir</i>] [-I <i>filename</i>] [-o <i>options</i>] [-p <i>path</i>] [-c]</div>
<div>
pg_ctl stop [-W] [-t <i>seconds</i>] [-s] [-D <i>datadir</i>] [-m s[mart] | f[ast] | i[mmediate]]</div>
<div>
pg_ctl restart [-w] [-t <i>seconds</i>] [-s] [-D <i>datadir</i>] [-c] [-m s[mart] | f[ast] | i[mmediate]] [-o <i>options</i>]</div>
<div>
pg_ctl reload [-s] [-D <i>datadir</i>]</div>
<div>
pg_ctl status [-D <i>datadir</i>]</div>
<div>
pg_ctl promote [-s] [-D <i>datadir</i>]</div>
<div>
pg_ctl kill <i>signal_name process_id</i></div>
<div>
pg_ctl register [-N <i>servicename</i>] [-U <i>username</i>] [-P <i>password</i>] [-D <i>datadir</i>] [-S a[uto] | d[emand]] [-w] [-t <i>seconds</i>] [-s] [-o<i>options</i>]</div>
<div>
pg_ctl unregister [-N <i>servicename</i>]<br />
<a name='more'></a></div>
<h4>
Описание</h4>
<div style="text-align: justify;">
pg_ctl - это утилита для инициализации кластера БД PostgreSQL, запуска, остановки или перезапуска сервера (<a href="http://postgresql.ru.net/manual/app-postgres.html" target="_blank">postgres</a>), или отображения статуса запущенного сервера. Хотя сервер может быть запущен вручную, pg_ctl включает в себя такие возможности, как перенаправления вывода логов и корректное отключение от терминала. Кроме того это общепринятый способ остановки сервера.</div>
<div style="text-align: justify;">
Режимы init или initdb создаёт новый кластер БД PostgreSQL. Кластер БД - это набор БД, которые управляются одним экземпляром сервера. Этот режим использует команду <a href="http://postgresql-lab.blogspot.ru/2012/12/initdb.html" target="_blank">initdb</a>.</div>
<div style="text-align: justify;">
В режиме start запускается новый сервер. Запуск происходит в фоне и стандартный ввод прикрепляется к /dev/null (или nul в Windows). На UNIX-подобных системах по умолчанию стандартный вывод и вывод ошибок посылаются на стандартный вывод pg_ctl (а не на стандартный вывод ошибок). Стандартный вывод pg_ctl должен быть затем перенаправлен в файл или канал к другому процессу, например программе, ротирующей логи вроде rotatelogs. В противном случае postgres будет выводить информацию на управляющий терминал (из фонового режима) и не покинет группу процессов оболочки. На Windows по умолчанию стандартный вывод и вывод ошибок отправляются на терминал. Это поведение по умолчанию может быть изменено при помощи опции -l, чтобы перенаправить вывод сервера в файл логов. Рекомендуется использовать либо -l, либо перенаправление вывода.</div>
<div style="text-align: justify;">
В режиме stop запущенный в указанной директории сервер будет остановлен. Три разных метода остановки могут быть определены при помощи опции -m. Режим smart (по умолчанию) ожидает отключения всех активных клиентов и создания резервных копий онлайн перед отключением. Если сервер находится в режиме "горячего" резерва, восстановление и потоковая репликация будут прерваны сразу после отключения клиентов. Режим fast не ожидает отлючения клиентов и прерывает все создания резервных копий онлайн. Все активные транзакции откатываются назад, клиенты принудительно отключаются и сервер останавливается. Режим immediate немендленно останавливает сервер, без какой-либо подготовки. В результате, при следующем запуске будет запущен режим восстановления.</div>
<div style="text-align: justify;">
Режим restart сначала останавливает сервер, после чего снова запускает его. Таким образом можно изменить опции командной строки postgres.</div>
<div style="text-align: justify;">
Режим reload просто посылает процессу postgres сигнал SIGHUP, указывающий на необходимость перечитать конфигурационные файлы (postgresql.conf, pg_hba.conf и т.д.). Это позволяет изменить те опции конфигурации сервера, которые не требуют перезагрузки.</div>
<div style="text-align: justify;">
Режим status проверяет запущен ли сервер в указанной директории. Если сервер запущен, то отображаются его PID и опции командной строки.</div>
<div style="text-align: justify;">
В режиме promote резервный сервер, запущенный в указанной директории, выходит из режима восстановления и начинает выполнять операции на чтение-запись.</div>
<div style="text-align: justify;">
Режим kill позволяет послать сигнал указанному процессу. Особенно важно это для Microsoft Windows, где нет команды kill. Используйте --help чтобы увидеть список поддерживаемых сигналов.</div>
<div style="text-align: justify;">
Режим register позволяет Вам зарегистрировать сервис в Microsoft Windows. Опция -S позволяет выбрать тип запуска сервиса "auto" (автоматический запуск сервиса при запуске системы) или "demand" (запуск сервиса вручную).</div>
<div style="text-align: justify;">
Режим unregister позволяет отменить регистрацию сервиса в Microsoft Windows. Другими словами, это отменяет результат команды register.</div>
<h4>
Опции</h4>
<div>
<br />
-с<br />
<div style="text-align: justify;">
На тех платформах, где это возможно, пытается разрешить серверу создавать core файлы при падении, поднимая лимиты на эти файлы (by lifting any soft resource limit placed on core files). Это полезно при отладке или диагностике проблемы, позволяя отслеживать стек упавшего процесса сервера.</div>
<div style="text-align: justify;">
-D <i>datadir</i></div>
<div style="text-align: justify;">
Определяет расположение файлов БД. Если не указан, то используется переменная окружения PGDATA.</div>
<div style="text-align: justify;">
-l <i>filename</i></div>
<div style="text-align: justify;">
Направляет вывод лога сервера в <i>filename</i>. Если файла не существует, то он создаётся. Права доступа устанавливаются в 077, так что доступ к файлу логов по умолчанию закрыт для других пользователей.</div>
<div style="text-align: justify;">
-m <i>mode</i></div>
<div style="text-align: justify;">
Определяет режим выключения сервера. mode может быть smart, fast или immediate, причём можно указать только первую букву режима. Если не указано - используется режим smart</div>
<div style="text-align: justify;">
-o <i>options</i></div>
<div style="text-align: justify;">
Определяет опции, которые будут переданы непосредственно команде postgres</div>
<div style="text-align: justify;">
Эти опции скорее всего должны быть окружены одинарными или двойными кавычками, чтобы они точно были переданы как одна группа параметров</div>
<div style="text-align: justify;">
<i>-</i>o <i>initdb-options</i></div>
<div style="text-align: justify;">
Определяет опции, которые будут переданы непосредственно команде initdb.</div>
<div style="text-align: justify;">
Эти опции скорее всего должны быть окружены одинарными или двойными кавычками, чтобы они точно были переданы как одна группа параметров</div>
<div style="text-align: justify;">
<i>-</i>p <i>path</i></div>
<div style="text-align: justify;">
Задаёт расположение исполняемого файла postgres. По умолчанию он находится в той же папке, что и pg_ctl или же, если его там нет, то в папке установки. Потребность использовать эту опцию может возникнуть только если Вы делаете что-то странное и получаете сообщение об ошибке, что postgres не найден.</div>
<div style="text-align: justify;">
В режиме init эта опция аналогичным образом определяет место initdb.</div>
<div style="text-align: justify;">
<i>-</i>s</div>
<div style="text-align: justify;">
Выводит только сообщения об ошибках, без информационных сообщений</div>
<div style="text-align: justify;">
-t</div>
<div style="text-align: justify;">
Максимальное количество секунд ожидания запуска или остановки сервера. По умолчанию - 60 секунд</div>
<div style="text-align: justify;">
-w</div>
<div style="text-align: justify;">
Ожидать завершения запуска или выключения. Ожидание - опция по умолчанию для завершения работы, но не для запуска. В процессе ожидания запуска pg_ctl периодически пытается подключиться к серверу. В процессе ожидания выключения pg_ctl ждёт, пока сервер удалит свой PID файл. pg_ctl возвращает код выхода в зависимости от успеха запуска или завершения</div>
<div style="text-align: justify;">
-W</div>
<div style="text-align: justify;">
Не ожидать завершения запуска или выключения. Опция по умолчанию для режимов start и restart</div>
<h4>
Опции для Windows</h4>
<div>
-N <i>servicename</i></div>
<div>
Имя системного сервиса для регистрации. Это имя будем использоваться и как имя сервиса и как название для отображения</div>
<div>
-P <i>password</i></div>
<div>
Пароль для пользователя, который будет запускать сервис</div>
<div>
-S <i>start-type</i></div>
<div style="text-align: justify;">
Тип запуска сервиса "auto" (автоматический запуск сервиса при запуске системы) или "demand" (запуск сервиса вручную). Можно использовать первую букву названия типа. Если не указано - используется тип auto.</div>
<div>
-U<i> username</i></div>
<div style="text-align: justify;">
Имя пользователя для запуска сервиса. Для доменных имён используйте формат DOMAIN\username</div>
<h4>
Окружение</h4>
<div>
PGDATA</div>
<div>
Место хранения данных</div>
<div>
<span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">Эта утилита, как и многие другие утилиты PostgreSQL, использует переменные окружения, поддерживаемые libpq (см </span><a href="http://postgresql.ru.net/manual/libpq-envars.html" style="background-color: white; color: #888888; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px; text-decoration: initial;" target="_blank">раздел 31.13</a><span style="background-color: white; color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">). Более подробно об переменных сервера написано в <a href="http://postgresql.ru.net/manual/app-postgres.html" target="_blank">postgres</a>.</span></div>
<h4>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Файлы</span></span></h4>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">postmaster.pid</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Наличие этого файла в папке данных помогает pg_ctl определить, запущен ли данный сервер</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">postmaster.opts</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Если этот файл присутствует в папке данных, pg_ctl (в режиме restart) передаст содержимое этого файла в качестве опций postgres, если только это не переопределено опцией -o. Содержимое этого файла так же отображается в режиме status.</span></span></div>
<h4>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Примеры</span></span></h4>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;"><i><u>Запуск сервера</u></i></span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Для запуска сервера:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl start</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Для запуска сервера и ожидания пока сервер начнёт принимать соединения:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl -w start</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Для запуска сервера на порте 5433 и без fsync:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl -o "-F -p 5433" start</span></span></div>
<div>
<i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;"><u>Остановка сервера сервера</u></i></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;">Для остановки сервера:</span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl stop</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;">Опция -m позволяет контролировать способ остановки сервера:</span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;">$pg_ctl stop -m fast</span></div>
<div>
<i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;"><u>Перезапуск сервера</u></i></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Перзапуск сервера практически эквивалентен остановке сервера и последующему запуску, за исключением того, что pg_ctl сохраняет и заново использует опции командной строки, которые были переданы для предыдущего запуска. Для перезапуска сервера в простейшем случае:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl restart</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Для перезапуска сервера, ожидания его выключения и включения заново:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl -w restart</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Для перезапуска с запуском на порту 5433 и без использования fsync:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl -o "-F -p 5433" restart</span></span></div>
<div>
<i style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 12.800000190734863px; line-height: 18px;"><u>Просмотр статуса сервера</u></i></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Вот простой пример вывода статуса:</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">$ pg_ctl status</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">pg_ctl: server is running (PID: 13718)</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">/usr/local/pgsql/bin/postgres "-D" "/usr/local/pgsql/data" "-p" "5433" "-B" "128"</span></span></div>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">Эта командная строка и будет использоваться в режиме restart</span></span></div>
<h4>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;">См также</span></span></h4>
<div>
<span style="color: #222222; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 12.800000190734863px; line-height: 18px;"><a href="http://postgresql-lab.blogspot.ru/2012/12/initdb.html" target="_blank">initdb</a>, <a href="http://postgresql.ru.net/manual/app-postgres.html" target="_blank">postgres</a></span></span></div>
</div>
<div class="REFSECT1" style="font-family: verdana, sans-serif; font-size: 12px; margin: 0px; padding: 0px;">
</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-62932539058295215372012-12-31T00:10:00.002-08:002012-12-31T05:13:32.526-08:00initdb<h4>
Имя</h4>
<div>
initdb - создаёт новый кластер БД PostgreSQL</div>
<h4>
Краткий обзор</h4>
<div>
initdb [option...] -- pgdata | -D <i>directory</i><br />
<a name='more'></a></div>
<h4>
Описание</h4>
<div style="text-align: justify;">
initdb создаёт новый кластер БД PostgreSQL. Кластер БД - это набор БД, которые управляются одним экземпляром сервера.</div>
<div style="text-align: justify;">
Создание кластер БД состоит из создания директории, где будут храниться данные БД, создания общих таблиц (shared catalog tables) (таблицы, которые относятся ко всему кластеру, а не к какой-либо конкретной БД) и создания БД template1 и postgres. Когда Вы в будущем будете создавать новую БД, то в неё будет копироваться всё из БД template1. (Поэтому всё, установленное в template1 будет автоматически скопировано в каждую БД, созданную позже). БД postgres - это БД по умолчанию для работы пользователей, утилит и сторонних приложений.</div>
<div style="text-align: justify;">
Хотя initdb постарается создать заданную папку для данных, тем не менее он может не иметь разрешений сделать это, если родительской папкой или целевой папкой владеет root. В этом случае Вы должны создать новую папку под root, а затем изменить её владельца на пользователя БД, после чего используйте su для запуска из под этого пользователя initdb.</div>
<div style="text-align: justify;">
initdb должен быть запущен из под пользователя, который владеет самим серверным процессом, так как сервер должен иметь права доступа к файлам и папке, созданной initdb. Так как сервер не может быть запущен из-под root, то и initdb не стоит запускать из под него (на самом деле - у Вас это и не получится).</div>
<div style="text-align: justify;">
initdb инициализирует локаль по умолчанию и кодовую страницу для кластера БД. Кодировка, порядок сравнения (LC_COLLATE) и классы символов (LC_CTYPE, например upper, lower, digit) могут быть заданы для БД уже после её создания. initdb определяет настройки для template1, которые будут служить настройками по умолчанию для всех других БД.</div>
<div style="text-align: justify;">
Для того, чтобы изменить порядок сравнения по умолчанию или классы символов используйте опции --lc-collate и --lc-ctype. При этом имейте ввиду, что порядок сравнения, отличный от С или POSIX будет оказывать негативное влияние на производительность. По этому причине важно сделать правильный выбор локали перед запуском initdb.</div>
<div style="text-align: justify;">
Все остальные категории локали могут быть изменены позже, после того как сервер уже запущен. Кроме того, Вы можете использовать --locale для того, чтобы задать значение по умолчанию для всех категорий локали, включая порядок сравнения и классы символов. Все серверные значения локали (lc_*) можно посмотреть при помощи SHOW ALL. Более подробно об этом говорится в <a href="http://postgresql.ru.net/manual/locale.html" target="_blank">главе 22.1</a></div>
<div style="text-align: justify;">
Для изменения кодировки по умолчанию используйте --encoding. Более подробно об этом говорится в <a href="http://postgresql.ru.net/manual/multibyte.html" target="_blank">главе 22.1</a></div>
<h4>
Опции</h4>
<div style="text-align: justify;">
-A <i>authmethod</i></div>
<div style="text-align: justify;">
<i>--</i>auth=<i>authmethod</i></div>
<blockquote class="tr_bq">
Эта опция определяет метод аутентификации для локальных пользователей, используемый в pg_hba.conf. Не используйте метод trust, если Вы не доверяете всем локальным пользователям на вашей системе. trust является значением по умолчанию для простоты установки.</blockquote>
<div style="text-align: justify;">
-D <i>directory</i></div>
<div style="text-align: justify;">
<i>--</i>pgdata=<i>directory</i></div>
<blockquote class="tr_bq">
Эта опция определяет папку, где будет храниться кластер БД. Это единственная информация необходимая для initdb, но и её можно не указывать, если задать переменную окружения PGDATA при условии, что сервер и позже сможет найти кластер по этому адресу.</blockquote>
<div style="text-align: justify;">
-E <i>encoding</i></div>
<div style="text-align: justify;">
<i>--</i>encoding=<i>encoding</i></div>
<blockquote class="tr_bq">
Задаёт кодировку для шаблона БД. Эта же кодировка будет установлена для любой БД, которую Вы создадите позже, пока Вы не переопределите её в шаблоне. Значение по умолчанию наследуется из локальных настроек или устанавливается в SQL_ASCII. Набор поддерживаемых кодировок перечислен в <a href="http://postgresql.ru.net/manual/multibyte.html#MULTIBYTE-CHARSET-SUPPORTED" target="_blank">разделе 22.3.1</a></blockquote>
<div style="text-align: justify;">
--locale=<i>locale</i></div>
<blockquote class="tr_bq">
Устанавливает значение по умолчанию локали для кластера БД. Если эта опция не определена, то её значение наследуется из окружения, в котором запущена initdb. Поддерживаемые значения описаны в <a href="http://postgresql.ru.net/manual/locale.html" target="_blank">разделе 22.1</a></blockquote>
<div style="text-align: justify;">
--lc-collate=<i>locale</i></div>
<div style="text-align: justify;">
--lc-ctype=<i>locale</i></div>
<div style="text-align: justify;">
--lc-messages=<i>locale</i></div>
<div style="text-align: justify;">
--lc-monetary=<i>locale</i></div>
<div style="text-align: justify;">
--lc-numeric=<i>locale</i></div>
<div style="text-align: justify;">
--lc-time=<i>locale</i></div>
<blockquote class="tr_bq">
То же самое, что и --locale, но устанавливает значение только для указанной категории</blockquote>
<div style="text-align: justify;">
--pwfile=<i>filename</i></div>
<blockquote class="tr_bq">
Указывает initdb прочитать пароль суперпользователя БД из файла. В качестве пароля используется первая строка файла</blockquote>
<div style="text-align: justify;">
-U <i>username</i></div>
<div style="text-align: justify;">
--username=<i>username</i></div>
<blockquote class="tr_bq">
Указывает имя пользователя в качестве суперпользователя БД. По умолчанию используется имя пользователя, от которого был запущен initdb. На самом деле это имя практически не важно, но кто-то может захотеть сохранить именем суперпользователя postgres, даже если имя пользователя в системе отличается.</blockquote>
<div style="text-align: justify;">
-W</div>
<div style="text-align: justify;">
--pwprompt</div>
<blockquote class="tr_bq">
Указывает initdb на необходимость запросить пароль для суперпользователя БД. Если Вы не хотите использовать аутентификацию по паролю - эта опция Вам не нужна. В противном же случае Вы не сможете использовать аутентификацию по паролю до тех пор пока не зададите пароль.</blockquote>
<div style="text-align: justify;">
-X <i>directory</i></div>
<div style="text-align: justify;">
--xlogdir=<i>directory</i></div>
<blockquote class="tr_bq">
Эта опция определяет каталог где будет храниться лог транзакции</blockquote>
<div style="text-align: justify;">
Кроме того есть и другие, менее используемые параметры:</div>
<div style="text-align: justify;">
-d</div>
<div style="text-align: justify;">
--debug</div>
<blockquote class="tr_bq">
Показывает отладочный вывод от bootstrap и некоторые другие сообщения, не такие интересные среднему пользователю. bootstrap - это программа, которую использует initdb для создания общих таблиц. При использовании этой опции будьте готовы к появлению огромного количества жутко неинтересных сообщений.</blockquote>
<div style="text-align: justify;">
-L <i>directory</i></div>
<blockquote class="tr_bq">
Определяет место, где initdb должен найти файлы для инициализации кластера БД. Обычно это не требуется. Если же Вам это понадобится - то Вам об этом скажут.</blockquote>
<div style="text-align: justify;">
<i>-</i>n</div>
<div style="text-align: justify;">
--noclean</div>
<blockquote class="tr_bq">
По умолчанию, когда initdb видит, что какая-то ошибка не позволяет создать кластер БД, он удаляет все файлы, которые могли бы быть созданы до появления этой ошибки. Эта опция препятствует удалению этих файлов, которые могут быть полезны для отладки</blockquote>
<div style="text-align: justify;">
-V</div>
<div style="text-align: justify;">
--version</div>
<blockquote class="tr_bq">
Выводит версию initdb и завершает работу</blockquote>
<div style="text-align: justify;">
-?</div>
<div style="text-align: justify;">
--help</div>
<blockquote class="tr_bq">
Показывает помощь по команде initdb и завершает работу</blockquote>
<h4>
Окружение</h4>
<div>
PGDATA</div>
<blockquote class="tr_bq">
Определяет папку, где будет храниться кластер БД; может быть переопределено при помощи опции -D</blockquote>
<div>
Эта утилита, как и многие другие утилиты PostgreSQL, использует переменные окружения, поддерживаемые libpq (см <a href="http://postgresql.ru.net/manual/libpq-envars.html" target="_blank">раздел 31.13</a>)</div>
<h4>
Примечания</h4>
<div>
initdb так же может быть вызван при помощи pg_ctl initdb</div>
<h4>
См также</h4>
<div>
<a href="http://postgresql-lab.blogspot.ru/2012/12/pgctl.html" target="_blank">pg_ctl</a>, <a href="http://postgresql.ru.net/manual/app-postgres.html" target="_blank">postgres</a></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-29240723733764686702012-12-30T04:42:00.001-08:002013-01-10T06:25:48.166-08:0017.2. Создание кластера БД<br />
<br />
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif;"><a name='more'></a>Перед тем, как Вы сможете что-то сделать, Вы должны инициализировать область хранения БД на диске. Мы называем это </span><i style="font-family: verdana, sans-serif;">кластер базы данных (database cluster). </i><span style="font-family: verdana, sans-serif;">(SQL использует термин catalog cluster). Кластер БД - это набор баз данных, который управляется одним экземпляром запущенного сервера БД. После инициализации, кластер БД будет содержать БД с именем postgres, которая является БД по умолчанию, которую используют утилиты, пользователи и сторонние приложения. Сам сервер БД не нуждается в этой БД, но многие внешние приложения подразумевают, что она существует. Другая БД, создаваемая на этапе инициализации, называется template1. Как и следует из её имени, она будет использоваться как шаблон для создаваемых БД; она не должна использоваться для работы (см </span><a href="http://postgresql.ru.net/manual/managing-databases.html" style="font-family: verdana, sans-serif;" target="_blank">главу 21</a><span style="font-family: verdana, sans-serif;">, где рассказано о том, как создавать новые БД в кластере).</span></div>
<span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
В терминах файловой системы кластер БД - это просто папка, в которой хранятся все данные. Мы называем её <i>папка с данными (data directory)</i> или <i>область данных (data area).</i> Расположить её Вы можете где угодно. Вариантов по умолчанию нет, однако такие места, как /usr/local/pgsql/data или /var/lib/pgsql/data пользуются популярностью. Для того, чтобы инициализировать кластер БД мы используем команду <a href="http://postgresql.ru.net/manual/app-initdb.html" target="_blank">initdb</a>, которая устанавливается вместе с PostgreSQL. Желаемое месторасположение кластера БД указывается опцией -D:</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
$ initdb -D /usr/local/pgsql/data</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
Обратите внимание, что Вы должны выполнить эту команду из под аккаунта пользователя PostgreSQL, про которого мы говорили в предыдущей секции.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
<b>Совет:</b> в качестве альтернативы опции -D можно использовать переменную окружения PGDATA.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
С другой стороны, Вы можете запустить initdb при помощи <a href="http://postgresql.ru.net/manual/app-pg-ctl.html" target="_blank">pg_ctl</a>:</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
$ pg_ctl -D /usr/local/pgsql/data initdb</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
Такой способ может казаться более естественным, если Вы используете pg_ctl для запуска и остановки сервера (см <a href="http://postgresql.ru.net/manual/server-start.html" target="_blank">раздел 17.3</a>), так что pg_sql может быть единственной командой, которую Вы будете использовать для управления сервером БД.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
Если папка, которую Вы передали initdb в качестве параметра, не существует, то initdb попытается её создать. Скорее всего у него не будет для этого достаточно полномочий (если Вы следовали нашему совету и создали непривилегированного пользователя). В этом случае Вы должны создать папку сами (из под root) и изменить её владельца на пользователя PostgreSQL. Вот пример того, как Вы можете это сделать:</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
root# mkdir /usr/local/pgsql/data</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
root# chown postgres /usr/local/pgsql/data</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
root# su postgres</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
root# initdb -D /usr/local/pgsql/data</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
initdb не запустится если указанная папка выглядит как уже инициализированная.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
Поскольку папка данных содержит все данные, хранимые в БД, очевидно, что должны быть предприняты меры по предотвращению неавторизованного доступа. По этой причине оставит права доступа к папке только для пользователя PostgreSQL.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
Как бы то ни было, хотя содержимое папки конфиденциально, тем не менее настройки доступа по умолчанию позволяют любому пользователю подключиться к БД и даже стать суперпользователем БД. Если Вы не доверяете другим локальным пользователям, то мы рекомендуем использовать одну из опций initdb: -W, --pwprompt или --pwfile для того, чтобы задать пароль для суперпользователя БД. Кроме того передайте опцию -A md5 или -A password чтобы не использовать режим аутентификации по умолчанию. Или же измените сгенерированный после запуска initdb файл pg_hba.conf, но сделайте это <i>до</i> первого запуска сервера. (Есть и другие советы, включая peerauthentication или разрешения ФС. За подробностями обращайтесь к <a href="http://postgresql.ru.net/manual/client-authentication.html" target="_blank">главе 19</a>).</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
initdb так же инициализирует локаль по умолчанию для кластера БД. Обычно для этого берутся настройки локали в окружении и применяются к инициализируемой БД. При этом можно определить и другую локаль для БД; более подробную информацию об этом можно получить в <a href="http://postgresql.ru.net/manual/locale.html" target="_blank">главе 22.1</a>. Порядок сортировки по умолчанию используемый для конкретного кластера БД задаётся initdb. И хотя Вы можете создать новые БД с другим порядком сортировки, порядок сортировки используемый в шаблонных БД, создаваемых initdb, не может быть изменён без того, чтобы его сбросить и создать заново. Кроме того, использование локали, отличной от C или POSIX, может оказать влияние на производительность. Поэтому, очень важно сделать сразу правильный выбор.</div>
</span><span style="font-family: verdana, sans-serif;"><div style="text-align: justify;">
initdb так же задаёт кодировку по умолчанию для кластера БД. Обчно она должна соответствовать локальным настройкам. Более подробно это обсуждается в <a href="http://postgresql.ru.net/manual/multibyte.html" target="_blank">главе 22.3</a></div>
</span><br />
<h2>
17.2.1 Сетевые файловые системы</h2>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif;">Зачастую при установке кластеры БД создаются на сетевых ФС. Иногда это делается непосредственно при помощи NFS, или с использованием NAS-устройств, которые сами используют NFS. PostgreSQL не требует специальной настройки для использования сетевых ФС в том случае, если они ведут себя в точности как локальные диски (DAS, Direct Attached Storage). Если же клиентская и серверная реализации NFS имеют нестанадртную семантику, то Вы можете столкнуться с проблемами (см <a href="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html" target="_blank">тут</a>). В частности, отложенная (асинхронная) запись на NFS сервер может создать проблемы с надёжностью. Поэтому, если возможно, монтируйте NFS в синхронном режиме (без кеширования). Кроме того, мягкое монтироване (soft-mounting) NFS тоже не рекомендуется. (SAN используют протокол нижнего уровня отличный от NFS.)</span></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-66815620921654823092012-12-29T22:35:00.002-08:002013-01-10T06:25:48.178-08:0017.1. PostgreSQL аккаунты пользователей<br />
<h1 class="SECT1" style="margin: 0px; padding: 0px; text-align: justify;">
<span style="font-family: verdana, sans-serif; font-size: 12px; font-weight: normal;">Как и любой серверный демон, доступный снаружи, рекомендуется запускать </span><span class="PRODUCTNAME" style="font-family: verdana, sans-serif; font-size: 12px; font-weight: normal;">PostgreSQL под отдельным пользователем. Этот аккаунт должен владеть только теми данными, которые управляются серверами и не должен использоваться другими демонами (поэтому, например, использовать пользователя nobody - плохая идея</span><span style="font-family: verdana, sans-serif;"><span style="font-size: 12px; font-weight: normal;">.) Не рекомендуется устанавливать исполняемые файлы под этим пользователем, так как на скомпрометированной системе они могут быть изменены.</span></span></h1>
<div style="text-align: justify;">
<span style="font-family: verdana, sans-serif;"><span style="font-size: 12px; font-weight: normal;">Для того чтобы добавить пользователя на свою систему используйте команды </span></span><tt class="COMMAND" style="font-size: 12px; text-align: justify;">useradd</tt><span style="font-family: verdana, sans-serif; font-size: 12px; text-align: justify;"> или</span><span style="font-family: verdana, sans-serif; font-size: 12px; text-align: justify;"> </span><tt class="COMMAND" style="font-size: 12px; text-align: justify;">adduser</tt><span style="font-family: verdana, sans-serif; font-size: 12px; text-align: justify;">. Чаще всего используется имя </span><span class="SYSTEMITEM" style="font-family: verdana, sans-serif; font-size: 12px; text-align: justify;">postgres и его мы и будем использовать в этом руководстве. Но Вы можете использовать любое имя на свой вкус</span><span style="font-family: verdana, sans-serif; font-size: 12px; text-align: justify;">.</span></div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0tag:blogger.com,1999:blog-3495458762343321167.post-62903223720654689732012-12-27T22:55:00.000-08:002013-01-21T03:58:28.628-08:00Глава 25.2 Резервные сервера на основе пересылки логов<h1 style="text-align: center;">
</h1>
<h2 style="text-align: justify;">
</h2>
<div style="text-align: justify;">
Непрерывное архивирование может быть использовано для создания конфигурации <i>высоко доступного</i> (HA) кластера с одним или несколькими <i>резервными серверами</i>, готовыми принять на себя работу, если основной сервер выходит из строя. Эта возможность широко известна под именем <i>"теплый" режим ожидания</i> или <i>передача логов</i>.</div>
<div style="text-align: justify;">
Основной и резервный сервера работают вместе, чтобы обеспечить эту функциональность, хотя сами сервера слабо связаны. Мастер-сервер работает в непрерывном режиме архивирования, а каждый резервный сервер работает в непрерывном режиме восстановления, читая WAL файлы от мастера. Не требуется никаких изменений в таблицах базы данных чтобы включить эту возможность, так что этот метод не требует накладных расходов для настройки по сравнению с некоторыми другими видами репликации. Эта конфигурация также имеет относительно низкое влияние на производительность мастер сервера.</div>
<div style="text-align: justify;">
Непосредственное перемещение WAL записей с одного сервера баз данных на другой, как правило, называется "передачей логов". PostgreSQL реализует передачу файлов логов пересылая WAL записи, один файл (WAL сегмент) за раз. WAL файлы (16 МБ) могут быть легко и дешево переданы на любое расстояние, будь то соседняя система, другая система на этом же сайте, или другая система на другом конце земного шара. Пропускная способность, требуемая для этого, зависит от частоты транзакций основного сервера. Доставка логов на основе записей более детальна и передаёт WAL изменения инкрементально через сетевое подключение (см. раздел 25.2.5 ).<br />
<a name='more'></a></div>
<div style="text-align: justify;">
Следует отметить, что доставка логов асинхронна, то есть WAL записи передаются после подтверждения транзакции. В результате есть зазор потери данных в случае если основной сервер упадёт: не отправленные транзакции будут потеряны. Размер окна потери данных при такой пересылке логов может быть ограничен параметром <tt>archive_timeout</tt>, который может быть равен нескольким секундам. Однако такое значение существенно увеличит требования к пропускной способности, необходимой для пересылки файлов. Потоковая репликация (см. раздел 25.2.5 ) позволяет значительно сократить это окно.</div>
<div style="text-align: justify;">
Скорость восстановления достаточно хороша, так как резервный сервер как правило, находится всего в нескольких шагах от полной доступности после того, как он был активирован. В результате, эта конфигурация называется "теплым" резервом, так как она предлагает высокую доступность. Восстановление сервера из архива резервной копии базы и повтор транзакций займёт значительно больше времени, так что такой подход актуален только для аварийного восстановления, а не для обеспечения высокой доступности. Резервный сервер также может использоваться для запросов на чтение данных; в этом случае он называется "горячий" резервный сервер. В разделе 25.5 мы поговорим об этом подробнее.</div>
<h2 style="text-align: justify;">
25.2.1. Планирование.</h2>
<div style="text-align: justify;">
Мудрым ходом будет создать мастер и резервный серверы так, чтобы они были похожи, как минимум с точки зрения сервера баз данных. В частности, имена путей, связанные с пространством имён таблиц будут передаваться без изменений, поэтому основной и резервный серверы должны иметь одинаковые пути монтирования для пространств имён таблиц, если Вы используете эту возможность. Имейте в виду, что если <a href="http://www.postgresql.org/docs/9.1/interactive/sql-createtablespace.html">CREATE TABLESPACE</a> выполнен на основном сервере, любую новую точку монтирования, в которой есть потребность, необходимо создать на мастере и резервном сервере до того, как будет выполнена эта команда. Оборудование не обязательно должно быть идентичным, но опыт показывает, что обслуживание двух идентичных систем проще, чем разнородных в течение всего срока использования приложения и этой системы. В любом случае, аппаратная архитектура должна быть одинаковой - пересылка от, скажем, 32-разрядной к 64-разрядной системе работать не будет.</div>
<div style="text-align: justify;">
Обычно пересылка журналов между серверами под управлением различных мажорных релизов PostgreSQL не возможна. Такова политика PostgreSQL Global Development Group: не вносить изменения в формат диска в минорных релизах, так что вполне вероятно, что запуск различных минорных релизов на мастере и резервном сервере будет успешно работать. Тем не менее, в этом случае не даётся никаких гарантий и обещаний поддержки и мы советуем вам держать основной и резервный серверы на одинаковых релизах как можно дольше. При обновлении на новый минорный релиз, безопасней всего обновить сперва резервные серверы - более вероятно, что новый минорный релиз сможет читать WAL файлы предыдущего минорного релиза, чем наоборот.</div>
<h2 style="text-align: justify;">
25.2.2. Операции на резервном сервере</h2>
<div style="text-align: justify;">
В режиме ожидания сервер непрерывно применяет WAL, полученные от главного сервера. Резервный сервер может читать WAL из WAL архива (см. <a href="http://www.postgresql.org/docs/9.1/interactive/archive-recovery-settings.html#RESTORE-COMMAND">restore_command</a>) или непосредственно с мастера через TCP соединение (потоковая репликация). Резервный сервер также будет пытаться восстановить любой WAL, найденный в каталоге <tt>pg_xlog</tt> резервного кластера. Обычно это происходит после перезапуска сервера, когда резервный сервер воспроизводит WAL, переданный от мастера до перезагрузки, но Вы также можете вручную скопировать файлы в <tt>pg_xlog</tt> в любое время, чтобы они были применены.</div>
<div style="text-align: justify;">
При запуске резервный сервер начинает с восстановления всех WAL, находящихся в архиве, вызывая <tt>restore_command.</tt> Как только он достигает конца доступного WAL и <tt>restore_command</tt> выдаёт ошибку, он пытается восстановить любой WAL доступный в каталоге <tt>pg_xlog</tt>. Если и это не удается, и настроена потоковая репликация, резервный сервер попытается подключиться к основному серверу и запустить поток WAL после последней корректной записи в архиве или <tt>pg_xlog.</tt> Если и это не удается или потоковая репликация не настроена, или же если соединение разрывается, резервный сервер возвращается к шагу 1 и пытается снова восстановить файл из архива. Этот цикл попыток восстановления из архива, <tt>pg_xlog,</tt> и через потоковую репликацию продолжается пока сервер не будет остановлен или не возникнет ошибка на основном сервере и не будет вызван триггер файл.</div>
<div style="text-align: justify;">
Режим ожидания завершается и сервер переключается в обычный режим либо когда запускается <tt>pg_ctl promote</tt> либо когда обнаруживается триггер-файл <tt>(trigger_file).</tt> До возникновения ошибки любой WAL доступный в архиве или в <tt>pg_xlog</tt> будет немедленно восстановлен, но попыток подключиться к мастеру не происходит.</div>
<h2 style="text-align: justify;">
25.2.3. Подготовка мастера для резервных серверов</h2>
<div style="text-align: justify;">
Настройте непрерывное архивирование на мастере в любую директорию директорию, доступную для резервного сервера, как это описано в <a href="http://postgresql.ru.net/manual/continuous-archiving.html" target="_blank">разделе 24.3</a>. Место, отведённое под архивирование, должно быть доступным для резервного сервера даже когда мастер выключен, т.е. оно должно находиться на самом резервном сервере или другом доверенном сервере, а не на главном сервере.</div>
<div style="text-align: justify;">
Если вы хотите использовать потоковую репликацию, настройте аутентификацию на мастере, чтобы разрешить подключения для репликации от резервного серера, то есть, создайте роль и подходящие записи в <tt>pg_hba.conf</tt>, где поле базы данных имеет значение <tt>replication</tt>. Также убедитесь, что <tt>max_wal_senders</tt> имеет на достаточно большое значение в файле конфигурации мастера.</div>
<div style="text-align: justify;">
Используйте базовый бакуп, как это описано в <a href="http://www.postgresql.org/docs/9.1/interactive/continuous-archiving.html#BACKUP-BASE-BACKUP">разделе 24.3.2</a> для начальной загрузки на резервный сервер.</div>
<h2 style="text-align: justify;">
25.2.4. Настройка резервного сервера</h2>
<div style="text-align: justify;">
Чтобы настроить резервный сервер, восстановите базу из резервной копии, полученной с основного сервера (см. <a href="http://www.postgresql.org/docs/9.1/interactive/continuous-archiving.html#BACKUP-PITR-RECOVERY">раздел 24.3.3</a> ). Создайте коммандный файл восстановления <tt>recovery.conf</tt> в каталоге с данными резервного кластера и включите режим <tt>standby_mode.</tt> Задайте в качестве <tt>restore_command</tt> простую команду копирования файлов из архива WAL. Если вы планируете иметь несколько резервных серверов для обеспечения высокой доступности, установите <tt>recovery_target_timeline</tt> в значение <tt>latest</tt>, чтобы резервный сервер следовал хронике изменений, которые происходят при ошибке на другом резервном сервере.</div>
<blockquote>
<div style="text-align: justify;">
<b>Примечание:</b> Не используйте pg_standby или аналогичные инструменты вместе со встроенным режимом ожидания, описаным здесь. <tt>restore_command</tt> должна немедленно завершиться, если файл не существует, сервер повторит команду снова, если это необходимо. См. <a href="http://www.postgresql.org/docs/9.1/interactive/log-shipping-alternative.html">раздел 25,4</a> по поводу использования таких инструментов, как pg_standby.</div>
</blockquote>
<div style="text-align: justify;">
Если вы хотите использовать потоковую репликацию, задайте значение <tt>primary_conninfo</tt> строкой соединения libpq, включающей имя хоста (или IP-адрес) и любые дополнительные данные, необходимые для подключения к основному серверу. Если мастер требует пароль для авторизации, то пароль тоже должен быть указанн в <tt>primary_conninfo</tt>.</div>
<div style="text-align: justify;">
Если вы настраиваете резервный сервер для обеспечения высокой доступности, настройте WAL архивирование, связь и аутентификацию, как на главном сервере, потому что резернвый сервер будет работать в качестве первичного сервера после сбоя мастера.</div>
<div style="text-align: justify;">
Если вы используете WAL архив, его размер может быть уменьшен при помощи параметра <a href="http://www.postgresql.org/docs/9.1/interactive/archive-recovery-settings.html#ARCHIVE-CLEANUP-COMMAND">archive_cleanup_command</a>, удаляющего файлы, которые больше не требуются резервному серверу. Утилита pg_archivecleanup предназначена для использования с <tt>archive_cleanup_command</tt> в типичных конфигурациях с одним резервным сервером, см. <a href="http://www.postgresql.org/docs/9.1/interactive/pgarchivecleanup.html">pg_archivecleanup</a>. Заметим, однако, что если Вы используете архив для целей резервного копирования, Вы должны хранить файлы, необходимые для восстановления как минимум последней резервной копии базы, даже если они больше не нужны резервному серверу.</div>
<div style="text-align: justify;">
Вот простой пример <tt>recovery.conf</tt>:</div>
<div style="text-align: justify;">
<br /></div>
<pre class="PROGRAMLISTING"><div style="text-align: justify;">
<span style="white-space: pre-wrap;">standby_mode = 'on'</span></div>
</pre>
<pre class="PROGRAMLISTING"><span class="goog-gtc-unit" id="goog-gtc-unit-224" style="white-space: pre-wrap;"><span class="goog-gtc-translatable" dir="ltr" gtc:wc="9">primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'</span></span>
<span class="goog-gtc-unit" id="goog-gtc-unit-225" style="white-space: pre-wrap;"><span class="goog-gtc-translatable" dir="ltr" gtc:wc="7">restore_command = 'cp /path/to/archive/%f %p'</span></span>
<span class="goog-gtc-unit" id="goog-gtc-unit-226" style="white-space: pre-wrap;"><span class="goog-gtc-translatable" dir="ltr" gtc:wc="6">archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'</span></span></pre>
<pre class="PROGRAMLISTING"></pre>
<div style="text-align: justify;">
Вы можете иметь любое количество резервных серверов, но если вы используете потоковую репликацию, убедитесь, что ваше значение <tt>max_wal_senders</tt> на мастере достаточно велико, чтобы позволить всем остальным серверам подключиться к нему одновременно.</div>
<h2 style="text-align: justify;">
25.2.5. Потоковая репликация</h2>
<div style="text-align: justify;">
Потоковая репликация позволяет резервному серверу поддерживать большую актуальность данных, чем это возможно на основе пересылки файлов журналов. Резервный сервер подключается к мастеру, который передаёт WAL записи резервному серверу по мере их создания, не дожидаясь, пока WAL файл будет заполнен.</div>
<div style="text-align: justify;">
Потоковая репликация является асинхронной, так что всё еще есть небольшая задержка между совершением транзакции на мастере и тем, что изменения будут видны на резервном сервере. Эта задержка, однако, намного меньше, чем в случае пересылки файлов журнала; обычно это где-то одна секунда, если предположить, что резервный сервер достаточно мощен, чтобы идти в ногу с нагрузкой. При потоковой репликации не требуется <tt>archive_timeout</tt> для уменьшения окна потери данных.</div>
<div style="text-align: justify;">
Если вы используете потоковую репликацию без файлового непрерывного архивирования, вы должны задать для параметра <tt>wal_keep_segments</tt> на мастере достаточно высокое значение, чтобы быть уверенным, что старые сегменты WAL не слишком рано удаляются, в то время как резервный сервер может всё ещё нуждаться в них. Если резервнвый сервер слишком сильно отстаёт, его нужно реинициализировать из новой резервной копии базы. Если вы создали архив WAL, который доступн для резервных серверов, <tt>wal_keep_segments</tt> не требуется, поскольку резервные сервера всегда могут воспользоваться архивом, чтобы наверстать упущенное.</div>
<div style="text-align: justify;">
Для использования потоковой репликации настройте резервный сервер для пересылки журналов, как описано в <a href="http://www.postgresql.org/docs/9.1/interactive/warm-standby.html">разделе 25.2</a> . Шаг, который превращает резервный сервер на основе пересылки файлов журналов в сервер на основе потокового репликации - установка <tt>primary_conninfo</tt> в файл <tt>recovery.conf</tt> указывающий на основной сервер. Задайте <a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-LISTEN-ADDRESSES">listen_addresses</a> и опции аутентификации (см. <tt>pg_hba.conf)</tt> на мастере, так чтобы резервный сервер мог подключиться к псевдобазе <tt>replication</tt> на мастер-сервере (см. <a href="http://www.postgresql.org/docs/9.1/interactive/warm-standby.html#STREAMING-REPLICATION-AUTHENTICATION">раздел 25.2.5.1</a> ).</div>
<div style="text-align: justify;">
В системах, которые поддерживают keepalive опцию сокета, задание <a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-TCP-KEEPALIVES-IDLE">tcp_keepalives_idle</a>, <a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-TCP-KEEPALIVES-INTERVAL">tcp_keepalives_interval</a> и <a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-connection.html#GUC-TCP-KEEPALIVES-COUNT">tcp_keepalives_count</a> помогает мастеру оперативно заметить сломанные связи.</div>
<div style="text-align: justify;">
Установите максимальное число одновременных соединений от резервных серверов (см. <a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-replication.html#GUC-MAX-WAL-SENDERS">max_wal_senders</a> где об этом говорится подробнее).</div>
<div style="text-align: justify;">
Если резервный сервер запускается и <tt>primary_conninfo</tt> настроен правильно, то в режиме ожидания он будет подключаться к мастеру после применения всех файлов WAL, доступных в архиве. Если соединение установлено, Вы увидите процесс walreceiver на резервном сервере, и соответствующий процесс walsender на мастере.</div>
<h3 style="text-align: justify;">
25.2.5.1. Аутентификация</h3>
<div style="text-align: justify;">
Очень важно, чтобы права доступа для епликации были настроена так, чтобы только доверенные пользователи могли читать WAL поток, потому что из них очень легко извлечь привилегированную информацию. Резервные серверы должны быть идентифицированы мастером как имеющие привелегии <tt>REPLICATION.</tt> Таким образом, на мастере должны быть заданы привилегии <tt>REPLICATION</tt> и <tt>LOGIN</tt>.</div>
<blockquote>
<div style="text-align: justify;">
<b>Примечание:</b> Рекомендуется использовать выделенного пользователя для репликации. Хотя привилегия <tt>REPLICATION</tt> предоставляется по умолчанию учетной записи суперпользователя, не рекомендуется использовать эту учетную запись для репликации. Хотя привилегия <tt>REPLICATION</tt> дает очень высокие разрешения, она не позволяет пользователю изменять любые данные на основной системе, что даёт привилегия <tt>SUPERUSER</tt>.</div>
</blockquote>
<div style="text-align: justify;">
Аутентификация клиента для репликации контролируется записями в <tt>pg_hba.conf</tt>, где в поле <tt class="REPLACEABLE c2">database</tt> стоит <tt>replication</tt>. Например, если резервный сервер запущен на хосте с IP <tt>192.168.1.100</tt> и имя учетной записи для репликации - <tt>foo</tt>, то администратор может добавить следующую строку в файл <tt>pg_hba.conf</tt> на мастере:</div>
<pre class="PROGRAMLISTING"><div style="text-align: justify;">
# Разрешить пользователю "foo" с хоста 192.168.1.100 подключения к мастеру</div>
<div style="text-align: justify;">
# в качестве резервного сервера для репликации, если правильно указан пароль.</div>
#
# TYPE DATABASE USER ADDRESS METHOD
<div style="text-align: justify;">
</div>
host replication foo 192.168.1.100/32 md5
</pre>
<div style="text-align: justify;">
Имя хоста и номер порта мастера, имя пользователя для подключения и пароль, указанны в файле <tt>recovery.conf</tt>. Пароль также может быть задан в файле <tt>~/.pgpass</tt> на резервном сервере (если в поле database указано <tt>replication</tt>). Например, если мастер работате на хосте с IP <tt>192.168.1.50</tt>, порт <tt>5432</tt>, имя учетной записи для репликации <tt>foo</tt>, пароль <tt>foopass</tt>, то администратор может добавить следующую строку в файл <tt>recovery.conf</tt> на резервном сервере:</div>
<pre class="PROGRAMLISTING"><div style="text-align: justify;">
# Резервный сервер подключается к мастеру, который работает на хосте 192.168.1.50</div>
# с портом 5432, в качестве пользователя "foo" с паролем "foopass".
<div style="text-align: justify;">
<pre class="PROGRAMLISTING" style="text-align: start;"><span class="goog-gtc-unit" id="goog-gtc-unit-329" style="white-space: pre-wrap;"><span class="goog-gtc-translatable goog-gtc-unit-highlight" dir="ltr" gtc:wc="9" style="background-color: white;">primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass</span></span></pre>
</div>
</pre>
<h3 style="text-align: justify;">
25.2.5.2. Мониторинг</h3>
<div style="text-align: justify;">
Важным показателем "здоровья" потоковой репликации является количество WAL записей, созданных на мастере, но ещё не применённых на резервном сервере. Вы можете вычислить это отставание сравнивая текущие записи WAL на мастере с последними WAL, полученными на резервном сервере. Они могут быть получены с помощью <tt>pg_current_xlog_location</tt> на мастере и <tt>pg_last_xlog_receive_location</tt> на резервном сервере соответственно (см. <a href="http://www.postgresql.org/docs/9.1/interactive/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE">таблицу 9-56</a> и <a href="http://www.postgresql.org/docs/9.1/interactive/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE">таблицу 9-57</a> в поисках деталей). Последний WAL, полученный резервным сервером также отображается в статусе процесса получения WAL, увидеть который можно с помощью команды <tt>ps</tt> (см. <a href="http://www.postgresql.org/docs/9.1/interactive/monitoring-ps.html">раздел 27.1</a>).</div>
<div style="text-align: justify;">
Вы можете получить список процессов-отправителей WAL при помощи <a href="http://www.postgresql.org/docs/9.1/interactive/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE"><tt>pg_stat_replication</tt></a>. Большая разница между <tt>pg_current_xlog_location</tt> и <tt>sent_location</tt> может указывать на то, что мастер находится под большой нагрузкой, в то время как различия между <tt>sent_location</tt> и <tt>pg_last_xlog_receive_location</tt> на резервном сервере может указывать на задержки в сети, или на большую нагрузку на резервный сервер.</div>
<h2 style="text-align: justify;">
25.2.6. Синхронная репликация</h2>
<div style="text-align: justify;">
PostgreSQL потоковая репликация по умолчанию является асинхронной. Если основной сервер выходит из строя, в таком случае некоторые транзакции, которые были подтверждены, могут быть не реплицированы на резервный сервер, в результате чего может произойти потеря данных. Количество потерянных данных будет пропорционально задержке репликации в момент краха мастера.</div>
<div style="text-align: justify;">
Синхронная репликация предоставляет возможность быть уверенным, что все изменения, сделанные транзакцией были переданы одному синхронному резервному серверу. Это расширяет стандартный уровень надёжности, предоставляемой транзакциями. Этот уровень защиты называют 2-жды безопасной репликацией в computer science theory.</div>
<div style="text-align: justify;">
При запросе синхронной репликации, каждое подтверждение транзакции на запись будет отложено до тех пор, пока не придёт подтверждение, что транзакция была записана в журнал транзакций на дисках основного и резервного серверов. Единственная возможность, где данные могут быть потеряны - когда мастер и резервный сервера засбоят в одно и то же время. Такая репликация может обеспечить более высокий уровень надёжности, но только в том случае, если системный администратор внимательно отнесётся к размещению и управлению двумя серверами. Ожидание подтверждение повышает уверенность пользователей, что изменения не будут потеряны в случае аварии сервера, но также обязательно увеличивает время отклика для запрашивающего транзакцию. Минимальное время ожидания составляет время обмена информацией в оба конца, между мастером и резервным сервером.</div>
<div style="text-align: justify;">
Транзакции только на чтение и отмена транзакций не требуют ожидания ответа от резервных серверов. Подтверждение подтранзакций так же не требует ожидания ответа от резервных серверов, только подтверждения транзакции верхнего уровня. Длительные действия, такие как загрузка данных или построение индекса тоже не требует ожидания выполнения. Все двухфазные подтверждения требуют ожидания подтверждения, в том числе подготовка и завершение.</div>
<h3 style="text-align: justify;">
25.2.6.1. Базовая конфигурация</h3>
<div style="text-align: justify;">
После настройки потоковой репликации настройка синхронной репликации требует только одного дополнительного шага:<a href="http://www.postgresql.org/docs/9.1/interactive/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES">synchronous_standby_names</a> должно быть задано непустое значение. <tt>synchronous_commit</tt> также должно быть присвоено значение <tt>on</tt>, но, так как это является значением по умолчанию, как правило, никаких изменений не требуется. Эта конфигурация заставляет мастера после каждой транзакции ожидать подтверждения что резервный сервер записал транзакцию в надёжное хранилище, даже если это занимает очень много времени. <tt>synchronous_commit</tt> может быть установлен отдельными пользователями, поэтому его можно настроить в файле конфигурации для конкретных пользователей или баз данных, или настроить его динамически для приложениий, для того, чтобы контролировать надёжность на уровне транзакций.</div>
<div style="text-align: justify;">
После подтверждения того, что запись была записана на диск мастера, WAL запись затем отправляется к резервному серверу. Резервный сервер посылает ответное сообщение каждый раз, когда новая партия WAL данных записывается на диск, если <tt>wal_receiver_status_interval</tt> не установлен в нуль на неё. Если резервный сервер является первым соответствующим сервером, указанным в <tt>synchronous_standby_names</tt> на мастере, ответное сообщение от этого сервера будет использовано для прекращения ожидания пользователями подтверждения того, что уведомление о фиксации записи было получено. Эти параметры позволяют администратору определить резервные сервера, которые должны быть синхронными. Обратите внимание, что конфигурация синхронной репликации в основном проводится на мастере.</div>
<div style="text-align: justify;">
Ожидание пользователей будет прервано если будет запрошено быстрое выключение. Однако, как и при использовании асинхронной репликации, сервер не будет полностью остановлен до тех пор, пока все невыполненные WAL записи не будут переданы подключённым в данный момент резервным серверам. </div>
<h3 style="text-align: justify;">
25.2.6.2. Планирование производительности</h3>
<div style="text-align: justify;">
Синхронная репликация, как правило, требует тщательной планировки и правильного размещения резервных серверов для обеспечения приемлемой производительности приложений. Ожидание не использует системные ресурсы, но блокировки транзакции сохраняются до подтверждения транзакции. В результате неосторожного использования синхронной репликации может уменьшиться производительность приложений баз данных из-за увеличения времени отклика и высокой конкуренции (higher contention).</div>
<div style="text-align: justify;">
PostgreSQL позволяет разработчикам приложений определить требуемый уровень надёжности с помощью репликации. Он может быть определен для системы в целом,или для конкретного пользователя или подключения, или даже для отдельных операций.</div>
<div style="text-align: justify;">
Например, нагрузка приложения может состоять из: 10% изменений важных для клиента и 90% менее важных изменений, чью потерю бизнес может пережить гораздо легче, например, чат между пользователями.</div>
<div style="text-align: justify;">
Если синхронная репликация определена на прикладном уровне (на мастере) мы можем предложить синхронную репликацию наиболее важных изменений, не замедляя остальную часть общей нагрузки. Такой вид репликации являются важным и практичным инструментом для совмещения преимущества синхронной репликации и обеспечения высокой производительности приложения.</div>
<div style="text-align: justify;">
Вы должны учитывать, что пропускная способность сети должна быть выше, чем скорость генерации данных WAL.</div>
<h3 style="text-align: justify;">
25.2.6.3. Планирование высокой доступности</h3>
<div style="text-align: justify;">
Коммиты, сделанные при <tt>synchronous_commit</tt>, имеющим значение <tt>on</tt>, будут ожидать ответа от синхронного резервного сервера. Ответ же может и не придти, если последний, или единственный, резервный сервер упадёт.</div>
<div style="text-align: justify;">
Лучшее решение для предотвращения потери данных - убедиться, что Вы не потеряли последний оставшийся резервный сервер. Это может быть достигнуто перечислением нескольких потенциальных синхронных резервных серверов, используя <tt>synchronous_standby_names.</tt> Первый названный резервный сервер будет использоваться как синхронный резервный сервер. Остальные сервера, перечисленных после него, возьмут на себя роль синхронного резервного сервера, если первый выйдет из строя.</div>
<div style="text-align: justify;">
Когда резервный сервер первый раз подключается к мастеру, он ещё не синхронизирован с ним должным образом. Это описывается как <tt>catchup</tt> режим. После того, как в первый раз разрыв между резервным серером и мастером достигает нуля, мы переходим в режим реального времени <tt>streaming</tt>. catch-up период может продолжаться достаточно долго с момента создщания резервного сервера. Если резервный сервер выключен, то catchup период будет увеличен на то время, пока резервный сервер выключен. Резервный сервер может стать синхронным только после того, как он достигает режима <tt>streaming</tt>.</div>
<div style="text-align: justify;">
Если мастер перезагружается во время ожидания подтверждения, то эти ожидающие транзакции будут помечены полностью подтвеждёнными только после того, как база данных мастера будет восстановлена. Не существует способа убедиться, что все резервные сервера получили все необработанные данные WAL на момент падения мастера. Некоторые транзакции могут не быть отмеченными как подтверждённые на резервном серере, даже если они отражены как совершенные на мастере. Мы лишь гарантируем, что приложение не получит явное подтверждение успешной транзакции, до тех пор, пока WAL данные не будут точно полученными резервным сервером.</div>
<div style="text-align: justify;">
Если вы действительно потеряете свой последний резервный сервер, то Вы должны отключить <tt>synchronous_standby_names</tt> и перезагрузить конфигурационный файл на мастере.</div>
<div style="text-align: justify;">
Если мастер изолирован от остальных резервных серверов, то Вы должны переключиться на лучшего кандидата из оставшихся резервных серверов.</div>
<div style="text-align: justify;">
Если вам нужно заново создать резервный сервер, во время ожидания транзакций, убедитесь, что команды для запуска pg_start_backup() и pg_stop_backup() выполняются в сессии с <tt>synchronous_commit</tt> <tt>=</tt> off, в противном случае эти запросы будут вечно ждать появления резервного сервера.</div>
Ishayahu Lastovhttp://www.blogger.com/profile/03850137965550355992noreply@blogger.com0