Postgres как поставить 2 кластера ubuntu

Обновлено: 06.07.2024

С точки зрения файловой системы, кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в /usr/local/pgsql/data или в /var/lib/pgsql/data . Для инициализации кластера баз данных применяется команда initdb , которая устанавливается в составе PostgreSQL . Расположение кластера базы данных в файловой системе задаётся параметром -D , например:

Заметьте, что эту команду нужно выполнять от имени учётной записи PostgreSQL , о которой говорится в предыдущем разделе.

Подсказка

В качестве альтернативы параметра -D можно установить переменную окружения PGDATA .

Также можно запустить команду initdb , воспользовавшись программой pg_ctl , примерно так:

Этот вариант может быть удобнее, если вы используете pg_ctl для запуска и остановки сервера (см. Раздел 18.3), так как pg_ctl будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.

Команда initdb попытается создать указанный вами каталог, если он не существует. Конечно, она не сможет это сделать, если initdb не будет разрешено записывать в родительский каталог. Вообще рекомендуется, чтобы пользователь PostgreSQL был владельцем не только каталога данных, но и родительского каталога, так что такой проблемы быть не должно. Если же и нужный родительский каталог не существует, вам нужно будет сначала создать его, используя права root, если вышестоящий каталог защищён от записи. Таким образом, процедура может быть такой:

Команда initdb не будет работать, если указанный каталог данных уже существует и содержит файлы; это мера предохранения от случайной перезаписи существующей инсталляции.

Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого initdb лишает прав доступа к нему всех пользователей, кроме пользователя PostgreSQL и, возможно, его группы. Если группе разрешается доступ, то только для чтения. Это позволяет непривилегированному пользователю, входящему в одну группу с владельцем кластера, делать резервные копии данных кластера или выполнять другие операции, для которых достаточно доступа только для чтения.

Заметьте, чтобы корректно разрешить или запретить доступ группы к данным существующего кластера, необходимо выключить кластер и установить соответствующий режим для всех каталогов и файлов до запуска PostgreSQL . В противном случае в каталоге данных возможно смешение режимов. Для кластеров, к которым имеет доступ только владелец, требуется установить режим 0700 для каталогов и 0600 для файлов, а для кластеров, в которых также разрешается чтение группой, режим 0750 для каталогов и 0640 для файлов.

Однако даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды initdb : -W , --pwprompt или --pwfile и назначить пароль суперпользователя баз данных. Кроме того, воспользуйтесь параметром -A md5 или -A password и отключите разрешённый по умолчанию режим аутентификации trust ; либо измените сгенерированный файл pg_hba.conf после выполнения initdb , но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности peer или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к Главе 20.)

Команда initdb также устанавливает для кластера баз данных локаль по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к Разделу 23.1. Команда initdb задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от C и POSIX , возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.

Команда initdb также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к Разделу 23.3.

Для локалей, отличных от C и POSIX , порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.

18.2.1. Использование дополнительных файловых систем

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

Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.

среда, 13 февраля 2019 г.

Ubuntu 16.04 создание второго кластера postgresql

Дополнительный кластер postgresql может пригодится для проверки развертывания как холодного backup так и горячего с использованием pg_basebackup

$ sudo pg_createcluster --locale ru_RU.UTF-8 9.6 beta
Creating new cluster 9.6/beta .
config /etc/postgresql/9.6/beta
data /var/lib/postgresql/9.6/beta
locale ru_RU.UTF-8
socket /var/run/postgresql
port 5433
Warning: systemd does not know about the new cluster yet. Operations like "service postgresql start" will not handle it. To fix, run:
sudo systemctl daemon-reload

$ sudo systemctl daemon-reload

Не забываем про настройку postgresql.conf !
$ sudo nano /etc/postgresql/9.6/beta/postgresql.conf

Для запуска нужен restart:

$ sudo systemctl restart postgresql

$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.6 beta 5433 down postgres /var/lib/postgresql/9.6/beta pg_log/postgresql-%a.log
9.6 main 5432 online postgres /var/lib/postgresql/9.6/main pg_log/postgresql-%a.log

$ ss -tunpl | grep 5432
tcp LISTEN 0 128 *:5432 *:*
tcp LISTEN 0 128 . 5432 . *

