четверг, 24 января 2013 г.

25.3. Обеспечение отказоустойчивости


Если мастер падает, то резервный сервер должен начать процедуру failover (обеспечения отказоустойчивости).
Если падает резервный сервер, то никаких действий предпринимать не надо. Если резервный сервер может быть перезапущен, даже спустя некоторое время, то процесс восстановления может быть немедленно возобновлён. Если же перезапустить резервный сервер не возможно, то тогда нужно использовать другой резервный сервер.
Если мастер падает и резервный сервер становится новым мастером, а затем перезапускается старый мастер, то у Вас должен быть механизм, который бы сообщил старому мастеру, что он уже не является основным сервером. Чаще всего это называется  STONITH (Shoot The Other Node In The Head - Выстрел Другому Узлу в Голову - ВДрУГ ;) ), что необходимо для того, чтобы избежать ситуаций, где два узла действовали бы как мастера,  что привело бы к проблемам и потере информации.
Многие системы обеспечения отказоустойчивости используют только две системы - мастер и резервный сервер, которые соединены каким-то механизмом, который контролирует наличие соединения между обоими системами и жизнеспособность мастера. Кроме того, можно использовать третью систему ("мудрый" сервер), который позволит избежать некоторых случаев отказа, но его использование оправдано лишь при наличии достаточного внимания к настройке и скрупулёзном тестировании.
PostgreSQL не предоставляет системы ПО, которая бы определяла падение мастера и сообщала об этом резервному серверу. Есть множество систем, которые для этого можно использовать и которых хорошо интегрированы со средствами ОС, необходимыми для обеспечения отказоустойчивости, такими как миграция IP.
После того, как происходит переход на резервный сервер, у Вас есть только один действующий сервер. Это называется "вырожденное" состояние, так как бывший резервный сервер теперь мастер, а бывший мастер выключен и может оставаться в таком состоянии. Чтобы вернуться к нормальной системе, Вы должны пересоздать резервный сервер, либо на бывшем мастере после его ремонта, либо на третей, возможно новой, системе. После этого Вы можете захотеть поменять роли серверов. Некоторые используют третий сервер в качестве резерва для нового мастера, пока не сделают новый резервный сервер, однако это усложняет настройку системы и её обслуживание.
Таким образом переключение с мастера на резервный сервер может быть быстрым, но требует некоторой подготовки отказоустойчивого кластера. Периодическое переключение с мастера на резервный сервер полезно, так как предоставляет время для обслуживания каждого из серверов. Кроме того, это позволяет проверить механизм обеспечения отказоустойчивости и убедиться, что он и вправду будет работать, когда это понадобится. Очень желательно, чтобы все действия администратора на этот случай были так же письменно зафиксированы.
Для того, чтобы активировать резервный сервер в случае аварии при использовании пересылки логов, используйте pg_ctl promote или создайте триггер-файл с именем и по адресу, указанным в параметре trigger_file файла recovery.conf. Если Вы собираетесь использовать команду pg_ctl promote, то параметр trigger_file не нужен. Он так же не нужен, если Вы будете использовать резервные сервера только для снятия нагрузки с мастера за счёт выполнения на них только запросов на чтение, а не для обеспечения отказоустойчивости.

вторник, 22 января 2013 г.

pg_basebackup

Название

pg_basebackup -- делает резервную копию кластера PostgreSQL

Краткое описание

pg_basebackup [option...]

Описание

