Инициализация Postgres в FreeBSD Jail и в Warden

Когда я попробовал вызвать скрипт Postgres rc.d c аргументом initdb, я получил сообщение об ошибке, связанное, как я потом понял, с тем, что я пытался сделать это в тюрьме. Ошибка была связана с общей памятью:

pg_ctl

Имя

pg_ctl - инициализирует, запускает, останавливает и управляет PostgreSQL сервером

Краткий обзор

pg_ctl init[db] [-s] [-D datadir] [-o initdb-options]

pg_ctl start [-w] [-t seconds] [-s] [-D datadir] [-I filename] [-o options] [-p path] [-c]

pg_ctl stop [-W] [-t seconds] [-s] [-D datadir] [-m s[mart] | f[ast] | i[mmediate]]

pg_ctl restart [-w] [-t seconds] [-s] [-D datadir] [-c] [-m s[mart] | f[ast] | i[mmediate]] [-o options]

pg_ctl reload [-s] [-D datadir]

pg_ctl status [-D datadir]

pg_ctl promote [-s] [-D datadir]

pg_ctl kill signal_name process_id

pg_ctl register [-N servicename] [-U username] [-P password] [-D datadir] [-S a[uto] | d[emand]] [-w] [-t seconds] [-s] [-ooptions]

pg_ctl unregister [-N servicename]

initdb

Имя

initdb - создаёт новый кластер БД PostgreSQL

Краткий обзор

initdb [option...] -- pgdata | -D directory

17.2. Создание кластера БД

17.1. PostgreSQL аккаунты пользователей

Как и любой серверный демон, доступный снаружи, рекомендуется запускать PostgreSQL под отдельным пользователем. Этот аккаунт должен владеть только теми данными, которые управляются серверами и не должен использоваться другими демонами (поэтому, например, использовать пользователя nobody - плохая идея.) Не рекомендуется устанавливать исполняемые файлы под этим пользователем, так как на скомпрометированной системе они могут быть изменены.

Для того чтобы добавить пользователя на свою систему используйте команды useradd или adduser. Чаще всего используется имя postgres и его мы и будем использовать в этом руководстве. Но Вы можете использовать любое имя на свой вкус.

Глава 25.2 Резервные сервера на основе пересылки логов

Непрерывное архивирование может быть использовано для создания конфигурации высоко доступного (HA) кластера с одним или несколькими резервными серверами, готовыми принять на себя работу, если основной сервер выходит из строя. Эта возможность широко известна под именем "теплый" режим ожидания или передача логов.

Основной и резервный сервера работают вместе, чтобы обеспечить эту функциональность, хотя сами сервера слабо связаны. Мастер-сервер работает в непрерывном режиме архивирования, а каждый резервный сервер работает в непрерывном режиме восстановления, читая WAL файлы от мастера. Не требуется никаких изменений в таблицах базы данных чтобы включить эту возможность, так что этот метод не требует накладных расходов для настройки по сравнению с некоторыми другими видами репликации. Эта конфигурация также имеет относительно низкое влияние на производительность мастер сервера.

Непосредственное перемещение WAL записей с одного сервера баз данных на другой, как правило, называется "передачей логов". PostgreSQL реализует передачу файлов логов пересылая WAL записи, один файл (WAL сегмент) за раз. WAL файлы (16 МБ) могут быть легко и дешево переданы на любое расстояние, будь то соседняя система, другая система на этом же сайте, или другая система на другом конце земного шара. Пропускная способность, требуемая для этого, зависит от частоты транзакций основного сервера. Доставка логов на основе записей более детальна и передаёт WAL изменения инкрементально через сетевое подключение (см. раздел 25.2.5 ).

25.1. Сравнение различных способов

Использование общего диска

Использование общего диска позволяет избежать накладок на выполнение синхронизации, так как у Вас будет всего одна копия базы данных. При этом способе используется всего один дисковый массив, общий для нескольких серверов. Если основной сервер базы данных падает, резервный сервер может смонтировать и запустить базу данных, как если бы она была восстановлена после сбоя. Это позволяет быстро восстановить работу без потери данных.

Обычно для этих целей используются общие физические носители. Однако так же возможно использовать сетевую файловую систему, но необходимо убедиться, что она ведёт себя полностью в соответствии со стандартом POSIX (См. раздел 17.2.1). Существенное ограничение этого метода состоит в том, что если общий дисковый массив выходит из строя или повреждается, основной и резервный сервера перестают функционировать. Другая проблема состоит в том, что резервный сервер не должен обращаться к общему хранилищу в то время как работает основной сервер.