четверг, 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). Некоторые параметры должны быть заданы на мастере, другие - на резервном сервере, которые будут получать данные репликации.