mysql, ubuntu

кластер Postgres на Ubuntu с помощью Patroni + Consul

Thank you for reading this post, don't forget to subscribe!

Кла­стер Postgresql, создан­ный штат­ны­ми сред­ства­ми не совсем удо­бен в экс­плу­а­та­ции — у него слож­ные меха­низ­мы отсле­жи­ва­ния про­блем с репли­ка­ци­ей, нет воз­мож­но­сти авто­ма­ти­че­ско­го пере­клю­че­ния с основ­ной ноды на резерв­ную и обрат­но, слож­ный про­цесс вос­ста­нов­ле­ния после паде­ния. При­ло­же­ние Patroni поз­во­ля­ет сде­лать про­цесс управ­ле­ния кла­сте­ром Postgresql про­ще. Оно хра­нит дан­ные кла­сте­ра в базе типа key-value и ори­ен­ти­ру­ет­ся на рабо­то­спо­соб­ность систе­мы с помо­щью DCS (Distributed Control Service). В каче­стве таких систем для Patroni могут выступать:

Consul Hashicorp.
Kubernetes.
Zookeeper.
etcd.

В дан­ной инструк­ции мы рас­смот­рим про­цесс уста­нов­ки и настрой­ки Patroni с Consul.

Установка и запуск PostgreSQL на Ubuntu

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

Версия репозитория

В зави­си­мо­сти от вер­сии опе­ра­ци­он­ной систе­мы, из короб­ки будет уста­нов­ле­на своя вер­сия СУБД. Если для нас вер­сия не прин­ци­пи­аль­на, про­сто вво­дим команду:

apt install postgresql postgresql-contrib

Разные версии PostgreSQL

Для уста­нов­ки более све­жей вер­сии PostgreSQL на Ubuntu, необ­хо­ди­мо под­клю­чить репозиторий:

echo "deb [arch=amd64] http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list

Импор­ти­ру­ем GPG ключ репозитория:

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

После чего обнов­ля­ем спи­сок пакетов:

apt update

Уста­нав­ли­ва­ем postgres:

apt install postgresql-14 postgresql-contrib

* в дан­ном при­ме­ре будет уста­нов­лен postgresql вер­сии 14.

Гото­во. Мы уже можем исполь­зо­вать СУБД.

Тестовое подключение

Захо­дим в систе­му под учет­ной запи­сью postgres:

su - postgres

Под­клю­ча­ем­ся к СУБД:

psql

Дела­ем тесто­вый запрос на полу­че­ние спис­ка таблиц:

=# \dt *

Мы долж­ны уви­деть что-то на подобие:

Выхо­дим из обо­лоч­ки psql:

=# \q

Отклю­ча­ем­ся от систе­мы поль­зо­ва­те­лем postgres:

exit

Установка и настройка кластера Consul Hashicorp на Linux Ubuntu

Подготовка сервера

Выпол­ним пред­ва­ри­тель­ные опе­ра­ции по настрой­ке наших сер­ве­ров. На каж­дой ноде выпол­ня­ем дан­ные действия.

1. Уста­нов­ка допол­ни­тель­ных пакетов

Обнов­ля­ем спи­сок пакетов:

apt update

Выпол­ня­ем команду:

apt install unzip wget

* где:

  • unzip — необ­хо­дим для рас­па­ков­ки архивов.
  • wget — ути­ли­та для загруз­ки фай­лов по сети.

2. Настра­и­ва­ем время

Зада­ем часо­вой пояс:

timedatectl set-timezone Europe/Moscow

* в дан­ном при­ме­ре мы зада­ем мос­ков­ское вре­мя. Пол­ный пере­чень воз­мож­ных вари­ан­тов мож­но полу­чить коман­дой: timedatectl list-timezones.

Уста­нав­ли­ва­ем ути­ли­ту для син­хро­ни­за­ции времени:

apt install chrony

Запус­ка­ем ее в каче­стве сервиса:

systemctl enable chrony

3. Настрой­ка име­ни серверов

Для сер­ве­ра кон­сул важ­но, что­бы сер­ве­ры были доступ­ны по име­нам. Пред­по­ло­жим, что наши сер­ве­ры име­ют сле­ду­ю­щие назва­ния и IP-адреса:

  1. consul01.test.local (192.168.0.15)
  2. consul02.test.local (192.168.0.20)
  3. consul03.test.local (192.168.0.25)

