17.3. Запуск сервера баз данных. Сервер postgresql

Установка PostgreSQL — пошаговое описание процесса

В очередной раз устанавливая и настраивая Postgres, решил законспектировать всю последовательность действий. Получилась лаконичная инструкция по установке PostgreSQL. Перечитал... и подумал, что если чуть расширить тему, добавив деталей в виде объяснений и рекомендаций, то может получиться целая статья, претендующая на полезность.

Статья получилась большая, разбил ее на две части:

В первой части, размещенной в этом посте, речь пойдет о том, как установить СУБД PostgreSQL, настроить кодировку/локаль и создать хранилище данных.
Следующая часть будет посвящена тому, как правильно настроить PostgreSQL и запустить в продакшн; в какую сторону изменять дефолтные настройки постгреса, как их оптимизировать под используемое железо, какие при этом могут возникнуть нюансы, и как с ними бороться.

Пара слов о железе

У многих сложилось впечатление, что поскольку Postgre SQL довольно навороченная СУБД, часто используемая в высокопроизводительных системах, то и требования к железу повышенные. Это не так. И тот, кто руководствуется только этим при выборе для своего проекта Mysql vs Postgres, мягко говоря не прав.

Первый опыт общения с СУБД Postgres у меня был в 99-м году. Уже тогда это был серьезный продукт. Еще лучше стало в 2000-м, когда вышла 7-я версия — казалось, что всё вообще супер! В реальности так и было.

Так вот, на каком железе работали те версии, на таком смогут работать и новые.

По умолчанию настройки сервера PostgreSQL довольно скромные: такие, что он заработает не то что на любом современном компьютере, но и внутри виртуальной машины с ограниченными ресурсами. Но параметры постгреса можно подкрутить — как в сторону увеличения потребляемых ресурсов (и, соответственно, увеличения возможной производительности PostgreSQL), так и в сторону их уменьшения, как это ни странно. В общем, настроить можно так, как нам нужно, достаточно гибко.

В качестве примеров конфигурации железа, от которых я буду отталкиваться при описании настроек SQL-сервера, выступят две разные машины, на которые я недавно устанавливал Postgres:

Выделенный сервер i5-2400 CPU @ 3.10GHz, 16 Gib RAM, 2xHDD SATA в зеркале (программный RAID 1). Эта машина выступает в качестве веб-сервера с Apache и Django.
Виртуальный сервер EC2 в "облаке" на Амазоне в конфигурации M1 Small Instance (Default) 1.7 GiB RAM, с хранилищем EBS. ПО, установленное на сервере аналогично первому (Apache, Django, аналогичные сайты).

Процесс установки и настройки PosgreSQL вкратце:

Установка Postgres
Настройка основных параметров запуска СУБД
Создание хранилища (инициализация "кластера")
Настройка конфигурации Postgres'а
Настройка прав доступа
Запуск сервера PostgreSQL

Шаг 1. Установка PostgreSQL

К примеру, на данный момент, если исключить версии 7.x, есть две ветки: 8.x и 9.x. И в каждой ветке еще по 2-3 подветки. Так, на момент написания статьи в портах FreeBSD доступны следующие версии PostgreSQL: 8.3.23, 8.4.17, 9.0.13, 9.1.9, 9.2.4!

Из опыта работы с другим ПО мы знаем, что самое новое — не обязательно лучшее. Да и обращает на себя внимание тот факт, что чем старше версия, тем больше третье число в номере версии: сравните 8.3.23 и 9.2.4. По идее, 23 должно быть матёрей 4. ))

К счастью, с Postgres'ом на данный момент времени этот выбор сделать легко — выбирайте самую новую версию (сейчас это 9.2.4), не ошибетесь, и вот почему:

версия 8.3.23 уже не поддерживается сообществом, то есть считается устаревшей; 8.4.17 пока поддерживается.
между 8-й и 9-й веткой, выигрывает последняя по многим показателям; а главное — в ней появилась встроенная потоковая репликация, что чрезвычайно важно, чтобы не городить свой огород из разнообразных программ и технологий;

версия 9.0.x, как первая в линейке, страдает от многих функциональных недостатков, в сравнении с 9.1, в которой потоковая репликация наконец-то может быть использована практически;
версия 9.2 PostgreSQL сделана на основе версии 9.1 и, кроме увеличения производительности и новых возможностей со всё той же репликацией, в нее добавлены другие интересные функции.

Как инсталлировать PostgreSQL, какие есть нюансы?

Бывают ситуации (оставшийся условный 1%), когда нужно скачать PostgreSQL в исходниках, распаковать, сконфигурировать, и собрать полностью в ручном режиме, без менеджера пакетов. Но, честно говоря, не припомню, чтобы у меня была на то какая-то необходимость когда либо вообще. Менеджер пакетов — наш друг!

Итак, в FreeBSD с установленными "портами" я делаю под пользователем root:

# cd /usr/ports/databases/postgresql92-server# make

Соглашаюсь с опциями во всех возникающих диалоговых окнах, в частности, опция ICU остается выключена.

После того как пакет соберется, я делаю:

# make install

И далее:

# make clean

Среди установленных пакетов мы видим не только postgresql92-server, но и postgresql92-client, который нам понадобится, а также вспомогательные, от которых зависит основной.

Вот, собственно, и вся установка. Теперь к параметрам запуска.

Шаг 2. Настройка параметров запуска PostgreSQL

postgresql_enable="YES"postgresql_data="/usr/local/pgsql/data"postgresql_flags="-w -s -m fast"postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C"postgresql_class="default"postgresql_profiles=""

Первая строчка разрешает автозапуск Postgres'а при старте системы или когда вы хотите запустить его вручную при помощи скрипта /usr/local/etc/rc.d/postgresql. Если этой строчки нет, стандартным способом PostgreSQL не запустится. Поменяв ее значение на "NO", можно отключить автозапуск постгреса при загрузке, если это зачем-то понадобилось.

Вторая строчка указывает место в файловой системе, где искать хранилище данных (кластер баз данных PostgreSQL). При установке с помощью пакетного менеджера, как это было показано выше, этот каталог (и его родительский) будет создан автоматически, а права на него будут назначены специальному пользователю pgsql (в некоторых системах его имя postgres), который добавляется в систему также автоматически.

Следующая строчка с флагами "-w -s -m fast" относится не к самому SQL-серверу, а к служебной программе pg_ctl. Можете посмотреть её man. Как правило, эти флаги приемлемы в большинстве случаев.

А вот четвертая строка нас скорее всего не устроит. Опции, указанные в ней будут использованы программой initdb для инициализации хранилища данных (если мы будем запускать ее стандартным для FreeBSD способом, через /usr/local/etc/rc.d/postgresql). Рекомендуется, во избежание разных проблем, связанных с кодировкой баз PostgreSQL, добавить в нее вашу локаль, например: --locale=ru_RU.UTF-8 (для русской) или --locale=uk_UA.UTF-8 (для украинской).

А теперь самое странное... --lc-collate. Этот параметр определяет как сортировать буквы. К примеру, в каком порядке должны идти буквы "а", "А", "б", "Б"? Это не всегда очевидно, на самом деле, поэтому бывают разные collate. В SQL этот параметр может влиять на результаты выполнения запросов (ORDER BY).

По умолчанию Postgres отдает всю работу по определению этого порядка операционной система, на которой он работает. Но некоторые операционные системы сами не знают как это делать "правильно"...

Каким же делать этот --lc-collate?

По идее, значение LC_COLLATE должно соответствовать используемой локали, то есть, к примеру быть ru_RU.UTF-8 (для русской UTF-8). Но работает ли это уже в FreeBSD? А если работает, то как быстро? На эту тему было обсуждение и предложения еще в 2008 году и ранее, и позднее, неоднократно.

Альтернативный вариант, не опирающийся на collate операционной системы возможен, если включить опцию ICU при сборке Postgres'а, но с этим тоже не всё идеально.

Если оставить значение этого параметра равным C (или POSIX), сортировка будет хотя и быстрой, но ориентированной на значение кода буквы как в языке Си. Для латиницы она, конечно, будет нормальной. А для кириллицы — не факт. Но жить можно, в большинстве случаев.

Подвожу итог: на Ubuntu, ставьте такое же значение, что и для локали. Предполагаю, что это работает и в Debian'е, и в других дистрибутивах Linux'а. А я в FreeBSD, пожалуй, пока оставлю --lc-collate=С.

Следующая строчка с параметром postgresql_class нас также может не устроить. Она определяет какой класс пользователя (из login.conf) присвоить постгресу, а точнее тому системному пользователю (pgsql или postgres) от имени которого сервер PostgreSQL выполняется. Т. к. по умолчанию в FreeBSD не включена русская локаль UTF-8, я создаю вот такую секцию в файле /etc/login.conf следом за определением класса russian:postgres:\ :lang=ru_RU.UTF-8:\ :setenv=LC_COLLATE=C:\ :tc=default:

Значения ru_RU.UTF-8 и LC_COLLATE=C выбраны по тем же причинам, что и выше.

Затем, чтобы зафиксировать изменения, я выполняю команду:

# cap_mkdb /etc/login.conf

Теперь у нас есть "класс" postgres, которым я заменяю бывший default в параметре postgres_class в /etc/rc.conf. А значит кодировка PostgreSQL и его локаль установлены.

По поводу postgresql_profiles — ни разу не использовал эту возможность, здесь опускаю.

Итак, имеем в итоге в /etc/rc.conf:

postgresql_enable="YES"postgresql_data="/usr/local/pgsql/data"postgresql_flags="-w -s -m fast"postgresql_initdb_flags="--locale=ru_RU.UTF-8 --encoding=utf-8 --lc-collate=C"postgresql_class="postgres"

Шаг 3. Создание хранилища данных PostgreSQL

# /usr/local/etc/rc.d/postgresql initdb

И, если всё прошло удачно (а так и должно быть), можно считать сервер PostgreSQL установленным, а хранилище созданным!

Альтернативный вариант, чаще используемый в Linux, такой: зайти в систему под пользователем postgres, залогинившись (если задан пароль для этого пользователя) или сменив пользователя, вот так: $ sudo su postgres

и запустить initdb с нужными параметрами (всё одной строке):

$ initdb --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF-8 --lc-type=ru_RU.UTF-8 --encoding=utf-8 -D /var/db/postgres/data

Здесь дополнительно задан параметр --lc-type, отвечающий за классификацию символов (разделение на буквы, цифры), который, в общем случае должен совпадать с --lc-collate. Ключ -D задает путь к каталогу, в котором создается хранилище.

В Ubuntu, например, при установке Postgres'а с помощью apt-get install этот каталог автоматически располагается в /var/lib/postgresql/9.1/main, где 9.1 указывает на версию установленного сервера PostgreSQL.

Этот каталог должен быть создан до того, как выполняют initdb, его владельцем должен быть пользователь postgres, с правами rwx------. Родительский каталог также принадлежат пользователю postgres, но уже может иметь права rwxr-xr-x.

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

О том, как правильно настроить Postgres, речь пойдет во второй части статьи.

PostgreSQL : Документация: 9.6: 18.3. Запуск сервера баз данных : Компания Postgres Professional

18.3. Запуск сервера баз данных

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

в результате которой сервер продолжит работу в качестве процесса переднего плана. Запускать эту команду следует под именем учётной записи PostgreSQL. Без параметра -D сервер попытается использовать каталог данных, указанный в переменной окружения PGDATA. Если и эта переменная не определена, сервер не будет запущен.

Однако обычно лучше запускать postgres в фоновом режиме. Для этого можно применить обычный синтаксис, принятый в оболочке Unix:

Важно где-либо сохранять информацию, которую выводит сервер в каналы stdout и stderr, как показано выше. Это полезно и для целей аудита, и для диагностики проблем. (Более глубоко работа с файлами журналов рассматривается в Разделе 24.3.)

Программа postgres также принимает несколько других параметров командной строки. За дополнительными сведениями обратитесь к справочной странице postgres и к следующей Главе 19.

Такой вариант запуска довольно быстро может оказаться неудобным. Поэтому для упрощения подобных задач предлагается вспомогательная программа pg_ctl. Например:

запустит сервер в фоновом режиме и направит выводимые сообщения сервера в указанный файл журнала. Параметр -D для неё имеет то же значение, что и для программы postgres. С помощью pg_ctl также можно остановить сервер.

Обычно возникает желание, чтобы сервер баз данных сам запускался при загрузке операционной системы. Скрипты автозапуска для разных систем разные, но в составе PostgreSQL предлагается несколько типовых скриптов в каталоге contrib/start-scripts. Для установки такого скрипта в систему требуются права root.

В различных системах приняты разные соглашения о порядке запуска служб в процессе загрузки. Во многих системах для этого используется файл /etc/rc.local или /etc/rc.d/rc.local. В других применяются каталоги init.d или rc.d. Однако при любом варианте запускаться сервер должен от имени пользователя PostgreSQL, но не root или какого-либо другого пользователя. Поэтому команду запуска обычно следует записывать в форме su postgres -c '...'. Например:

Ниже приведены более конкретные предложения для нескольких основных ОС. (Вместо указанных нами шаблонных значений необходимо подставить правильный путь к каталогу данных и фактическое имя пользователя.)

Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL.
В OpenBSD, добавьте в файл /etc/rc.local следующие строки:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data' echo -n ' postgresql' fi
В системах Linux вы можете либо добавить
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
в /etc/rc.d/rc.local или в /etc/rc.local, либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL.
Используя systemd, вы можете применить следующий файл описания службы (например, /etc/systemd/system/postgresql.service):
[Unit] Description=PostgreSQL database server Documentation=man:postgres(1) [Service] Type=notify User=postgres ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=0 [Install] WantedBy=multi-user.target
Для использования Type=notify требуется, чтобы сервер был скомпилирован с указанием configure --with-systemd.
Особого внимания заслуживает значение тайм-аута. На момент написания этой документации по умолчанию в systemd принят тайм-аут 90 секунд, так что процесс, не сообщивший о своей готовности за это время, будет уничтожен. Но серверу PostgreSQL при запуске может потребоваться выполнить восстановление после сбоя, так что переход в состояние готовности может занять гораздо больше времени. Предлагаемое значение 0 отключает логику тайм-аута.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux, в зависимости от предпочтений.
В Solaris, создайте файл с именем /etc/init.d/postgresql, содержащий следующую стоку:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Затем создайте символическую ссылку на него в каталоге /etc/rc3.d с именем S99postgresql.

Когда сервер работает, идентификатор его процесса (PID) сохраняется в файле postmaster.pid в каталоге данных. Это позволяет исключить запуск нескольких экземпляров сервера с одним каталогом данных, а также может быть полезно для выключения сервера.

18.3.1. Сбои при запуске сервера

Есть несколько распространённых причин, по которым сервер может не запуститься. Чтобы понять, чем вызван сбой, просмотрите файл журнала сервера или запустите сервер вручную (не перенаправляя его потоки стандартного вывода и ошибок) и проанализируйте выводимые сообщения. Ниже мы рассмотрим некоторые из наиболее частых сообщений об ошибках более подробно.

Это обычно означает именно то, что написано: вы пытаетесь запустить сервер на том же порту, на котором уже работает другой. Однако, если сообщение ядра не Адрес уже используется или подобное, возможна и другая проблема. Например, при попытке запустить сервер с номером зарезервированного порта будут выданы такие сообщения:

Следующее сообщение:

может означать, что установленный для вашего ядра предельный размер разделяемой памяти слишком мал для рабочей области, которую пытается создать PostgreSQL (в данном примере 4011376640 байт). Возможно также, что в вашем ядре вообще отсутствует поддержка разделяемой памяти в стиле System-V. В качестве временного решения можно попытаться запустить сервер с меньшим числом буферов (shared_buffers), но в итоге вам, скорее всего, придётся переконфигурировать ядро и увеличить допустимый размер разделяемой памяти. Вы также можете увидеть это сообщение при попытке запустить несколько серверов на одном компьютере, если запрошенный ими объём разделяемой памяти в сумме превышает этот предел.

Сообщение:

не означает, что у вас закончилось место на диске. Это значит, что установленное в вашем ядре предельное число семафоров System V меньше, чем количество семафоров, которое пытается создать PostgreSQL. Как и в предыдущем случае, можно попытаться обойти эту проблему, запустив сервер с меньшим числом допустимых подключений (max_connections), но в конце концов вам придётся увеличить этот предел в ядре.

Если вы получаете ошибку «illegal system call» (неверный системный вызов), то, вероятнее всего, ваше ядро вовсе не поддерживает разделяемую память или семафоры. В этом случае, вам остаётся только переконфигурировать ядро и включить их поддержку.

Настройка средств IPC в стиле System V описывается в Подразделе 18.4.1.

18.3.2. Проблемы с подключениями клиентов

Хотя ошибки подключений, возможные на стороне клиента, довольно разнообразны и зависят от приложений, всё же несколько проблем могут быть связаны непосредственно с тем, как был запущен сервер. Описание ошибок, отличных от описанных ниже, следует искать в документации соответствующего клиентского приложения.

Это общая проблема «я не могу найти сервер и начать взаимодействие с ним». Показанное выше сообщение говорит о попытке установить подключение по TCP/IP. Очень часто объясняется это тем, что сервер просто забыли настроить для работы по протоколу TCP/IP.

Кроме того, при попытке установить подключение к локальному серверу через Unix-сокет можно получить такое сообщение:

Путь в последней строке помогает понять, к правильному ли адресу пытается подключиться клиент. Если сервер на самом деле не принимает подключения по этому адресу, обычно выдаётся сообщение ядра Connection refused (В соединении отказано) или No such file or directory (Нет такого файла или каталога), приведённое выше. (Важно понимать, что Connection refused в данном контексте не означает, что сервер получил запрос на подключение и отверг его. В этом случае были бы выданы другие сообщения, например, показанные в Разделе 20.4.) Другие сообщения об ошибках, например Connection timed out (Тайм-аут соединения) могут сигнализировать о более фундаментальных проблемах, например, о нарушениях сетевых соединений.

postgrespro.ru

PostgreSQL : Документация: 9.5: 17.3. Запуск сервера баз данных : Компания Postgres Professional

17.3. Запуск сервера баз данных

Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL.
В OpenBSD, добавьте в файл /etc/rc.local следующие строки:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data' echo -n ' postgresql' fi
В системах Linux вы можете либо добавить
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
в /etc/rc.d/rc.local или в /etc/rc.local, либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux, в зависимости от предпочтений.
В Solaris, создайте файл с именем /etc/init.d/postgresql, содержащий следующую стоку:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Затем создайте символическую ссылку на него в каталоге /etc/rc3.d с именем S99postgresql.

17.3.1. Сбои при запуске сервера

Следующее сообщение:

Сообщение:

Настройка средств IPC в стиле System V описывается в Подразделе 17.4.1.

17.3.2. Проблемы с подключениями клиентов

Путь в последней строке помогает понять, к правильному ли адресу пытается подключиться клиент. Если сервер на самом деле не принимает подключения по этому адресу, обычно выдаётся сообщение ядра Connection refused (В соединении отказано) или No such file or directory (Нет такого файла или каталога), приведённое выше. (Важно понимать, что Connection refused в данном контексте не означает, что сервер получил запрос на подключение и отверг его. В этом случае были бы выданы другие сообщения, например, показанные в Разделе 19.4.) Другие сообщения об ошибках, например Connection timed out (Тайм-аут соединения) могут сигнализировать о более фундаментальных проблемах, например, о нарушениях сетевых соединений.

postgrespro.ru

PostgreSQL : Документация: 10: 18.3. Запуск сервера баз данных : Компания Postgres Professional

18.3. Запуск сервера баз данных

Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL.
В OpenBSD, добавьте в файл /etc/rc.local следующие строки:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data' echo -n ' postgresql' fi
В системах Linux вы можете либо добавить
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
в /etc/rc.d/rc.local или в /etc/rc.local, либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL.
Используя systemd, вы можете применить следующий файл описания службы (например, /etc/systemd/system/postgresql.service):
[Unit] Description=PostgreSQL database server Documentation=man:postgres(1) [Service] Type=notify User=postgres ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=0 [Install] WantedBy=multi-user.target
Для использования Type=notify требуется, чтобы сервер был скомпилирован с указанием configure --with-systemd.
Особого внимания заслуживает значение тайм-аута. На момент написания этой документации по умолчанию в systemd принят тайм-аут 90 секунд, так что процесс, не сообщивший о своей готовности за это время, будет уничтожен. Но серверу PostgreSQL при запуске может потребоваться выполнить восстановление после сбоя, так что переход в состояние готовности может занять гораздо больше времени. Предлагаемое значение 0 отключает логику тайм-аута.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux, в зависимости от предпочтений.
В Solaris, создайте файл с именем /etc/init.d/postgresql, содержащий следующую стоку:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Затем создайте символическую ссылку на него в каталоге /etc/rc3.d с именем S99postgresql.

18.3.1. Сбои при запуске сервера

Это обычно означает именно то, что написано: вы пытаетесь запустить сервер на том же порту, на котором уже работает другой. Однако, если сообщение ядра не Address already in use или подобное, возможна и другая проблема. Например, при попытке запустить сервер с номером зарезервированного порта будут выданы такие сообщения:

Следующее сообщение:

Сообщение:

Настройка средств IPC в стиле System V описывается в Подразделе 18.4.1.

18.3.2. Проблемы с подключениями клиентов

postgrespro.ru

Настройка потоковой репликации Postgresql сервера (WAL-репликация)

Опубликовано: 01 Авг 2018 (последние правки 1 месяц, 3 недели)

Потоковая репликация Postgresql сервера позволяет создать асинхронную Read Only копию сервера баз данных который можно использовать как FailOver-сервер или строить на нем какие-то тяжелые аналитические отчеты которые бы в свою очередь сильно загрузили боевой сервер. Назначений можно придумать огромное множество, да и настраивается эта технология довольно просто, правда есть у нее есть и несколько недостатков.

Главным недостатком потоковой репликации является, то что вы вынуждены реплицировать полностью сервер и не можете реплицировать отдельные таблицы и базы данных, вторым недостатком является, то что мастер и слэйв должны мало того, что одной версии, так и использовать одинаковую архитектуру (i386/x64/ARM) и теперь если вас все из вышеперечиcленного устраивает, то мы приступаем к настройке потоковой репликации.

Настраиваем MASTER-сервер

На основном сервере вносим изменения в конфигурацию (файл /etc/postgresql/10/main/pg_hba.conf):

мы сейчас разрешили доступ к нашему центральному серверу с адреса 94.177.204.179 (это наш Slave-сервер).

В основном конфигурационном файле (/etc/postgresql/10/main/postgresql.conf):

В первом приближении этого достаточно чтобы сервер Postgresql начал выступать в качестве мастер-сервера. Самый главный из перечисленных параметров, это wal_level = replica и до Postgresql версии 10 он устанавливался в значение hot_standby:

Параметр wal_level определяет, как много информации записывается в WAL. Со значением replica (по умолчанию) в журнал записываются данные, необходимые для поддержки архивирования WAL и репликации, включая запросы только на чтение на ведомом сервере. Вариант minimal оставляет только информацию, необходимую для восстановления после сбоя или аварийного отключения. Наконец, logical добавляет информацию, требующуюся для поддержки логического декодирования. Каждый последующий уровень включает информацию, записываемую на всех уровнях ниже. Задать этот параметр можно только при запуске сервера.

Более подробно можно почитать тут: https://postgrespro.ru/docs/postgrespro/10/runtime-config-wal#RUNTIME-CONFIG-WAL-SETTINGS

Создаем каталог для хранения архива и назначаем права доступа к каталогу:

Как вы видели в начале статьи, я разрешил доступ к серверу (для репликации) с одного IP-адреса и строго определенному пользователю которого сейчас необходимо создать и назначить ему привилегии и пароль:

Для применения нового режима работы сервер баз данных придется перезагрузить:

Настраиваем SLAVE-сервер

На Slave-сервере необходимо остановить сервер баз данных командой:

Следующим этапом вам требуется удалить текущие данные и скопировать базу с мастера командой pg_basebackup:

После того как вы получили сообщение, что данные успешно скопированы необходимо внести правки в конфигурацию как в случае с MASTER-сервером (в файле /etc/postgresql/10/main/postgresql.conf):

Мы изменяем только один параметр и переключаем сервер в режим горячей замены. Теперь сервер будет получать данные с мастера, но при этом перейдет в режим Read Only.

Следующим этапом создаем файл /var/lib/postgresql/10/main/recovery.conf следующего содержания:

Кстати сказать если вы использовали pg_basebackup, то этот файл будет создан автоматически. Дополнительно можно создать запись:

Если вы создадите файл /tmp/postgresql-trigger с любым содержанием, то SLAVE автоматически переконфигурируется в MASTER.

Обратите внимание, на параметр restore-command он обратный к archive_command на MASTER сервере и каталог с архивами должен быть смонтирован на SLAVE с MASTER-сервера.

Мы все настройки произвели и можем запускать Postgresql-сервер:

В списке системных процессов должен появиться процесс:

А в логах соответственно записи:

Теперь можете попробовать создать запись в таблице на мастер-сервере и проверить была ли она получена на SLAVE.

Диагностика репликации

В Postgresql 10 вы можете использовать следующий запрос для получения сведений о клиентах потоковой репликации:

gita-dev.ru

PostgreSQL : Документация: 9.6: pg_upgrade : Компания Postgres Professional

Переместить старый кластер (необязательно)
Если ваш каталог инсталляции привязан к версии, например, /opt/PostgreSQL/9.1, перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.
Если ваш каталог инсталляции не привязан к версии, например /usr/local/pgsql, необходимо переместить каталог текущей инсталляции PostgreSQL, чтобы он не конфликтовал с новой инсталляцией PostgreSQL. Когда текущий сервер PostgreSQL отключён, каталог этой инсталляции PostgreSQL можно безопасно переместить; если старый каталог /usr/local/pgsql, его можно переименовать, выполнив:
mv /usr/local/pgsql /usr/local/pgsql.old
Собрать новую версию при установке из исходного кода
Соберите из исходного кода новую версию PostgreSQL с флагами configure, совместимыми с флагами старого кластера. Программа pg_upgrade проверит результаты pg_controldata, чтобы убедиться, что все параметры совместимы, прежде чем начинать обновление.
Установить новые исполняемые файлы PostgreSQL
Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.
При установке из исходного кода, если вы хотите разместить сервер в нестандартном каталоге, воспользуйтесь переменной prefix:
make prefix=/usr/local/pgsql.new install
Инициализировать новый кластер PostgreSQL
Инициализируйте новый кластер, используя initdb. При этом так же необходимо указать флаги initdb, совместимые с флагами в старом кластере. Многие готовые инсталляторы выполняют это действие автоматически. Запускать новый кластер не требуется.
Установите дополнительные разделяемые объектные файлы
Установите в новый кластер все нестандартные разделяемые объектные файлы (или DLL), которые использовались в старом кластере, например, pgcrypto.so, где бы они ни находились — в contrib или в другом месте. Устанавливать определения схемы (например, CREATE EXTENSION pgcrypto) не требуется, так как они будут перенесены из старого кластера. Кроме того, в новый кластер нужно скопировать и все нестандартные файлы поддержки полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов).
Настроить аутентификацию
Программа pg_upgrade будет подключаться к новому и старому серверу несколько раз, так что имеет смысл установить режим аутентификации peer в pg_hba.conf или использовать файл ~/.pgpass (см. Раздел 32.15).
Остановить оба сервера
Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:
pg_ctl -D /opt/PostgreSQL/8.4 stop pg_ctl -D /opt/PostgreSQL/9.0 stop
А в Windows, с соответствующими именами служб:
NET STOP postgresql-8.4 NET STOP postgresql-9.0
Ведомые серверы с потоковой репликацией и трансляцией журнала могут продолжать работать до последнего шага.
Подготовиться к обновлению ведомых серверов
Если вы производите обновление ведомых серверов (как описано в разделе Шаг 10), удостоверьтесь, что эти серверы находятся в актуальном состоянии, запустив pg_controldata в старых ведущем и ведомых кластерах. Убедитесь в том, что «Положение последней контрольной точки» во всех кластерах одинаковое. (Несовпадение будет иметь место, если старые ведомые серверы будут отключены раньше, чем старый ведущий.) Также смените wal_level на replica в файле postgresql.conf нового ведущего кластера.
Запустить pg_upgrade
Всегда запускайте программу pg_upgrade от нового сервера, а не от старого. pg_upgrade требует указания каталогов данных старого и нового кластера, а также каталогов исполняемых файлов (bin). Вы можете также определить имя пользователя и номера портов, и следует ли ограничиться ссылкой на данные, а не копировать их (по умолчанию).
Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_xlog могут находиться в других файловых системах.) Полный список параметров вы можете получить, выполнив pg_upgrade --help.
Параметр --jobs позволяет задействовать для копирования/связывания файлов и для выгрузки/перезагрузки схем баз данных несколько процессорных ядер. В качестве начального значения параметра стоит выбрать максимум из числа процессорных ядер и числа табличных пространств. Этот параметр может радикально сократить время обновления сервера со множеством баз данных, работающего в многопроцессорной системе.
В Windows вы должны войти в систему с административными полномочиями, затем запустить командную строку от имени пользователя postgres, задать подходящий путь:
RUNAS /USER:postgres "CMD.EXE" SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin;
Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:
pg_upgrade.exe --old-datadir "C:/Program Files/PostgreSQL/8.4/data" --new-datadir "C:/Program Files/PostgreSQL/9.0/data" --old-bindir "C:/Program Files/PostgreSQL/8.4/bin" --new-bindir "C:/Program Files/PostgreSQL/9.0/bin"
При запуске pg_upgrade проверит два кластера на совместимость и, если всё в порядке, выполнит обновление. Также возможно запустить pg_upgrade --check, чтобы ограничиться только проверками (при этом старый сервер может продолжать работать). Команда pg_upgrade --check также сообщит, какие коррективы вам нужно будет внести вручную после обновления. Если вы планируете использовать режим ссылок на данные, укажите вместе с --check параметр --link, чтобы были проведены специальные проверки для этого режима. Программе pg_upgrade требуются права на запись в текущий каталог.
Очевидно, никто не должен обращаться к кластерам в процессе обновления. Программа pg_upgrade по умолчанию запускает серверы с портом 50432, чтобы не допустить нежелательных клиентских подключений. В процессе обновления оба кластера могут использовать один номер порта, так как они не будут работать одновременно. Однако для проверки старого работающего сервера новый порт должен отличаться от старого.
Если при восстановлении схемы базы данных происходит ошибка, pg_upgrade завершает свою работу и вы должны вернуться к старому кластеру, как описывается ниже в Шаг 16. Чтобы попробовать pg_upgrade ещё раз, вы должны внести коррективы в старом кластере, чтобы pg_upgrade могла успешно восстановить схему. Если проблема возникла в модуле contrib, может потребоваться удалить этот модуль contrib в старом кластере, а затем установить его в новом после обновления (предполагается, что этот модуль не хранит пользовательские данные).
Обновить ведомые серверы с потоковой репликацией и трансляцией журнала
Если вы используете режим ссылок и у вас реализована потоковая репликация (см. Подраздел 26.2.5) или трансляция журнала (см. Раздел 26.2) для ведомых серверов, вы можете быстро обновить эти серверы следующим образом. Вам не нужно будет запускать на них pg_upgrade, вместо этого вы выполните rsync на ведущем. Не запускайте никакие серверы на этом этапе.
Если вы не используете режим ссылок, либо у вас нет rsync или вы не хотите его использовать, либо если вам нужен более простой вариант, пропустите инструкции в этом разделе и просто пересоздайте ведомые серверы сразу после завершения pg_upgrade и запуска нового ведущего сервера.
1. Установите новые исполняемые файлы PostgreSQL на ведомых серверах
  Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.
2. Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют
  Новые каталоги данных ведомых серверов должны отсутствовать либо быть пустыми. Если запускалась программа initdb, удалите новые каталоги данных на ведомых.
3. Установите дополнительные разделяемые объектные файлы
  Установите на новых ведомых серверах те же дополнительные разделяемые объектные файлы, что вы установили в новом ведущем кластере.
4. Остановите ведомые серверы
  Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.
5. Сохраните файлы конфигурации
  Сохраните все нужные вам файлы конфигурации из старых каталогов данных ведомых серверов, в частности postgresql.conf и recovery.conf, так как они будут перезаписаны или удалены на следующем этапе.
6. Запустите rsync
  Когда используется режим ссылок, ведомые серверы можно быстро обновить, применив rsync. Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем:
  rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
  Здесь каталоги old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится над каталогами старого и нового кластера на ведомом. Структура подкаталогов в заданных каталогах на ведущем и ведомых серверах должна быть одинаковой. Обратитесь к странице руководства rsync, где подробно описано, как указать удалённый каталог, например так:
  rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \ /opt/PostgreSQL/9.6 standby.example.com:/opt/PostgreSQL
  Проверить, что будет делать команда, можно, воспользовавшись параметром rsync --dry-run. Выполнить rsync на ведущем необходимо как минимум с одним ведомым, но затем, пока обновлённый ведомый остаётся остановленным, можно запускать rsync на нём для обновления других ведомых.
  В ходе этой операции записываются ссылки, созданные режимом ссылок pg_upgrade, связывающие файлы нового и старого кластера на ведущем сервере. Затем в старом кластере ведомого находятся соответствующие файлы и в новом кластере ведомого создаются ссылки на них. Файлы, не связанные ссылками на ведущем, копируются с него на ведомый. (Обычно их объём невелик.) Это позволяет произвести обновление ведомого быстро. К сожалению, при этом rsync будет напрасно копировать файлы, связанные с временными и нежурналируемыми таблицами, так как они обычно не будут существовать на ведомых серверах.
  Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств:
  rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \ /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp
  Если вы вынесли pg_xlog за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.
7. Настройте ведомые серверы с потоковой репликацией и трансляцией журнала
  Настройте серверы для трансляции журнала. (Запускать pg_start_backup() и pg_stop_backup() или делать копию файловой системы не нужно, так как ведомые серверы остаются синхронизированными с ведущим.)
Восстановить pg_hba.conf
Если вы изменяли pg_hba.conf, восстановите его исходное состояние. Также может потребоваться скорректировать другие файлы конфигурации в новом кластере, чтобы они соответствовали старому, например postgresql.conf.
Запустить новый сервер
Теперь можно безопасно запустить новый сервер, а затем ведомые серверы, синхронизированные с ним с помощью rsync.
Действия после обновления
Если после обновления требуются какие-то дополнительные действия, программа pg_upgrade выдаст предупреждения об этом по завершении работы. Она также сгенерирует файлы скриптов, которые должны запускаться администратором. Эти скрипты будут подключаться к каждой базе данных, требующей дополнительных операций. Каждый такой скрипт следует выполнять командой:
psql --username postgres --file script.sql postgres
Эти скрипты могут выполняться в любом порядке, а после выполнения их можно удалить.
Внимание
Обычно к таблицам, задействованным в перестраивающих базу скриптах, опасно обращаться, пока эти скрипты не сделают свою работу; при этом можно получить некорректный результат или плохую производительность. К таблицам, не задействованным в таких скриптах, можно обращаться немедленно.
Статистика
Так как статистика оптимизатора не передаётся в процессе работы pg_upgrade, вы получите указание запустить соответствующую команду для воссоздания этой информации после обновления. Возможно, для этого вам понадобится установить параметры подключения к новому кластеру.
Удалить старый кластер
Если вы удовлетворены результатами обновления, вы можете удалить каталоги данных старого кластера, запустив скрипт, упомянутый в выводе pg_upgrade после обновления. (Автоматическое удаление невозможно, если в старом каталоге данных находятся дополнительные табличные пространства.) Также вы можете удалить каталоги старой инсталляции (например, bin, share).
Возврат к старому кластеру
Если выполнив команду pg_upgrade, вы захотите вернуться к старому кластеру, возможны следующие варианты:
- Если pg_upgrade запускалась с ключом --check, никакие изменения в старом кластере не производились и его использование можно продолжить в любой момент.
- Если pg_upgrade запускалась с параметром --link, файлы данных будут разделяться старым и новым кластером. Если новый кластер уже запускался, он произвёл запись в эти файлы, так что использовать старый кластер небезопасно.
- Если pg_upgrade запускалась без ключа --link или новый сервер не запускался, старый кластер не претерпел никаких изменений, за исключением того, что в режиме ссылки на данные к имени $PGDATA/global/pg_control было добавлено окончание .old. Чтобы продолжить использование старого кластера, можно просто убрать окончание .old из имени файла $PGDATA/global/pg_control; после этого старый кластер можно будет перезапустить.

postgrespro.ru

PostgreSQL : Документация: 9.4: Запуск сервера баз данных : Компания Postgres Professional

Для запуска во FreeBSD воспользуйтесь файлом contrib/start-scripts/freebsd в дереве исходного кода PostgreSQL.
В OpenBSD, добавьте в файл /etc/rc.local следующие строки:
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data' echo -n ' postgresql' fi
В системах Linux вы можете либо добавить
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
в /etc/rc.d/rc.local или в /etc/rc.local, либо воспользоваться файлом contrib/start-scripts/linux в дереве исходного кода PostgreSQL.
В NetBSD можно использовать скрипт запуска для FreeBSD или для Linux, в зависимости от предпочтений.
В Solaris, создайте файл с именем /etc/init.d/postgresql, содержащий следующую стоку:
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
Затем создайте символическую ссылку на него в каталоге /etc/rc3.d с именем S99postgresql.

Следующее сообщение:

Сообщение:

Если вы получаете ошибку "illegal system call" (неверный системный вызов), то, вероятнее всего, ваше ядро вовсе не поддерживает разделяемую память или семафоры. В этом случае, вам остаётся только переконфигурировать ядро и включить их поддержку.

Настройка средств IPC в стиле System V описывается в Подразделе 17.4.1.

Это общая проблема "я не могу найти сервер и начать взаимодействие с ним". Показанное выше сообщение говорит о попытке установить подключение по TCP/IP. Очень часто объясняется это тем, что сервер просто забыли настроить для работы по протоколу TCP/IP.

Кроме того, при попытке установить подключение к локальному серверу через доменный сокет Unix можно получить такое сообщение:

Путь в последней строке помогает понять, к правильному ли адресу пытается подключиться клиент. Если сервер на самом деле не принимает подключения по этому адресу, обычно выдаётся сообщение ядра Connection refused (В соединении отказано) или No such file or directory (Нет такого файла или каталога), приведённое выше. (Важно понимать, что Connection refused в данном контексте не означает, что сервер получил запрос на подключение и отверг его. В этом случае были бы выданы другие сообщения, например, показанные в Разделе 19.4.) Другие сообщения об ошибках, например Connection timed out (Таймаут соединения) могут сигнализировать о более фундаментальных проблемах, например, о нарушениях сетевых соединений.

postgrespro.ru

17.3. Запуск сервера баз данных. Сервер postgresql

Установка PostgreSQL — пошаговое описание процесса

Пара слов о железе

Процесс установки и настройки PosgreSQL вкратце:

(adsbygoogle = window.adsbygoogle || []).push({}); Шаг 1. Установка PostgreSQL

Как инсталлировать PostgreSQL, какие есть нюансы?

Шаг 2. Настройка параметров запуска PostgreSQL

Шаг 3. Создание хранилища данных PostgreSQL

PostgreSQL : Документация: 9.6: 18.3. Запуск сервера баз данных : Компания Postgres Professional

18.3. Запуск сервера баз данных

18.3.1. Сбои при запуске сервера

18.3.2. Проблемы с подключениями клиентов

PostgreSQL : Документация: 9.5: 17.3. Запуск сервера баз данных : Компания Postgres Professional

17.3. Запуск сервера баз данных

17.3.1. Сбои при запуске сервера

17.3.2. Проблемы с подключениями клиентов

PostgreSQL : Документация: 10: 18.3. Запуск сервера баз данных : Компания Postgres Professional

18.3. Запуск сервера баз данных

18.3.1. Сбои при запуске сервера

18.3.2. Проблемы с подключениями клиентов

Настройка потоковой репликации Postgresql сервера (WAL-репликация)

Настраиваем MASTER-сервер

Настраиваем SLAVE-сервер

Диагностика репликации

PostgreSQL : Документация: 9.6: pg_upgrade : Компания Postgres Professional

Внимание

PostgreSQL : Документация: 9.4: Запуск сервера баз данных : Компания Postgres Professional

Шаг 1. Установка PostgreSQL