$ ss -tunpl | grep 5433
tcp LISTEN 0 128 *:5433 *:*
tcp LISTEN 0 128 . 5433 . *

$ ps aux | grep postgres
postgres 4252 0.0 0.0 315616 27704 ? S 18:18 0:00 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib postgresql/9.6/beta -c config_file=/etc/postgresql/9.6/beta/postgresql.conf
postgres 4253 0.0 0.5 4597816 182016 ? S 18:18 0:00 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf
.

Сделаем холодный backup кластера main:

Имя базы рекомендую указать с указанием кластера:

Удаление кластера.
После работы с дополнительным кластером можно его удалить:

$ sudo pg_dropcluster --stop 9.6 beta
$ sudo systemctl daemon-reload
$ sudo systemctl restart postgresql

Важно:
Если не будете делать restore, нужно задать пароль:
$ sudo -u postgres psql -U postgres -p 5433 -c "alter user postgres with password 'pass';"
$ sudo -u postgres psql -U postgres -c "alter user postgres with password 'pass';"

Получил задание на работе: установить линукс, 1с, postgres и подрубить непрерывное архивирование. Дело легкое, но при сдаче мне сказали, что на сервере будет 2 базы. И это была проблема, т.к восстанавливать определенную базу на определенный момент нельзя - весь кластер будет откатываться до необходимой отметки и затрагивать вторую рабочую базу. Сразу в голову приходит мысль о втором кластере, но доходчивой инфы в интернете мало поэтому на освоение этой темы мне понадобилось 3 дня и 3 ночи.

Даю вам все готовое.

Создаем каталоги и выдаем права

Создаем второй кластер

Перед запуском необходимо поменять порт

Скрипт для запуска второго кластера при запуске машины. Задержка на запуск скрипта обязательна, можете указать минуту.

Теперь давайте зайдем в 1С и создадим базу на втором кластере

Про непрерывное архивирование.

Включение и настройка такая же, как и на первом кластере. Важно не забывать, что конфиг второго кластера лежит в самом кластере, поэтому сначала восстаналивайтесь из архива, а после прописывайте параметры восстановления.

Специальные предложения

Это что за шаманство такое? Почему обязательна? Почему вообще понадобился скрипт, а не был использован стандартный механизм через systemd?
(1)Пробовал, не получалось. Попробуйте проделать это сами и отпишите.
В смысле сделать статью на эту тему? У нас на разных проектах в разных вариантах ПГ запускается через systemd и все ок ;) (3)Я говорю за второй кластер, лично у меня не получалось.
Покажите распишите как, что буду благодарен

Просмотры 658

Загрузки 0

Рейтинг 2

Создание 08.09.21 13:30

Обновление 08.09.21 13:30

№ Публикации 1511413

Тип файла Нет файла

Конфигурация Не имеет значения

Операционная система Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)

Код открыт Да

См. также

Базовые приемы работы с кластером 1С при помощи БСП

В данной публикации я рассматриваю базовые приемы работы с кластером серверных баз 1С, используя типовые типовые возможности библиотеки стандартных подсистем (БСП).

26.10.2021 3020 quazare 6

Обновление платформы 1С тонкого клиента с вебсервера, когда сервер 1С ПРОФ

19.10.2021 1419 ser6702 13

Клиент-серверный режим базы данных 1С8 для тестирования

В публикации рассматриваются некоторые аспекты настройки базы данных 1С8.3 в серверном режиме, для тестирования обработок или расширений.

30.09.2021 1324 etmarket 3

Зависание базы при создании/редактировании пользователей после конвертации базы с платформы 8.1 на 8.3

При переводе базы с платформы 8.1 на платформу 8.3 возникает проблема - база конвертится замечательно, но при редактировании или создании новых пользователей база напрочь зависает. Речь пойдёт о серверной базе данных.

29.09.2021 438 Kitri 4

Перекуем Cloud на Oracle. Тестируем размещение 1С в облачной платформе Oracle Cloud.

После цикла публикаций про размещение 1С в облачных сервисах я думал, что все различные варианты рассмотрены и тема для меня закрыта. Однако есть события, мимо которых не пройти. Так вот и сейчас, когда наблюдается аттракцион невиданной щедрости от Oracle, мимо этого просто так не пройти.

02.09.2021 667 capitan 22