Тогда вво­дим команды.

а) Сер­вер 1:

hostnamectl set-hostname consul01.test.local

б) Сер­вер 2:

hostnamectl set-hostname consul02.test.local

в) Сер­вер 3:

hostnamectl set-hostname consul03.test.local

Что­бы сер­ве­ры мог­ли обра­щать­ся друг к дру­гу по име­нам, мы долж­ны либо заре­ги­стри­ро­вать их в локаль­ной систе­ме DNS, либо доба­вить на каж­дом сер­ве­ре запи­си в файл hosts:

vi /etc/hosts

192.168.0.15 consul01.test.local consul01
192.168.0.20 consul02.test.local consul02
192.168.0.25 consul03.test.local consul03

Про­ве­рить доступ­ность сер­ве­ров по име­ни мож­но с помо­щью коман­ды ping. На каж­дом из сер­ве­ров введем:

ping consul01

ping consul02

ping consul03

4. Настрой­ка безопасности

Откры­ва­ем пор­ты в брандмауэре:

iptables -I INPUT -p tcp --match multiport --dports 8300,8301,8302,8500,8600 -j ACCEPT

iptables -I INPUT -p udp --match multiport --dports 8301,8302,8600 -j ACCEPT

Для сохра­не­ния пра­вил исполь­зу­ем ути­ли­ту iptables-persistent:

apt install iptables-persistent

netfilter-persistent save

Установка и запуск Consul

Выпол­ним уста­нов­ку ком­по­нен­тов, настрой­ку кла­сте­ра и его запуск.

Установка

Уста­нов­ка будет выпол­не­на путем копи­ро­ва­ния бинар­но­го фай­ла. Для нача­ла перей­дем на стра­ни­цу загруз­ки про­грамм­но­го про­дук­та и посмот­рим его послед­нюю версию.

После под­ста­вим нуж­ную вер­сию в пере­мен­ную (для наше­го удобства):

export VER="1.12.2"

* на момент обнов­ле­ния инструк­ции, послед­няя вер­сия была 1.12.2.

После загру­жа­ем архив с бинарником:

wget https://releases.hashicorp.com/consul/${VER}/consul_${VER}_linux_amd64.zip

И рас­па­ко­вы­ва­ем его:

unzip consul_${VER}_linux_amd64.zip

Копи­ру­ем полу­чен­ных бинар­ник в ката­лог /usr/bin:

mv consul /usr/bin/

Про­ве­ря­ем, что при­ло­же­ние может запус­кать­ся в наших системах:

consul -v

Мы долж­ны уви­деть что-то на подобие:

Consul v1.12.2
Revision 19041f20
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Мож­но пере­хо­дить к настройке.

Настройка

Созда­ем учет­ную запись, от кото­рой будет рабо­тать консул:

useradd -r -c 'Consul DCS service' consul

* в дан­ном при­ме­ре мы созда­дим учет­ную запись consul, кото­рая будет систем­ной. Так­же мы доба­вим неболь­шой комментарий.

Созда­ем ката­ло­ги для при­ло­же­ния консул:

mkdir -p /var/lib/consul /etc/consul.d

И выста­вим на них нуж­ные права:

chown consul:consul /var/lib/consul /etc/consul.d

chmod 775 /var/lib/consul /etc/consul.d

* в дан­ном при­ме­ре мы ука­за­ли, что вла­дель­цем дан­ных ката­ло­гов будет создан­ная учет­ная запись consul. Пра­ва будут пол­ные у вла­дель­ца, осталь­ные смо­гут читать данные.

Сге­не­ри­ру­ем ключ для кон­су­ла на любой из нод кластера:

consul keygen

Мы полу­чим после­до­ва­тель­ность сим­во­лов, например:

wHFWVHTstpfh08ZflUs4FD2FAMueraoCN2LyqmeLxV0=

Полу­чен­ный ключ при­сва­и­ва­ем в каче­стве зна­че­ния пере­мен­ной на всех нодах:

CONSUL_TOKEN=wHFWVHTstpfh08ZflUs4FD2FAMueraoCN2LyqmeLxV0=

* где wHFWVHTstpfh08ZflUs4FD2FAMueraoCN2LyqmeLxV0= нуж­но заме­нить на тот ключ, кото­рый был сге­не­ри­ро­ван на вашем сервере.

Так­же на наших кла­стер­ных сер­ве­рах созда­дим пере­мен­ные с ука­за­ни­ем всех нод:

CONSUL_SERVER1=consul01.test.local

CONSUL_SERVER2=consul02.test.local

CONSUL_SERVER3=consul03.test.local

Созда­ем кон­фи­гу­ра­ци­он­ный файл для консула:

* мы исполь­зу­ем коман­ду для созда­ния кон­фи­гу­ра­ци­он­но­го фай­ла с ука­за­ни­ем пере­мен­ных, создан­ных ранее. Это дела­ет­ся для наше­го удоб­ства рабо­ты, что­бы вво­дить одну и ту же коман­ду на всех нодах.
** где:

  • bind_addr — адрес, на кото­ром будет слу­шать наш сер­вер кон­сул. Это может быть IP любо­го из наших сете­вых интер­фей­сов или, как в дан­ном при­ме­ре, все.
  • bootstrap_expect — мини­маль­но ожи­да­е­мое коли­че­ство сер­ве­ров в кла­сте­ре. Consul будет ждать, пока дан­ное чис­ло сер­ве­ров не ста­нет доступ­ным, толь­ко после это­го загру­зит кластер.
  • client_addr — адрес, к кото­ро­му будут при­вя­за­ны кли­ент­ские интерфейсы.
  • datacenter — при­вяз­ка сер­ве­ра к кон­крет­но­му дата­цен­тру. Нужен для логи­че­ско­го раз­де­ле­ния. Сер­ве­ры с оди­на­ко­вым дата­цен­тром долж­ны нахо­дить­ся в одной локаль­ной сети.
  • node_name — имя ноды, на кото­рой запус­ка­ет­ся сервис.
  • data_dir — ката­лог для хра­не­ния данных.
  • domain — домен, в кото­ром будет заре­ги­стри­ро­ван сервис.
  • enable_local_script_checks — раз­ре­ша­ет на аген­те про­вер­ку рабо­то­спо­соб­но­сти сервисов.
  • dns_config — пара­мет­ры для настрой­ки DNS.
  • enable_syslog — раз­ре­ше­ние на веде­ние лога.
  • encrypt — ключ для шиф­ро­ва­ния сете­во­го тра­фи­ка. В каче­стве зна­че­ния исполь­зу­ем сге­не­ри­ро­ван­ный ранее. Дол­жен быть оди­на­ко­вый на всех участ­ни­ках кластера.
  • leave_on_terminate — при полу­че­нии сиг­на­ла на оста­нов­ку про­цес­са кон­су­ла, кор­рект­но отклю­чать ноду от кластера.
  • log_level — мини­маль­ный уро­вень собы­тия для отоб­ра­же­ния в логе. Воз­мож­ны вари­ан­ты "trace", "debug", "info", "warn", and "err".
  • rejoin_after_leave — по умол­ча­нию, нода поки­да­ю­щая кла­стер не при­со­еди­ня­ет­ся к нему авто­ма­ти­че­ски. Дан­ная опция поз­во­ля­ет управ­лять дан­ным поведением.
  • retry_join — пере­чис­ля­ем узлы, к кото­рым мож­но при­со­еди­нять кла­стер. Про­цесс будет повто­рять­ся, пока не завер­шить­ся успешно.
  • server — режим рабо­ты сервера.
  • start_join — спи­сок узлов кла­сте­ра, к кото­рым про­бу­ем при­со­еди­нить­ся при загруз­ке сервера.
  • ui_config — кон­фи­гу­ра­ция для гра­фи­че­ско­го веб-интерфейса.

Посмот­реть ито­го­вую кон­фи­гу­ра­цию мож­но командой:

cat /etc/consul.d/config.json

Про­ве­ря­ем кор­рект­ность кон­фи­гу­ра­ци­он­но­го файла:

consul validate /etc/consul.d

Мы долж­ны увидеть:

…
Configuration is valid!