pg_basebackup используется для создания резервной копии БД работающего кластера PostgreSQL. Этот процесс не влияет на других клиентов БД и может использоваться и для point-in-time восстановления (см раздел 24.3), и как начальная точка для передачи логов или потоковой репликации (см раздел 24.2).
pg_basebackup делает двоичную копию файлов кластера БД, убедившись, что система автоматически входит и выходит из режима создания резервной копии. Копия всегда создаётся всего кластера, не возможно сделать копию отдельных БД или объектов БД. Для создания резервных копий отдельных БД используйте инструменты вроде pg_dump.
Резервная копия делается через обычное подключение PostgreSQL и использует протокол репликации. Поэтому соединение должно быть установлено пользователем, имеющим привилегию REPLICATION (см раздел 20.2) и у него должны быть соответствующие разрешения в pg_hba.conf. Сервер так же должен иметь достаточно высокое значение max_wal_senders, чтобы разрешить хотя бы одно подключение.
Одновременно может быть запущенно несколько экземпляров pg_basebackup, но с точки зрения производительности лучше запустить один pg_basebackup и потом просто сделать копии результата.

понедельник, 21 января 2013 г.

19.2. Карты имён пользователей

Когда Вы используете внешние системы аутентификации как Ident или GSSAPI, то имя пользователя ОС, который устанавливает соединение, может не совпадать с именем пользователя, под которым он хочет подключиться. В этом случае карта имён пользователей может использоваться ОС для отображения имени пользователя ОС на имя пользователя БД. Для того, чтобы использовать отображение имён пользователей, используйте опцию map=map-name в поле опций pg_hba.conf. Эта опция поддерживается для всех методов аутентификации, которые получают внешние имена пользователей. Так как для разных подключений могут быть необходимы разные карты, имя карты в параметре указывает, какую именно карту использовать в этом случае.

воскресенье, 20 января 2013 г.

19.1. Файл pg_hba.conf

Аутентификация клиента контролируется конфигурационным файлом, который обычно называется pg_hba.conf и хранится в каталоге кластера БД. (HBA означает host-based authentication - аутентификацию на основе хоста.) Файл со значениями по умолчанию создаётся при инициализации кластера при помощи initdb. Тем не менее можно разместить этот файл где угодно, для этого используется параметр hba_file.

четверг, 17 января 2013 г.

18.6. Репликация

Эти настройки управляют встроенной потоковой репликацией (см раздел 25.2.5). Некоторые параметры должны быть заданы на мастере, другие - на резервном сервере, которые будут получать данные репликации.

четверг, 10 января 2013 г.

18.2. Расположение файлов


Кроме конфигурационного файла postgresql.conf, о котором мы уже говорили, PostgreSQL использует два других конфигурационных файла, редактируемых вручную, отвечающих за аутентификацию клиента (они обсуждаются в главе 19). По умолчанию все три конфигурационных файла хранятся в каталоге с данными. Параметры, описанные в этом разделе позволяют расположить эти файлы где-либо в другом месте. (Это может облегчить администрирование сервера. В частности зачастую гораздо проще убедиться что сделана резервнвая копия конфигурационных файлов если они хранятся отдельно от остальных данных).
data_directory (string)
Определяет каталог, используемый для хранения данных. Этот параметр может быть определён только при запуске сервера
config_file (string)
Определяет главный конфигурационный файл сервера (обычно называемый postgresql.conf). Этот параметр может быть определён только как аргумент командной строки
hba_file (string)
Определяет конфигурационный файл для аутентификации на основе хостов (обычно называемый pg_hba.conf). Этот параметр может быть задан только при запуске сервера.
ident_file (string)
Определяет конфигурационный файл для карт имён пользователей, обсуждаемых в разделе 19.2 (обычно называемый pg_ident.conf). Этот параметр может быть задан только при запуске сервера.
external_pid_file (string)
Определяет имя дополнительного PID (process-ID) файла, который сервер должен создать для использования программы управления сервером. Этот параметр может быть задан только при запуске сервера.
В установке по умолчанию ни один из этих параметров не задан явно. Вместо этого все файлы ищутся в каталоге с данными, который определяется либо через параметр -D командной строки, либо через переменную окружения PGDATA.
Если Вы хотите хранить конфигурационные файлы где-то в другом месте, то -D или PGDATA должны указывать место хранения конфигурационных файлов, а параметр data_directory в postgresql.conf (или в командной строке) должен указывать каталог с данными. Обратите внимание, что data_directory переопределяет -D и PGDATA в поиске данных, но не в поиске файлов настроек.
Если Вы хотите, то Вы можете задать свои имена файлов конфигурации при помощи параметров config_file, hba_file и / или ident_file. config_file может быть определён только в командной строке, но другие имена могут быть обозначены в главном конфигурационном файле. Если явно заданы все три параметра и data_directory, то тогда вообще можно обойтись без -D или PGDATA.
Указанный в отношении этих параметров относительный путь будет использован относительно места запуска postgres.