Метод быстрой реструктуризации больших таблиц (10 миллионов записей и более) через SQL Server Managment Studio

Бывает так, что в какой-то объект метаданных решают добавить новый реквизит или даже табличную часть, а чуть позже выясняется, что таблица насчитывает десятки или даже сотни миллионов записей. Как-же быть в таком случае?

30.08.2021 4756 orfos 64

Исправление ошибки плана обслуживания MS SQL

Частный случай решения ошибки выполнения планов обслуживания MS SQL.

20.08.2021 863 TokarevV 1

Показатель Page Life Expectancy (PLE)

18.08.2021 1409 vasilev2015 6

Кластер для отказоустойчивости

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021 2478 FB_3393521717335803 0

Что на самом деле делает администратор базы данных (DBA)?

17.08.2021 1986 vasilev2015 2

Почему PostgreSQL не лучше MS SQL

На онлайн-митапе "PostgreSQL VS Microsoft SQL" выступил с докладом руководитель ИТ в компании "Инфософт" Антон Дорошкевич. Он сравнил работу MS SQL и PostgreSQL, поделился методическим пособием по настройке PostgreSQL для 1С и объяснил, кому нужно перейти на новую СУБД, а кому лучше работать с тем, что есть.

09.08.2021 18513 a.doroshkevich 53

Обновление 1С: Розницы с релиза 2.3.8.27 до 2.3.9.28

Многие уже столкнулись с тем, что не смогли обновить 1С: Розницу релиз 2.3.8.27 на более поздние релизы. Напомню, релиз 2.3.8.27 - позволял-таки нам работать в ЕГАИС 4. Но а вот с дальнейшими обновлениями.

05.07.2021 6152 13D 25

Как подключиться к хранилищу конфигурации на сервере за NAT, если есть доступ по RDP?

В статье находится инструкция по подключению базы 1С к хранилищу конфигурации, если хранилище не опубликовано в интернет, но опубликовано по TCP в локальной сети клиента.

01.06.2021 2618 Dipod 13

Как получить полный доступ к данным файловой базы 1С

Опыт перевода файловой базы 1С в клиент-серверный вариант работы при отсутствии административного доступа (авторизации) в базе.

31.05.2021 1436 info1i 2

Как добыть последнюю версию SQL Server 2012 Native Client

Краткое руководство администраторам 1С по получению свежей версии SQL Server 2012 Native Client, необходимого для работы сервера 1С.

13.05.2021 2004 tedkuban 3

Простой метод установки postgresql-12 от 1С на Archlinux/Manjaro

Инструкция по установке дистрибутива postgresql-12 от 1С на Arch и Manjaro, совсем без красноглазия

02.05.2021 1044 cdiamond 4

Ускорение реструктуризации больших таблиц. Мой вариант

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

28.04.2021 1310 buganov 0

Xubuntu 20.04 для бухгалтера 1С

В публикации представлен необходимый минимум для настройки Xubuntu 20.04 в качестве рабочего места бухгалтера, ведущего учёт в программе 1С: Бухгалтерия 3.0 файловый вариант. Кроме этого, настроено подключение и других сотрудников через тонкий клиент 1С к опубликованной на веб-сервере базе бухгалтерии.

12.04.2021 4777 compil7 25

Режим совместимости конфигурации 1С

Приветствую, коллеги! В этой статье будет сделан обзор функции совместимости конфигурации 1С с другими версиями конфигураций 1С, а также рассмотрено, как выбрать и настроить режим совместимости конфигурации с версией 1С 8.3. Во-первых, разберём главное понятие в этой статье: режим совместимости в конфигурации – это устройство, благодаря которому выводится номер версии системы, под которую станет открыто приложение 1С:Предприятие. Данный режим существует на платформе 1С начиная с версий 8.2 и 8.3 (платформа версии 1С:Предприятие 8.3 совместима с платформой версии 1С:Предприятие 8.2).

31.03.2021 5809 Koder_Line 3

Как мы на Managed Service for SQL Server в Yandex.Cloud переезжали

Рассказ про грабли при переезде на Yandex Managed Service for SQL Server и DataLens.

02.02.2021 1267 dsdred 5

Платформа 8.3.18 Обновление ИБ в пакетном режиме поломалось? Решено