* так­же мы можем уви­деть неко­то­рые пре­ду­пре­жде­ния. Например:

  • Node name "consul01.test.local" will not be discoverable via DNS due to invalid characters. Появ­ля­ет­ся в слу­чае, если мы раз­ре­ша­ем имя сер­ве­ра в адрес не с помо­щью внут­рен­ней DNS, а при помо­щи фай­ла hosts.
  • bootstrap_expect > 0: expecting 3 servers. Отоб­ра­жа­ет­ся, если у нас еще настро­е­ны не все участ­ни­ки кластера.

В завер­ше­ние настрой­ки созда­дим юнит в systemd для воз­мож­но­сти авто­ма­ти­че­ско­го запус­ка сервиса:

vi /etc/systemd/system/consul.service

Пере­чи­ты­ва­ем кон­фи­гу­ра­цию systemd:

systemctl daemon-reload

Систе­ма уста­нов­ле­на, настро­е­на и гото­ва к запуску.

Запуск и проверка

Стар­ту­ем наш сервис:

systemctl start consul

Так­же раз­ре­ша­ем авто­ма­ти­че­ский старт при запус­ке сервера:

systemctl enable consul

Смот­рим теку­щее состо­я­ние рабо­ты сервиса:

systemctl status consul

Мы долж­ны уви­деть состояние:

…
Active: active (running) since …
…

Состо­я­ние нод кла­сте­ра мы можем посмот­реть командой:

consul members

А дан­ной коман­дой мож­но уви­деть допол­ни­тель­ную информацию:

consul members -detailed

Так­же у нас дол­жен быть досту­пен веб-интер­фейс по адресу:
http://<IP-адрес любо­го сер­ве­ра консул>:8500. Перей­дя по нему, мы долж­ны уви­деть стра­ни­цу со ста­ту­сом наше­го кластера.

Аутентификация

При вхо­де на веб-интер­фейс или рабо­те из команд­ной стро­ки, мы заме­тим, что систе­ма поз­во­ля­ет выпол­нять опе­ра­ции без запро­са иден­ти­фи­ка­ци­он­ных дан­ных. Если нам нуж­но обез­опа­сить систе­му, настро­им ACL и дона­стро­им сервис.

Включение ACL

Откры­ва­ем кон­фи­гу­ра­ци­он­ные фай­лы на всех нодах наше­го кластера:

vi /etc/consul.d/config.json

Добав­ля­ем строки:

* обра­ти­те вни­ма­ние, что стро­ка "ui_config": { "enabled": true }, у нас уже была в кон­фи­гу­ра­ци­он­ном фай­ле, но мы доба­ви­ли запя­тую в кон­це, так как это кри­тич­но для кон­фи­га в фор­ма­те json. Наша добав­лен­ная настрой­ка acl запре­ща­ет по умол­ча­нию доступ и тре­бу­ет вво­да токе­на безопасности.

Про­ве­ря­ем кор­рект­ность вне­сен­ных настроек:

consul validate /etc/consul.d/config.json

Если оши­бок нет, то пере­за­пус­ка­ем сервис:

systemctl restart consul

Захо­дим на веб-интер­фейс — мы обна­ру­жим, что в пра­вом верх­нем углу появи­лась ссыл­ка для вхо­да в систему:

Работа с токенами

Полу­ча­ем токен командой:

consul acl bootstrap

* если коман­да нам вер­ну­ла ошиб­ку Failed ACL bootstrapping: Unexpected response code: 500 (The ACL system is currently in legacy mode.), то зна­чит, что мы не на всех нодах при­ме­ни­ли новую настрой­ку. Про­ве­ря­ем, на всех ли сер­ве­рах кла­сте­ра вне­се­ны соот­вет­ству­ю­щие изме­не­ния по добав­ле­нию ACL.

Мы полу­чим ответ на подобие:

В дан­ном при­ме­ре 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a — нуж­ный нам для аутен­ти­фи­ка­ции SecretID. Воз­вра­ща­ем­ся в веб-интер­фей­су и про­бу­ем вой­ти в систе­му с исполь­зо­ва­ни­ем дан­но­го кода.

Если нам нуж­но уда­лить дан­ный токен, вво­дим команду:

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

export CONSUL_HTTP_TOKEN=59ac7fa8-dca6-e066-ff33-0bf9bb6f466a