18.1. Настройка параметров

Все имена параметров чувствительны к регистру. Каждый параметр принимает значение одного из пяти типов: boolean, integer, floating point, string или enum. Логические (boolean) значения могут быть заданы как on, off, true, false, yes, no, 1, 0 (вне зависимости от региста) или как их однозначное сокращение.

вторник, 8 января 2013 г.

17.10. Безопасные TCP/IP соединения при помощи SSHTunnels


Возможно использовать SSH для шифрования сетевых соединений между клиентом и сервером PostgreSQL. Если это сделано правильно, что мы поучаем адекватный уровень сетевой безопасности даже для клиентов, не поддерживающих SSL.

17.9. Безопасные TCP/IP соединения посредством SSL

PostgreSQL поддерживает использование SSL соединений для шифрования общения клиент/сервер, обеспечивая более высокий уровень безопасности. Для этого требуется, чтобы OpenSSL был установлен как на клиенте, так и на сервере и чтобы поддержка SSL была включена в момент сборки PostgreSQL (см главу 15).

понедельник, 7 января 2013 г.

17.8. Опции шифрования


PostgreSQL предоставляет возможность шифрования на разных уровнях, что позволяет защитить данные от кражи БД с сервера, недобросовестного администратора и небезопасной сети. Шифрование так же может использоваться для обеспечения тайны данных, таких как медицинская информация или финансовые транзакции.

17.7. Предотвращение спуфинга сервера

Всё то время, что сервер запущен, никто не может занять его место в качестве сервера-злоумышленника БД. Однако, пока сервер выключен, локальный пользователь может занять его место, запустив свой сервер. Такой сервер может читать пароли пользователей и их запросы, но не может возвращать данные, так как каталог PGDATA недоступен ему из-за разрешений ФС. Спуфинг возможен, так как любой пользователь может запустить свой сервер БД; клиент не может отличить настоящий сервер от злоумышленника, если он не сконфигурирован должным образом.
Самый простой способ предотвратить спуфинг для локальных подключений - использовать каталог Unix domain socket (unix_socket_directory), который имеет права на запись только для доверенного локального пользователя. Это не позволит злоумышленнику создать свой собственный сокет в этой директории. Если Вы обеспокоены тем, что некоторые приложения могут всё ещё ссылаться на /tmp в поисках файла сокета и потому быть уязвимы для спуфинга, создайте при запуске ОС символическую ссылку /tmp/.s.PGSQL.5432, которая будет вести к файлу сокета в другом месте. Кроме того, возможно, Вам потребуется изменить скрипт отчистки /tmp, чтобы он не удалял эту ссылку.
Для того, чтобы предотвратить спуфинг через TCP соединения, лучше всего использовать SSL сертификаты и убедиться, что клиент проверяет сертификат сервера. Для этого сервер должен быть настроен на приём только hostssl соединений (раздел 19.1) и иметь SSL файлы server.key (ключ) и server.crt (сертификат) (раздел 17.9). TCP клиенты должны подключаться при помощи sslmode=verify-ca или verify-full и иметь установленные соответствующие корневые сертификаты (раздел 31.1)

17.6. Обновление PostgreSQL кластера


В этом разделе будет рассказано о том, как перевести вашу БД с одного PostgreSQL релиза на более новый.

воскресенье, 6 января 2013 г.

17.5. Остановка сервера


Есть несколько способов выключить сервер БД. Вы можете определить способ остановки сервера, посылая разные сигналы главному процессу postgres.

SIGTERM
Это режим "умного выключения" (smart shutdown). После получения сигнала SIGTERM сервер запрещает создание новых подключений, но уже существующие работают нормально. Выключение происходит только после того, как разорваны все соединения. Если сервер находится в режиме online backup, то новые подключения всё ещё можно создать, но только для суперпользователя (это позволит суперпользователю подлкючиться и остановить процесс создания резервной копии). Если сервер находится в режиме восстановления, то восстановление и потоковая репликация останавливаются только после того, как завершаются все сессии
SIGINT
Это режим "быстрого выключения" (fast shutdown). Сервер запрещает создание новых подключений и посылает всем существующим процессам сервера сигнал SIGTERM, что завершает их работу. После того, как все процессы завершат свою работу, останавливается и главный процесс. Если сервер находится в режиме online backup, то оно тут же прерывается.
SIGQUIT
Это режим "немедленного выключения" (immediate shutdown). Главный процесс postgres посылает сигнал SIGQUIT всем дочерним процессам и завершается сам, не дожидаясь их завершения. Дочерние процессы так же завершаются сразу же по получении сигнала. Это приведёт к восстановлению (воспроизведению WAL логов) при следующем запуске. Рекомендуется только в крайних случаях.
Программа pg_ctl предоставляет удобный способ посылки сигналов для остановки сервера. Кроме того Вы можете послать сигнал напрямую при помощи команды kill, если Вы не используете Windows. PID процесса postgres может быть найден при помощи программы ps, или его можно узнать из файла postmaster.pid в директории с данными. Вот пример быстрого выключения:
$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
Важно: Лучше не использовать SIGKILL для выключения сервера. Такой способ не позволяет серверу освободить память и семафоры, так что это должно будет сделано вручную перед запуском нового процесса сервера. Более того, SIGKILL убивает процесс postgres не позволяя переслать сигнал дочерним процессам, так что каждый из них придётся убивать вручную.
Для того, чтобы прервать индивидуальную сессию, оставив остальные рабочими, используйте pg_terminate_backend() (см таблицу 9-55) или пошлите SIGTERN дочернему процессу, связанному с этой сессией.

17.4. Управление ресурсами ядра

Большая установка PostgreSQL может быстро исчерпать ресурсы вашей системы (на некоторых системах объём доступных ресурсов так мал, что для этого даже не нужна "большая" установка). Если и Вы столкнулись с этой проблемой - читайте дальше.

среда, 2 января 2013 г.

17.3. Запуск сервера БД


Перед тем, как кто-нибудь сможет получить доступ к БД, Вы должны запустить сервер БД. Программа сервер называется postgres. Эта программа должна знать где найти необходимые ей для работы данные. Для этого используется опция -D. Так что самый простой способ запуска сервера:

29.4. Настройка WAL

Есть несколько связанных с WAL параметров конфигурации, которые влияют на производительность БД. Этот раздел объясняет как их использовать. По поводу настройки сервера обращайтесь к главе 18.
Checkpoints - это точки в последовательности транзакций в которых гарантируется, что файлы данных heap и index содержат всю информацию, записанную до этой точки. На момент чекпойнта все страницы грязных данных записаны на диск и в лог-файл записана специальная запись чекпойнта. (Изменения перед этим записаны в WAL файлы). Если происходит падение, то процесс восстановления смотрит на последний чекпойнт, чтобы определить место в логах (известное как redo record), откуда должна быть начата операция REDO. Все изменения, сделанные до этого момента гарантированно записаны на диск. По этой причине все сегменты, расположенные до чекпойнта могут быть удалены или перезаписаны. (Когда происходит архивирование WAL - сегменты лога должны быть заархивированы до того, как они будут удалены или перезаписаны.)