Уже давно работаем с большим количеством ИБ и обновляем, естественно, в пакетном режиме, но с переходом на новую платформу 8.3.18.1208 этот пакетный режим поломался. Стало появляться окно конфигуратора и спрашивать вопросы, раньше такого не было. Решение найдено.

24.12.2020 6249 VPanin56 14

Пример отправки логов из MS Sql Server с использованием бота Telegram и PowerShell.

26.11.2020 1985 ivv1970 9

Сравнение архитектуры двух СУБД.

Избранные административные представления.

09.09.2020 2262 vasilev2015 4

Сбой, отказ 1C:Предприятия 7.7, код исключения e06d7363. APPCRASH 1cv7s.exe

Прекращена работа программы "1CV7 starter program". Никто не может зайти в 1C 7.7. Апкреш. Что делать? Проверьте, возможно журнал регистрации информационной базы 1С: Предприятия 7.7 поврежден.

17.08.2020 2086 ksnik 3

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант. Моя практика.

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант.

06.08.2020 1108 premierex 3

Администрирование списка баз Windows правами.

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

03.08.2020 1262 sergey279 0

Линукс как основной многофункциональный сервер небольшой компании. Наш опыт

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

08.06.2020 6160 ogroup 22

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

Приветствую, хаброжители!
В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.

Схема кластера и требования к машинам

На рисунке представлена типичная схема кластера Master-slave.

Кластер должен содержать 1 ведущий сервер (Master), хотя бы 1 ведомый (Slave), 1 узел масштабирования (Balancer).
При на каждый из серверов должен быть установлен Linux-дистрибутив (у меня поставлен Red Hat 6.1), на узле масштабирования должен установлен компилятор gcc.
Версия PostgreSQL — 9.0.1, pgpool-II 3.0.5. Можно использовать и другие версии СУБД и pgpool. При этом обратитесь к документации.

Настройка удаленного соединения между серверами кластера

Online recovery и failover требуют настройки удаленного соединения по протоколу SSH без пароля. Для этого нужно создать SSH-ключи пользователя postgres и разослать их пользователям postgres каждому из серверов.
Важный момент! Для online recovery необходимо, чтобы при открытии удаленной сессии можно было перейти в еще одну удаленную сессию (т.е. можно было реализовать следующий механизм перехода по SSH без пароля: узел масштабирования — ведущий сервер — ведомый сервер и узел масштабирования — ведомый сервер — ведущий сервер).
Для failover необходимо создать SSH-ключ пользователя root на узле масштабирования и переслать пользователям postgres ведущего и ведомого сервера.
Этот шаг является важным при настройке, поэтому убедитесь, что возможно подключение из удаленной сессии одного из серверов к другому.

Настройка потоковой репликации

Предварительно нужно открыть прием/передачу данных по порту 5432 (стандартный порт PostgreSQL) в iptables.
Отредактируйте конфигурационный файл $PGDATA/postgresql.conf ведущего сервера следующим образом:

Отмечу важность последней строки. Дело в том, что она будет использована в скрипте восстановления ведомого узла, поэтому ее нужно обязательно изменить так, как написано выше.
Далее добавляем строчки для репликации в $PGDATA/pg_hba.conf :

postgres — это администратор базы, который будет проводить репликацию и прочие админские хитрости. С помощью этих строк мы разрешили производить репликацию как ведомого, так и ведущего сервера.
После чего перегружаем ведущий сервер:

Останавливаем ведомый сервер (если был запущен ранее):

Теперь можно приступать к репликации.
На ведущем сервере пользователем postgres создаем backup базы пересылаем ведомому серверу:

После чего на ведомом создаем конфиг репликации $PGDATA/recovery.conf :

Параметр trigger_file отвечает за путь, по которому PostgreSQL ищет файл, чтобы переключиться в режим ведущего. В данном случае PostgreSQL ищет файл по пути $PGDATA/failover .
Далее нужно включить режим «горячего резерва» на ведомом сервере:

После чего нужно запустить ведомый сервер:

Активность репликации можно проверить следующим образом:
На ведущем сервере выполнить команду

Она должна вывести приблизительно следующее:

Аналогично на ведомом сервере:

Она выдаст следующее:

Общая настройка узла масштабирования

Меняем конфигурационный файл /etc/pgpool-II/pgpool.conf :