* где 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a, полу­чен­ный нами SecretID.

Создать новый токен мож­но командой:

consul acl token create -policy-name global-management

Что­бы уви­деть спи­сок токе­нов, вводим:

consul acl token list

Если нам пона­до­бить­ся уда­лить токен, мы долж­ны исполь­зо­вать его AccessorID:

consul acl token delete -id 54b5f2bb-1a57-3884-f0ea-1284f84186f5

* где будет уда­лен токен с AccessorID 54b5f2bb-1a57-3884-f0ea-1284f84186f5.

Настройка политики для DNS

После вклю­че­ния ACL наша систе­ма пере­ста­нет отве­чать на запро­сы DNS. Это свя­за­но с поли­ти­кой бло­ки­ров­ки по умол­ча­нию. Для раз­ре­ше­ния запро­сов мы долж­ны создать поли­ти­ку с раз­ре­ше­ни­ем дан­ных запро­сов, полу­чить для ее токен и при­ме­нить дан­ный токен на всех нодах консула.

На одной из нод созда­ем файл с политикой:

cd /etc/consul.d/

vi dns-request-policy.txt

Созда­ем поли­ти­ку в консуле:

consul acl policy create -name "dns-requests" -rules @dns-request-policy.txt

Созда­ем токен без­опас­но­сти на осно­ве политики:

consul acl token create -description "Token for DNS Requests" -policy-name dns-requests

Мы долж­ны уви­деть что-то на подобие:

* где SecretID — это нуж­ный нам токен.

На всех ком­пью­те­рах с consul авторизовываемся:

export CONSUL_HTTP_TOKEN=59ac7fa8-dca6-e066-ff33-0bf9bb6f466a

* где 59ac7fa8-dca6-e066-ff33-0bf9bb6f466a — ранее создан­ный токен для полу­че­ния досту­па к управ­ле­нию консулом.

И вво­дим:

consul acl set-agent-token default 42bd65e5-42a5-356b-a81b-60eff20f657

* где 42bd65e5-42a5-356b-a81b-60eff20f657 — тот SecretID, кото­рый мы полу­чи­ли на осно­ве поли­ти­ки, раз­ре­ша­ю­щей запро­сы DNS.

==================================================================

 

Предварительная настройка

Преж­де чем перей­ти к настрой­ке patroni и кла­сте­ра, под­го­то­вим наши сер­ве­ры баз данных.

Настройка брандмауэра

Если на наших сер­ве­рах исполь­зу­ет­ся бранд­мау­эр, то нам нуж­но открыть порт 5432, по кото­ро­му рабо­та­ет postgresql, а так­же порт 8008 для patroni.

Вво­дим команды:

iptables -I INPUT -p tcp --dport 5432 -j ACCEPT

iptables -I INPUT -p tcp --dport 8008 -j ACCEPT

Для сохра­не­ния пра­вил вводим:

apt install iptables-persistent

netfilter-persistent save

Подготовка СУБД

Patroni само­сто­я­тель­но ини­ци­а­ли­зи­ру­ет базу и настрой­ки, поэто­му наш ката­лог с дан­ны­ми Postgresql дол­жен быть чист, а сер­вис postgresql нахо­дит­ся в выклю­чен­ном состоянии.

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

На наших сер­ве­рах СУБД смот­рим путь до ката­ло­га с данными:

su - postgres -c "psql -c 'SHOW data_directory;'"

В моем слу­чае для обо­их сер­ве­ров путь был /var/lib/postgresql/14/main — сохра­ня­ем путь. Ско­ро он нам понадобиться.

Оста­нав­ли­ва­ем сер­вис postgres и запре­ща­ем его автозапуск:

systemctl disable postgresql --now

Уда­ля­ем содер­жи­мое ката­ло­га с дан­ны­ми, путь до кото­ро­го нам вер­ну­ла коман­да SHOW data_directory:

rm -rf /var/lib/postgresql/14/main/*

Гото­во. Мож­но пере­хо­дить к уста­нов­ке и настрой­ке Patroni.

Установка и настройка Patroni

Дан­ное при­ло­же­ние раз­ра­бо­та­но на Python и тре­бу­ет уста­нов­ки как послед­не­го, так и неко­то­рых его компонентов.

Выпол­ня­ем команду:

apt install python3 python3-pip python3-psycopg2

* в нашем при­ме­ре мы будем рабо­тать с python вер­сии 3. Так­же нам нуж­на биб­лио­те­ка для рабо­ты с postgresql python3-psycopg2.

Теперь ста­вим сам patroni, как при­ло­же­ние python:

pip3 install patroni[consul]

Уста­нов­ка завер­ше­на. Пере­хо­дим к настройке.

Созда­дим ката­лог для хра­не­ния конфигурации:

mkdir /etc/patroni

И сам кон­фи­гу­ра­ци­он­ный файл:

vi /etc/patroni/patroni.yml

* дан­ные кон­фи­гу­ра­ци­он­ные фай­лы на раз­ных сер­ве­рах будут немно­го раз­ли­чать­ся. Опи­шем подроб­нее опции, на кото­рые нам нуж­но обра­тить внимание:

  • name — имя узла, на кото­ром настра­и­ва­ет­ся дан­ный конфиг.
  • scope — имя кла­сте­ра. Его мы будем исполь­зо­вать при обра­ще­нии к ресур­су, а так­же под этим име­нем будет заре­ги­стри­ро­ван сер­вис в consul.
  • consul - token — если наш кла­стер consul исполь­зу­ет ACL, необ­хо­ди­мо ука­зать токен.
  • restapi - connect_address — адрес на настра­и­ва­е­мом сер­ве­ре, на кото­рый будут при­хо­дить под­клю­че­ния к patroni.
  • restapi - auth — логин и пароль для аутен­ти­фи­ка­ции на интер­фей­се API.
  • pg_hba — блок кон­фи­гу­ра­ции pg_hba для раз­ре­ше­ния под­клю­че­ния к СУБД и ее базам. Необ­хо­ди­мо обра­тить вни­ма­ние на под­сеть для стро­ки host replication replicator. Она долж­на соот­вет­ство­вать той, кото­рая исполь­зу­ет­ся в вашей инфраструктуре.
  • postgresql - pgpass — путь до фай­ла, кото­рый создаст патро­ни. В нем будет хра­нить­ся пароль для под­клю­че­ния к postgresql.
  • postgresql - connect_address — адрес и порт, кото­рые будут исполь­зо­вать­ся для под­клю­че­ния к СУДБ.
  • postgresql - data_dir — путь до фай­лов с дан­ны­ми базы.
  • postgresql - bin_dir — путь до бинар­ни­ков postgresql.
  • pg_rewind, replication, superuser — логи­ны и паро­ли, кото­рые будут созда­ны для базы.

Созда­дим юнит в systemd для patroni:

vi /lib/systemd/system/patroni.service

* обра­ти­те вни­ма­ние, что в офи­ци­аль­ной доку­мен­та­ции пред­ла­га­ет­ся не пере­за­пус­кать авто­ма­ти­че­ски служ­бу (Restart=no). Это дает воз­мож­ность разо­брать­ся в при­чине паде­ния базы.

Пере­чи­ты­ва­ем кон­фи­гу­ра­цию systemd:

systemctl daemon-reload

Раз­ре­ша­ем авто­за­пуск и стар­ту­ем сервис:

systemctl enable patroni --now

Про­ве­ря­ем ста­ту­сы сер­ви­са на обо­их серверах:

systemctl status patroni

Посмот­реть спи­сок нод

patronictl -c /etc/patroni/patroni.yml list pgdb

* где pgdb — имя нашей базы (ука­за­на с исполь­зо­ва­ни­ем дирек­ти­вы scope в кон­фи­гу­ра­ци­он­ном фай­ле patroni).

Мы долж­ны уви­деть что-то на подобие:

Мож­но про­ве­рить, что сер­вер кон­сул раз­ре­ша­ет име­на кластера:

nslookup -port=8600 master.pgdb.service.consul 127.0.0.1

nslookup -port=8600 replica.pgdb.service.consul 127.0.0.1

* где consul — настро­ен­ный в consul домен.

Коман­ды нам долж­ны вер­нуть адре­са соот­вет­ству­ю­щих сер­ве­ров — лиде­ра и реплики.

Наш кла­стер в рабо­чем состоянии.