Далее в /etc/pgpool-II/pool_hba.conf добавляем информацию об авторизации клиентов:

Настройка автоматического failover

На рабочих (ведущем и ведомом) серверах выполняется процедура pgpool-walrecrunning() , определяющая, какой из серверов является ведущим, какой ведомый.
pgpool удаленно подключается к рабочим серверам и проверяет активность процессов СУБД. Если нет, то pgpool вызывает скрипт, который создает failover на ведомом узле в случае отказа ведущего сервера.
После чего pgpool отключается от упавшего узла и перезапускает все клиентские приложения, подключенные к нему.

Расскажу немного подробнее про параметр failover_command . Скрипту, указанному в этой строке, передаются параметры %d — идентификатор упавшего узла (согласно backend_hostname в pgpool.conf ), %H — IP нового ведущего сервера.
Собственно сам скрипт failover.sh :

Этот скрипт нужно создать в каталоге pgpool /etc/pgpool-II/ и выдать права 755.
Теперь нужно скомпилировать процедуры pgpool. В src пакета pgpool в каталоге sql/pgpool-walrecrunning содержится исходный код нужной нам процедуры. Для ее компилирования нужны заголовочные файлы PostgreSQL, после чего можно воспользоваться командой make и получить pgpool-walrecrunning.so и SQL-запрос загрузки этой процедуры pgpool-walrecrunning.sql .
Процедуру нужно скопировать в каталог на каждом рабочем сервере /usr/lib64/pgsql/ , который именуется $libdir , sql-файл в /usr/share/pgsql/ .
Загружаем в базу на ведущем сервере:

Загрузку в базу этой процедуры на ведомом сервере нет необходимости: она будет доступна благодаря настроенной ранее репликации.
Вот и все.

Статус серверов можно определить с помощью запроса предварительно зайдя в клиент psql на узле масштабирования.
Пример вывода запроса:
Статус сервера 2 означает, что сервер активен и доступен для запросов. В случае отказа одного из серверов статус изменится на 3.

Отключить ведущий сервер
Выполнить запрос SHOW pool_nodes; на узле масштабирования
Смотреть логи pgpool на предмет выполнения скрипта
Убедиться в том, что ведомый сервер после выполнения скрипта может принимать запросы на запись

Online recovery

На узле масштабирования запускается процедура восстановления ведомого сервера
Эта процедура на ведущем сервере запускает скрипт, выполняющий автоматическую репликацию между ведущим и ведомым сервером
После успешного выполнения репликации, база на ведущем сервере удаленно запускается с помощью стандартной утилиты PostgreSQL PGCTL
pgpool перезапускается, обнаруживает ведомый сервер и включает его в кластер

Добавить хэш пароля postgres :

123456 — это пароль postgres в открытом виде. При этом дополнительно перед хэшем пароля нужно указать имя пользователя, кому этот хэш принадлежит, т.е. в файле должно быть строка postgres:enrypted_password .
На ведущем узле создать скрипт basebackup.sh следующего содержания:

Подчеркиваю, этот скрипт должен быть в каталоге $PGDATA . Скрипту назначить права 755.
На ведомом и ведущем сервере в каталоге $PGDATA создать скрипт pgpool_remote_start (Именно под таким именем!) со следующим содержанием:

Он позволит удаленно запускать процессы СУБД.
Далее на узле масштабирования нужно скомпилировать хранимую процедуру pgpool-recovery.so , расположенную по пути sql/pgpool-recovery src пакета pgpool. Аналогичным образом переслать ее рабочим серверам и выполнить загрузку процедуру в базу:

На этом настройка online recovery закончена.

Запустить базу на новом ведущем узле
На узле масштабирования выполнить команду по восстановлению сервера: pcp_recovery_node 20 192.168.100.4 9898 postgres 123456 1

Создать тестовую базу данных на ведущем сервере. Убедиться, что она реплицировалась на ведомый
Имитировать отказ ведущего сервера, отключив его
Убедиться, что сработал failover и ведомый сервер стал новым ведущим
Внести изменения в базу данных на ведомом сервере
Запустить упавший ведущий сервер и сделать его ведомым, проведя online recovery

Таким образом, описанные выше механизмы позволяют обезопасить кластер «Ведущий-ведомый» и упростить работу администратора базы данных при ее восстановлении.

Читайте также: