Часто встречающиеся проблемы и пути их устранения#

Проблема:

Если включено расширение pg_pathman, pg_repack входит в бесконечный цикл при обработке его таблиц, что приводит к реорганизации не отдельной таблицы, а всей базы.

Решение:

Явно исключить pg_pathman из обработки с помощью ключа: -C pg_pathman.

Проблема:

При работе Pangolin Pooler в транзакционном режиме может наблюдаться ошибка:

ERROR: prepared statement "S_2" does not exist

Решение:

В качестве временного решения рекомендуется, до момента устранения данного ограничения, либо:

• отключить prepare statement;

• включить сессионный режим Pangolin Pooler;

• выставить prepareThreshold=0 в параметры jdbc (возможно увеличение latency). Пример строки подключения JDBC:

  JDBC:postgresql:127.0.0.1:6543/dbname?prepareThreshold=0
  

Дополнительно: рекомендуется завершать открытые соединения в случае если они не используются.

Проблема:

СУБД не переключилась в режим резервного копирования (РК).

pg_is_in_backup
-----------------
f

Процессы РК не запустились. На стороне СРК ошибки:

[Critical] From: test@test.ru "pvlad-sverk0001_PG_FULL"  Time: 7/24/2022 22:53:13
      04_manage_backup.sh on host <hostname>
      Script execution timed out => aborted by the Session Manager

[Critical] From: test@test.ru "pvlad-sverk0001_PG_FULL"  Time: 7/24/2022 22:53:13
      Session remote exec script "04_manage_backup.sh start"
      on host <hostname> failed.

[Critical] From: test@test.ru "pvlad-sverk0001_PG_FULL"  Time: 7/24/2022 22:53:13
      None of the Disk Agents completed successfully.
      Session has failed.

Из /var/log/messages:

Jul 24 22:23:13 pvlad-sverk0001 xinetd[1400]: START: omni pid=2697897 from=<IP-адрес>

Решение:

Возможно, БД находится в режиме неисключительной резервной копии до сих пор. Если это так, то:

• стоит вывести ее из режима pg_stop_backup(false). И настроить для контрольных точек параметр checkpoint_timeout, чтобы они выполнялись не реже 10-15 минут;

• или поправить скрипт, где разрешить pg_start_backup выполнять дополнительную контрольную точку:

  pg_start_backup ( '<текст>', TRUE, FALSE )
  

Проблема:

Администраторы АС грузят раз в сутки большой объем данных и у Postgres заканчивается оперативная память.

Решение:

Уменьшить work_mem — это позволит не выбиваться за пределы памяти.

Проблема:

Потеря соединений с БД. Из лога Pangolin Pooler:

2022-07-12 12:15:01.824 MSK [2310345] WARNING C-0x7f9b50ab0838 (328863): (nodb)/aposs_adm@<IP-адрес> authentication context expired. user: db=aposs user=aposs_adm
2022-07-12 12:15:01.824 MSK AUDIT aposs/aposs_adm@<IP-адрес> login attempt tls=no
2022-07-12 12:15:01.825 MSK AUDIT aposs/aposs_adm@<IP-адрес> send auth startup packet
2022-07-12 12:15:01.895 MSK AUDIT aposs/aposs_adm@<IP-адрес> auth server login ok
2022-07-12 12:15:41.512 MSK [2310345] LOG stats: 53 xacts/s, 97 queries/s, in 45910 B/s, out 19511 B/s, xact 1097 us, query 424 us, wait 0 us
2022-07-12 12:16:05.629 MSK AUDIT aposs/aposs_adm@<IP-адрес> closing because: client close request (age=545s)
2022-07-12 12:16:41.512 MSK [2310345] LOG stats: 53 xacts/s, 97 queries/s, in 45956 B/s, out 19530 B/s, xact 1126 us, query 427 us, wait 10 us
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@<IP-адрес> closing because: client unexpected eof (age=3298s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@<IP-адрес> closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@<IP-адрес> closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:07.182 MSK AUDIT aposs/aposs_adm@<IP-адрес> closing because: client unexpected eof (age=3623s)
2022-07-12 12:17:30.658 MSK AUDIT aposs/aposs_adm@<IP-адрес> connection received

Причины:

1. В логе очень много сообщений вида:

   AUDIT aposs/aposs_adm@<IP-адрес> closing because: client unexpected eof (age=1815s)
   

   Данное сообщение свидетельствует о том, что Pangolin Pooler обнаружил отсутствие клиента с противоположной стороны. Возможно, это обрывы сети, но вероятнее некорректное закрытие приложения (без закрытия пула соединений).

2. По причине 1 появляются сообщения вида:

   AUDIT aposs/aposs_adm@<IP-адрес> closing because: unclean server (age=1564s)
   

   Данные события происходят когда теряется связь между клиентом и Pangolin Pooler в момент передачи запроса, либо результатов запроса (Pangolin Pooler закрывает ставшую ненужной сессию в которой могли остаться незафиксированные изменения). Данное событие является прямым следствием причины 1.

3. В логе периодически встречаются сообщения вида:

   AUDIT aposs/aposs_adm@<IP-адрес> closing because: server_lifetime (age=3600s)
   

   Данное сообщение говорит о том, что Pangolin Pooler закрыл соединение по достижению параметра по умолчанию server_lifetime. Данное событие может приводить к причине 1 (например, приложение написано так, что падает при обрыве сессии).

Решение:

В первую очередь нужно понять почему происходит падение приложения (причина 1). Штатно ли закрываются пулы HikariCP или нет.

Дополнительно можно увеличить параметр server_lifetime Pangolin Pooler до 7200s и явно задать параметр maxLifetime в HikariCP (например 1800s). Параметр maxLifeTime в HikariCP определяет время жизни соединения, после которого его нужно пересоздать (касается только неактивных соединений, поэтому, если есть длинные транзакции, нужно определить максимальное время их выполнения и задать выше этого времени параметр server_lifetime Pangolin Pooler).

Проблема:

При работе с хранилищем паролей (утилита pg_auth_config), а именно при удалении записи (remove) или очистке хранилища паролей (reset) возникает ошибка:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

Решение:

Запустите выполнение команды с ключом -s (без подтверждения операции):

-- Удаление записи из хранилища паролей
pg_auth_config  remove -s -h <host> -p 5433 -U <username> -d <database>

Проблема:

Для транзакций не имеющих флаг READ ONLY при выполнении DML на мастер-узле возникают ошибки вида

ERROR:  cannot execute UPDATE in a read-only transaction

Причины:

Pangolin Pooler в транзакционном режиме по умолчанию не сбрасывает настройки сессии в сторону БД. Как результат может возникает ситуация, когда RW транзакция попадает в сессию с параметрами для RO транзакции.

Решение:

1. Настройте принудительный сброс параметров для сессий в Pangolin Pooler. Для этого добавьте/скорректируйте следующие параметры:

   $ grep server_reset_query /etc/pangolin-pooler/pangolin-pooler.ini
   server_reset_query_always = 1
   server_reset_query = DISCARD ALL
   

Внимание!

В этом случае будут сбрасываться все параметры сессии, в том числе search_path, set role и т.д.

1. Примените настройки:

   sudo systemctl reload pangolin-pooler
   

Проблема:

Pangolin Pooler блокирует УЗ при включенной сквозной аутентификации.

Решение:

• Компенсационные меры:

  Создайте bash скрипт c текстом sudo systemctl restart pangolin-pooler и с именем reload_pgbouncer.sh, поместите его в каталог /etc/pangolin-manager/. В файле конфигурации postgres.yml, в разделе postgresql: добавьте следующую строку:

  callbacks:
  on_restart: /etc/pangolin-manager/reload_pgbouncer.sh
  

  В результате после перезагрузки экземпляра СУБД, Pangolin Manager выполнит скрипт reload_pgbouncer.sh, который перезагрузит Pangolin Pooler и соответственно токен клиента обновится.

• Обходное решение:

  Отключите использование сквозной аутентификации.

Проблема:

Не работает аутентификация по сертификатам, если не настроен TLS.

Пример:

• Ошибка при подключении через SSL (сертификаты) к порту 6544 (Pangolin Pooler). При этом получается подключиться напрямую в Pangolin к порту 5433, пароль не проверяется и устанавливается зашифрованное соединение:

  [postgres@<hostname> /home/postgres]$ psql -p 5433 -U postgres
  
  psql (11.12)
  SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
  Type "help" for help.
  
  postgres=#
  

• Аутентификация по порту 6544 (через Pangolin Pooler) прошла неуспешно. Соединение не установлено:

  [postgres@<hostname> /home/postgres]$ psql -p 6544 -U postgres
  psql: ERROR: authentication failed for user "postgres": host rejected
  

• Лог Pangolin Pooler пишет следующее:

  2021-12-29 11:22:54.889 MSK AUDIT postgres/postgres@<IP-адрес> login attempt tls=no
  2021-12-29 11:22:54.889 MSK AUDIT postgres/(nouser)@<IP-адрес> new connection to auth server (from <IP-адрес>)
  2021-12-29 11:22:54.897 MSK AUDIT postgres/postgres@<IP-адрес> send auth startup packet
  2021-12-29 11:22:54.948 MSK AUDIT postgres/postgres@<IP-адрес> auth server login failed
  2021-12-29 11:22:54.948 MSK AUDIT postgres/postgres@<IP-адрес> closing because: authentication failed for user "postgres": host rejected (age=0s)
  2021-12-29 11:22:54.948 MSK [3254560] WARNING C-0xabe600 (2): postgres/postgres@<IP-адрес> pooler error: authentication failed for user "postgres": host rejected
  

Решение:

Решением является настройка TLS параметров соединения между Pangolin Pooler и Pangolin в файле конфигурации pangolin-pooler.ini. А именно необходимо раскомментировать все строчки под TLS SETTINGS, указать пути до актуальных сертификатов.

Проблема:

Файловая система /pgarclogs заполнена на 100%.

Решение:

1. Очистите каталог /pgarclogs/wal/clustername (в случае длительной недоступности каталога архивов часть wal-файлов гарантированно потеряется и восстановиться с их помощью уже не будет возможности);

2. Убедитесь, что новые архивы создаются, сессии резервного копирования wal-архивов периодически отрабатывают и чистят каталог;

3. Выполните полное копирование (Full Backup).

В случае, если закончится место в pgarchlogs, начнет заполняться каталог pg_xlog. По переполнению каталога pg_xlog, СУБД аварийно завершит свою работу.

Проблема:

Все соединения с БД завершаются по причине client_login_timeout:

2022-08-17 19:47:53.155 MSK [1347149] DEBUG C-0x1b0c040 (32): ufs/aplj@172.20.2.214:33131 client_proto: evtype = FLUSH, state = CL_LOGIN
2022-08-17 19:47:53.155 MSK [1347149] LOG C-0x1b076a0 (1): ufs/aplj@172.20.2.242:30229 closing because: client_login_timeout (age=177s)
2022-08-17 19:47:53.155 MSK [1347149] WARNING C-0x1b076a0 (1): ufs/aplj@172.20.2.242:30229 pooler error: client_login_timeout

Решение:

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

Проблема:

При разблокировке пользователя в однопользовательском режиме возникает ошибка:

ERROR: Can't find role with Oid <roloid> in password policy cache

Решение:

Выполните команду:

backend> update pg_pp_policy set lockout='f' WHERE roloid = to_regrole('postgres');

Для выхода из однопользовательского режима нажмите Crl-D.

Проблема:

Заблокированы все администраторы. В случае блокировки всех администраторов БД, в том числе пользователя postgres, восстановить УЗ функцией unblock_role не получится, так как все пользователи с правами на ее запуск не могут подключиться к БД.

В такой ситуации Pangolin Manager не сможет подключиться к экземпляру PostgreSQL и кластер потеряет лидера. Это можно увидеть в таблице вывода: столбец Role будет пустой.

$ list
+ Cluster: clustername (6857170778029161231) ----------------------------------------+--------------+---------+----+-----------+
|                 Member                |                    Host                    |     Role     |  State  | TL | Lag in MB |
+---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+
| <hostname>                            | <hostname>                                 |              | running |    |   unknown |
| <hostname>                            | <hostname>                                 |              | running |    |   unknown |
+---------------------------------------+--------------------------------------------+--------------+---------+----+-----------+

В логе Pangolin Manager появится запись об ошибке:

psycopg2.OperationalError: FATAL: Password policy. Auth check. User blocked: too many login fails
...
INFO: Error communicating with PostgreSQL. Will try again later

Решение:

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

1. Определить, на каком хосте был последний активный лидер.

2. Остановить службу Pangolin Manager на хосте последнего лидера.

3. Запустить PostgreSQL в single user режиме.

4. В single режиме разблокировать пользователя postgres.

5. Запустить службу Pangolin Manager.

6. Проверить работоспособность кластера.

7. Разблокировать остальных администраторов БД стандартным образом.

Подробнее порядок действий для разблокировки и восстановления работы кластера описан в документе «Руководство администратора», раздел «Сценарии администрирования», подраздел «Разблокировать и восстановить работу кластера».

Пересоздание хоста арбитра#

Полностью утерян хост арбитра. Необходимо восстановить только сбойный хост, а не весь кластер целиком. Для восстановления потребуется полностью новая виртуальная машина.

Процедура инициализации#

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

Примечание:

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

Узел мастера обозначается параметрами: {{ master_host }} и {{ master_ip }}.

Узел реплики обозначается параметрами: {{ replica_host }} и {{ replica_ip }}.

Узел арбитра обозначается параметрами: {{ arbiter_host }} и {{ arbiter_ip }}.

Узел арбитра в сокращенной форме, используемый в etcd-командах: {{ arbiter_etcd_host }}.

Примечание:

В качестве пользователя с правами sudo используется параметр: {{ USER }}.

Директория с сертификатами обозначается параметром: {{ pg_ssl }}. Например, pg_ssl или home/postgres/ssl. Имя директории с сертификатами следует выбрать так же, как на мастере.

Примечание:

В случае необходимости конфигурации дополнительных компонентов, таких как RSYSLOG или SRC, следует обращаться к соответствующим материалам.

Подготовительные действия#

Для выполнения процедуры предполагается наличие новой виртуальной машины, на которой будет производиться инсталляция. Параметры виртуальной машины должны соответствовать сохранившимся хостам кластера Pangolin. Процедура может быть использована для различных версий Pangolin: 4.x.x - 5.x.x. Однако, следует учитывать тот факт, что примеры команд и набор необходимых действий приводятся для версий Pangolin 5.1.0-5.2.0 и операционной системы Red Hat Enterprise Linux Server release 7.9. В других версиях могут отличаться имена файлов, директорий, набор компонентов, особенности конфигурации, влияющие на выбор того или иного формата команд, и др.

Настройка репозиториев yum#

Действие выполняется на арбитре.

Для настройки репозиториев yum перенесите содержимое с аналогичных файлов на узле мастера или скопируйте сами файлы на узел арбитра и дайте такие же права:

sudo su - {{ USER }}
sudo vi /etc/yum.repos.d/D10.repo
sudo vi /etc/yum.repos.d/mirror.repo
sudo vi /etc/yum.repos.d/redhat.repo

Установка пакетов#

Действие выполняется на арбитре.

Для дальнейшей работы требуется установить ряд необходимых пакетов. Заполните вспомогательный файл prereq.txt:

sudo su - {{ USER }}
vi /home/{{ USER }}/prereq.txt

Файл prereq.txt должен содержать следующий список пакетов:

openssl
rsync
sshpass
python3-pip
python36
python36-devel
python36-virtualenv
rsyslog
postgresql-libs

Выполните установку пакетов как в следующем примере:

sudo su - {{ USER }}
sudo yum install $(cat /home/{{ USER }}/prereq.txt)

Создание пользователя postgres#

Действие выполняется на арбитре.

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

sudo su - {{ USER }}
sudo useradd -m -G postgres postgres

Заполните /home/postgres/.bash_profile:

• перенесите содержимое с мастера;

• удалите все записи после строки PATH=$PATH:$HOME/.local/bin:$HOME/bin;

• добавьте следующие записи в конец полученного файла:

export PATH
export CLNAME=clustername
export CLNAME=KSG
sudo su - {{ USER }}

sudo vi /home/postgres/.bash_profile
sudo chown postgres:postgres /home/postgres/.bash_profile
sudo chmod 700 /home/postgres/.bash_profile

Генерация сертификатов#

Перенесите root-сертификат с узла мастера на арбитр и сгенерируйте серверный сертификат на арбитре для того, чтобы все сертификаты кластера были подписаны одним root-сертификатом.

Создание директории с сертификатами#

Действие выполняется на арбитре.

Создайте директорию с сертификатами на хосте арбитра:

sudo su - {{ USER }}
sudo rm -rf /{{ pg_ssl }}/
sudo mkdir -p /{{ pg_ssl }}/
sudo chown {{ USER }}:{{ USER }} /{{ pg_ssl }}/
sudo chmod 0755 /{{ pg_ssl }}/

Копирование root во временную директорию на мастере#

Действие выполняется на мастере.

Скопируйте root во временную директорию на мастере:

sudo su - {{ USER }}
mkdir /tmp/{{ pg_ssl }}
sudo cp /{{ pg_ssl }}/root.key        /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/root.crt        /tmp/{{ pg_ssl }}/

sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/root.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/root.crt

Перенос сертификатов на арбитр#

Действие выполняется на арбитре.

Перенесите сертификаты на арбитр:

sudo su - {{ USER }}
sudo scp -r {{ USER }}@{{ master_ip }}:/tmp/{{ pg_ssl }}/* /{{ pg_ssl }}/

sudo chown {{ USER }}:{{ USER }} /{{ pg_ssl }}/root.key
sudo chown postgres:postgres /{{ pg_ssl }}/root.crt

sudo chmod 644 /{{ pg_ssl }}/root.crt
sudo chmod 600 /{{ pg_ssl }}/root.key

Удаление временной директории на мастере#

Действие выполняется на мастере.

Удалите временную директорию на мастере:

sudo su - {{ USER }}
rm -rf /tmp/{{ pg_ssl }}

Генерация серверного сертификата#

Действие выполняется на арбитре.

Заполните конфигурационный файл server.cnf подставьте актуальное имя хоста и IP-адрес в разделе [alt_names]:

sudo su - {{ USER }}
vi /{{ pg_ssl }}/server.cnf

Содержимое файла server.cnf:

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[ssl_client]
extendedKeyUsage = clientAuth, serverAuth
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName = @alt_names
[v3_ca]
basicConstraints = CA:TRUE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
authorityKeyIdentifier=keyid:always,issuer
[alt_names]
DNS = {{ arbiter_host }}
IP = {{ arbiter_ip }}

Сгенерируйте серверный сертификат, подписывая его с помощью root:

sudo su - {{ USER }}

openssl req -new -nodes -text -out /{{ pg_ssl }}/server.csr -keyout /{{ pg_ssl }}/server.key -config /{{ pg_ssl }}/server.cnf -subj "/CN={{ arbiter_host }}"
openssl x509 -req -in /{{ pg_ssl }}/server.csr -text -days 365 -CA /{{ pg_ssl }}/root.crt -CAkey /{{ pg_ssl }}/root.key -CAcreateserial -extfile /{{ pg_ssl }}/server.cnf -extensions ssl_client -out /{{ pg_ssl }}/server.crt

sudo chown postgres:postgres /{{ pg_ssl }}/server.crt
sudo chown postgres:postgres /{{ pg_ssl }}/server.key
sudo chmod 644 /{{ pg_ssl }}/server.crt
sudo chmod 600 /{{ pg_ssl }}/server.key

sudo cp /{{ pg_ssl }}/root.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust

Настройка прав sudo#

Действие выполняется на арбитре.

Добавьте общие правила в /etc/sudoers (специфичные только для хоста арбитра):

sudo su - {{ USER }}
sudo visudo --file /etc/sudoers

Содержимое sudoers, необходимое для хоста арбитра

postgres  ALL=(ALL)       NOPASSWD: /usr/bin/systemctl daemon-reload, /usr/bin/systemctl stop etcd, /usr/bin/systemctl start etcd, /usr/bin/systemctl restart etcd, /usr/bin/systemctl status etcd, /usr/bin/systemctl status etcd -l, /usr/bin/systemctl status etcd --no-pager --full, /usr/bin/systemctl enable etcd, /usr/bin/systemctl disable etcd, /bin/journalctl -u etcd

Перевод Pangolin Manager в режим паузы#

Действие выполняется на мастере.

Переведите Pangolin Manager в режим паузы:

sudo su - postgres
pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml pause

Установка etcd#

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

Действие выполняется на арбитре.

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

sudo su - {{ USER }}
sudo systemctl stop etcd
sudo yum remove etcd -y
sudo rm -rf /var/lib/etcd
sudo rm -rf /etc/etcd
sudo rm /etc/systemd/system/etcd.service

Конфигурирование файла службы#

Действие выполняется на арбитре.

Заполните файл службы. Информацию перенесите из аналогичного файла на узле мастере.

sudo su - {{ USER }}
sudo vi /etc/systemd/system/etcd.service
sudo chown postgres:postgres /etc/systemd/system/etcd.service
sudo chmod 640 /etc/systemd/system/etcd.service

Установка etcd#

Действие выполняется на арбитре.

Выполните установку etcd. Версия etcd должна совпадать с версией, установленной на мастере.

sudo su - {{ USER }}
sudo yum install etcd-3.3.11

Конфигурирование etcd#

Действие выполняется на арбитре.

Заполните конфигурационный файл etcd. Содержимое файла перенесите с узла мастера и откорректируйте значения следующих параметров для работы на хосте арбитра:

• ETCD_NAME

• ETCD_ADVERTISE_CLIENT_URLS

• ETCD_INITIAL_ADVERTISE_PEER_URLS

sudo su - {{ USER }}
sudo mkdir -p /etc/etcd
sudo chown postgres:postgres /etc/etcd
sudo chmod 700 /etc/etcd
sudo vi /etc/etcd/etcd.conf
sudo chown postgres:postgres /etc/etcd/etcd.conf
sudo chmod 700 /etc/etcd/etcd.conf

Создание рабочей директории#

Действие выполняется на арбитре.

Создайте рабочую директорию etcd:

sudo mkdir -p /var/lib/etcd
sudo chown postgres:postgres /var/lib/etcd
sudo chmod 700 /var/lib/etcd

Настройка .bash_profile пользователя postgres#

Действие выполняется на арбитре.

Найдите в файле .bash_profile на хосте мастера 4 строки с префиксом: alias members, alias elist, alias elog, alias health и добавьте их в конец аналогичного файла на арбитре. Откорректируйте имена хостов и IP-адреса на значения, соответствующие хосту арбитра:

sudo su - {{ USER }}
sudo vi /home/postgres/.bash_profile

Процедура 1. Мягкий способ без замены всех узлов.#

Внимание:

Процедура 1 применяется в следующих случаях:

• в etcd не включена аутентификация (до версии Pangolin v.5.x.x);

• известен пароль etcd-пользователя root.

В противном случае переходим к Процедуре 2 (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста арбитра», подраздел «Процедура 2. Способ с полной заменой всех узлов»), где производится полная замена всех узлов.

В соответствии с Процедурой 1 потерянный узел кластера удаляется и взамен него добавляется новый. Остановка всего кластера etcd не выполняется. При этом все настройки кластера, включая аутентификационные (если они есть), перенесутся на новый узел etcd. Таким образом, Процедура 1 предлагает более «мягкий» вариант конфигурирования кластера etcd после потери одного из узлов.

Особенности использования Процедуры 1 на реплике:

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

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

Однако, если в postgres.yml на мастере этот пароль хранится в зашифрованном виде, а сам пароль неизвестен, то нельзя взять пароль из postgres.yml на мастере и записать его в аналогичный файл на реплике. Это связано с тем, что зашифрованные пароли привязаны к конкретному хосту (там, где производилось шифрование). Расшифровать пароль нельзя. Поэтому в этом случае дополнительно потребуется сгенерировать новый пароль и заново описать пользователей в etcd (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», подраздел «Процедура 2. Способ с полной заменой всех узлов», подраздел «Настройка аутентификации в etcd»).

Если же помнить пароли пользователей, их зашифрованные версии (каждого хоста) или иметь резервную копию файла postgresql.yml утерянного хоста реплики, то при работе с репликой достаточно выполнить только Процедуру 1. Дополнительные действия из подраздела «Настройка аутентификации в etcd» (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», подраздел «Процедура 2. Способ с полной заменой всех узлов») не требуются.

Дополнительная возможность

Существует еще одна альтернатива удалению и добавлению узла etcd-кластера. Это использование команды Pangolin Manager: pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml remove. В этом случае удаляется вся DCS-информация о кластере, включая все узлы. Аутентификационные настройки etcd (и пользователи) сохраняются. Однако в этом случае также встает вопрос необходимости генерации нового пароля patronietcd, если зашифрованный ранее на реплике вариант неизвестен.

Первоначальная оценка состояния кластера#

Действие выполняется на мастере.

Выполните оценку состояния кластера:

sudo su - postgres
etcdctl cluster-health

Анализ состояния кластера:

Когда все узлы кластера функционируют и аутентификация не включена - можно наблюдать следующий результат:

$ etcdctl cluster-health
member 320b6f2612a31501 is healthy: got healthy result from http://{{  replica_host }}:2379
member a7f7ea42134ef0f7 is healthy: got healthy result from http://{{ arbiter_host }}:2379
  member c1018517e2a55030 is healthy: got healthy result from http://{{ master_host }}:2379
cluster is healthy

Когда узел арбитра не функционирует и аутентификация включена - можно наблюдать следующий результат команды проверки состояния кластера (описание параметра {{ root_pass }} можно найти в подразделе «Настройка аутентификации в etcd» (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», подраздел «Процедура 2. Способ с полной заменой всех узлов»)):

$ ETCDCTL_API=3 etcdctl --endpoints={{ master_host }},{{ replica_host }}:2379,{{ arbiter_host }}:2379 --cert=/{{ pg_ssl }}/client.crt --key=/{{ pg_ssl }}/client.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' endpoint health
{{ master_host }}:2379 is healthy: successfully committed proposal: took = 1.22267ms
{{ replica_host }}:2379 is healthy: successfully committed proposal: took = 1.477113ms
{{ arbiter_host }}:2379 is unhealthy: failed to connect: rpc error: code = Unavailable desc = grpc: the connection is unavailable
Error: unhealthy cluster

Идентификаторы узлов в случае, когда аутентификация включена, можно получить при помощи следующей команды:

   $ ETCDCTL_API=3 etcdctl --endpoints={{ master_host }} --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key member list -w table
   +------------------+---------+--------------------+-----------------------------------+-----------------------------------+
   |        ID        | STATUS  |   NAME             |            PEER ADDRS             |           CLIENT ADDRS            |
   +------------------+---------+--------------------+-----------------------------------+-----------------------------------+
   | 320b6f2612a31501 | started | {{ master_host }}  | https://{{ master_host }}:2380    | https://{{ master_host }}:2379    |
   | a7f7ea42134ef0f7 | started | {{ replica_host }} | https://{{ replica_host }}:2380   | https://{{ replica_host }}:2379   |
   | c1018517e2a55030 | started | {{ arbiter_host }} | https://{{ arbiter_host }}:2380   | https://{{ arbiter_host }}:2379   |
   +------------------+---------+--------------------+-----------------------------------+-----------------------------------+

Ошибки, получаемые во время анализа:

Результат (ошибочный) ниже можно наблюдать, если в etcd включена аутентификация, но в команде не указан пользователь root и его пароль. По нему можно оценить, что наблюдаются неявные признаки того, включена или нет аутентификация в etcd. Если пароль неизвестен, см. Процедуру 2 (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста арбитра», подраздел «Процедура 2. Способ с полной заменой всех узлов»).

Данный результат приведен для примера - на практике могут быть получены и другие варианты:

$ etcdctl cluster-health
cluster may be unhealthy: failed to list members
Error:  client: etcd cluster is unavailable or misconfigured; error #0: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
; error #1: dial tcp 127.0.0.1:4001: connect: connection refused

error #0: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
error #1: dial tcp 127.0.0.1:4001: connect: connection refused

Удаление потерянного хоста арбитра#

Действие выполняется на мастере.

Удалите из кластера хост арбитра, как в следующем примере. Если он существовал ранее и был утерян - информация о нем будет отображаться в результате команды cluster-health или member list.

В данном примере узел a7f7ea42134ef0f7 относится к узлу арбитра ('{{ arbiter_host }}') и аутентификация не включена:

sudo su - postgres
$ etcdctl member remove a7f7ea42134ef0f7
Removed member a7f7ea42134ef0f7 from cluster

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

sudo su - postgres
$ ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379,{{ replica_host }}:2379,{{ arbiter_host }}:2379 --cert=/{{ pg_ssl }}/client.crt --key=/{{ pg_ssl }}/client.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' member remove a7f7ea42134ef0f7
Member a7f7ea42134ef0f7 removed from cluster 2fb3e311c3006ea9

Добавление нового хоста арбитра#

Действие выполняется на мастере.

Добавьте новый узел кластера etcd. В команде указывается хост арбитра и порт 2380.

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

sudo su - postgres
$ etcdctl member add {{ arbiter_etcd_host }} https://{{ arbiter_host }}:2380
Added member named {{ arbiter_etcd_host }} with ID 318b1c283299fb41 to cluster

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

sudo su - postgres
$ ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379,{{ replica_host }}:2379,{{ arbiter_host }}:2379 --cert=/{{ pg_ssl }}/client.crt --key=/{{ pg_ssl }}/client.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' member add {{ arbiter_etcd_host }} --peer-urls=https://{{ arbiter_host }}:2380
Member dd3624a80d791875 added to cluster 2fb3e311c3006ea9
...

Корректировка настроек etcd перед стартом#

Действие выполняется на арбитре.

В конфигурационном файле на узле арбитра установите параметр ETCD_INITIAL_CLUSTER_STATE в значение "existing":

Внимание:

Старт etcd на хосте арбитра без параметра ETCD_INITIAL_CLUSTER_STATE="existing" не будет успешным.

sudo su - {{ USER }}
sudo vi /etc/etcd/etcd.conf

Старт etcd на хосте арбитра#

Действие выполняется на арбитре.

Запустите службу etcd на узле арбитра:

sudo su - {{ USER }}
sudo systemctl daemon-reload
sudo systemctl start etcd
sudo systemctl status etcd
sudo etcdctl cluster-health

Корректировка настроек etcd после старта#

Действие выполняется на арбитре.

В конфигурационном файле на узле арбитра установите параметр ETCD_INITIAL_CLUSTER_STATE в значение "new". Затем произведите рестарт службы:

sudo su - {{ USER }}
sudo vi /etc/etcd/etcd.conf
sudo systemctl restart etcd

Процедура 2. Способ с полной заменой всех узлов#

Внимание:

Процедура 2 выполняется, если не были выполнены шаги Процедуры 1 (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», подраздел «Процедура 1. Мягкий способ без замены всех узлов»), то есть в случае, когда в etcd включена аутентификация и неизвестен etcd-пароль root.

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

Пересоздание рабочих директорий#

Действие выполняется на всех узлах.

Остановите службу etcd:

sudo su - {{ USER }}
sudo systemctl stop etcd

Пересоздайте рабочие директории etcd на каждом узле (они будут заполнены впоследствии автоматически во время первого старта):

sudo su - {{ USER }}
sudo rm -rf /var/lib/etcd
sudo mkdir -p /var/lib/etcd
sudo chown postgres:postgres /var/lib/etcd
sudo chmod 700 /var/lib/etcd

Старт etcd-кластера#

Действие выполняется на всех узлах.

Запустите службу etcd:

sudo su - {{ USER }}
sudo systemctl daemon-reload
sudo systemctl start etcd

Настройка аутентификации в etcd#

Действие выполняется на мастере.

Опишите пользователей в etcd и включите аутентификацию:

Внимание:

Команды ниже соответствуют версии Pangolin 5.2.1.

Примечание:

Пользователь root является техническим и используется только во время данного конфигурирования. Его возможно запомнить и использовать в дальнейшем, но по умолчанию он не используется после инсталляции.

Пароль можно сгенерировать с помощью команды: openssl rand -base64 24.

В примере в качестве пароля root использован параметр: {{ root_pass }}.

Примечание:

Пароль пользователя patronietcd можно сгенерировать с помощью команды: openssl rand -base64 24.

В примере в качестве пароля root использован параметр: {{ patronietcd_pass }}.

Затем пароль надо зашифровать (на хосте мастера и реплики), чтобы впоследствии поместить в postgres.yml. Команда, используемая для шифрования, запрашивает пароль и выдает его зашифрованный вид: pg_auth_password enc.

sudo su - postgres

ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  user add root:'{{ root_pass }}'
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  user add patronietcd:'{{ patronietcd_pass }}'
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' role add patroni
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  role grant-permission patroni readwrite --prefix=true /service/
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' user grant-role patronietcd patroni
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' auth enable

ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt user add root:'{{ root_pass }}'
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt user add patronietcd:'{{ patronietcd_pass }}'
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' role add patroni
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt role grant patroni -path '/service/*' -readwrite
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' user grant patronietcd -roles patroni
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' auth enable
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' role revoke guest -path '/*' --readwrite

ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key member list -w table
ETCDCTL_API=3 etcdctl --endpoints={{ replica_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' user list

Корректировка паролей в Pangolin Manager#

Действие выполняется на мастере и реплике.

Так как в пункте 2.8.3 поменялся пароль пользователя patronietcd, необходимо обновить его в конфигурационных файлах Pangolin Manager на мастере и реплике:

Внимание:

Пароль, зашифрованный на мастере, должен быть указан в postgres.yml на мастере.

Пароль, зашифрованный на реплике, должен быть указан в postgres.yml на реплике.

Заполните новые пароли в postgres.yml:

sudo su - {{ USER }}
sudo vi /etc/pangolin-manager/postgres.yml

Актуализация настроек Pangolin Manager посредством рестарта#

Действие выполняется на мастере и реплике.

Актуализируйте новые файлы postgres.yml, содержащие новые пароли patronietcd:

sudo su - core_dev
sudo systemctl restart pangolin-manager

Перевод Pangolin Manager в рабочий режим#

Действие выполняется на мастере.

Выведите Pangolin Manager из режима паузы:

sudo su - postgres
pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml resume

Пересоздание хоста реплики с использованием средств автоматической инсталляции#

Полностью утерян хост реплики. Необходимо восстановить только сбойный хост, а не весь кластер целиком. Для восстановления потребуется полностью новая виртуальная машина.

Процедура инициализации#

Примечание:

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

Примечание:

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

Узел мастера обозначается параметрами: {{ master_host }} и {{ master_ip }}. Например, srv1.db.dev, 10.4.0.1.

Узел реплики обозначается параметрами: {{ replica_host }} и {{ replica_ip }}. Например, srv2.db.dev, 10.4.0.2.

Узел арбитра обозначается параметрами: {{ arbiter_host }} и {{ arbiter_ip }}. Например, srv3.db.dev, 10.4.0.3.

Примечание:

В качестве пользователя с правами sudo используется параметр: {{ USER }}. Например core_dev.

Директория с сертификатами обозначается параметром: {{ pg_ssl }}. Например, pg_ssl или home/postgres/ssl. Имя директории с сертификатами следует выбрать так же, как на мастере.

Примечание:

В случае необходимости конфигурации дополнительных компонентов, таких как RSYSLOG или SRC, следует обращаться к соответствующим материалам.

Подготовительные действия#

Для выполнения процедуры предполагается наличие новой виртуальной машины, на которой будет производиться инсталляция. Параметры виртуальной машины должны соответствовать сохранившимся хостам кластера Pangolin. Процедура может быть использована для различных версий Pangolin: 4.x.x - 5.x.x. Однако, следует учитывать тот факт, что примеры команд и набор необходимых действий приводятся для версий Pangolin 5.1.0-5.2.0 и операционной системы Red Hat Enterprise Linux Server release 7.9. В других версиях могут отличаться имена файлов, директорий, набор компонентов, особенности конфигурации, влияющие на выбор того или иного формата команд, и др.

Перевод Pangolin Manager в режим паузы#

Действие выполняется на мастере.

Переведите Pangolin Manager в режим паузы:

sudo su - postgres
pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml pause

Установка Pangolin#

Действие выполняется на реплике.

Произведите установку Pangolin с помощью автоматических средств (например, Ansible или Jenkins). При установке выберите конфигурацию standalone, соответствующую целевому кластеру и содержащую такой же перечень компонентов Pangolin. Например, вместо cluster-patroni-etcd-pgbouncer следует выбрать standalone-patroni-etcd-pgbouncer. В процессе дальнейшей инициализации данный standalone-узел, установленный автоматически, будет включен в кластер.

Останов служб#

Действие выполняется на реплике.

Остановите службы на реплике:

sudo su - {{ USER }}
sudo systemctl stop pangolin-pooler
sudo systemctl stop pangolin-manager
sudo systemctl stop etcd

Генерация сертификатов#

В данном разделе выполняется генерация серверного сертификата и перенос клиентских сертификатов с мастера для того, чтобы все сертификаты кластера были подписаны одним root-сертификатом.

Очистка директории с сертификатами#

Действие выполняется на реплике.

Удалите все сертификаты на реплике:

sudo su - {{ USER }}
sudo rm -rf /{{ pg_ssl }}/*

Копирование сертификатов во временную директорию на мастере#

Действие выполняется на мастере.

Скопируйте root и клиентские сертификаты во временную директорию на мастере:

sudo su - {{ USER }}
mkdir /tmp/{{ pg_ssl }}
sudo cp /{{ pg_ssl }}/root.key        /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/root.crt        /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/client.crt      /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/client.key      /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/etcd.crt        /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/etcd.key        /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/patroni.crt     /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/patroni.key     /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/patronietcd.crt /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/patronietcd.key /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/pgbouncer.crt   /tmp/{{ pg_ssl }}/
sudo cp /{{ pg_ssl }}/pgbouncer.key   /tmp/{{ pg_ssl }}/

sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/root.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/root.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/client.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/client.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/etcd.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/etcd.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/patroni.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/patroni.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/patronietcd.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/patronietcd.key
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/pgbouncer.crt
sudo chown {{ USER }}:{{ USER }} /tmp/{{ pg_ssl }}/pgbouncer.key

Перенос сертификатов на реплику#

Действие выполняется на реплике.

Перенесите сертификаты с мастера на реплику:

sudo su - {{ USER }}
sudo scp -r {{ USER }}@{{ master_ip }}:/tmp/{{ pg_ssl }}/* /{{ pg_ssl }}/

sudo chown {{ USER }}:{{ USER }} /{{ pg_ssl }}/root.key
sudo chown postgres:postgres /{{ pg_ssl }}/root.crt
sudo chown postgres:postgres /{{ pg_ssl }}/client.crt
sudo chown postgres:postgres /{{ pg_ssl }}/client.key
sudo chown {{ USER }}:{{ USER }} /{{ pg_ssl }}/etcd.crt
sudo chown {{ USER }}:{{ USER }} /{{ pg_ssl }}/etcd.key
sudo chown postgres:postgres /{{ pg_ssl }}/patroni.crt
sudo chown postgres:postgres /{{ pg_ssl }}/patroni.key
sudo chown postgres:postgres /{{ pg_ssl }}/patronietcd.crt
sudo chown postgres:postgres /{{ pg_ssl }}/patronietcd.key
sudo chown postgres:postgres /{{ pg_ssl }}/pgbouncer.crt
sudo chown postgres:postgres /{{ pg_ssl }}/pgbouncer.key

sudo chmod 644 /{{ pg_ssl }}/root.crt
sudo chmod 600 /{{ pg_ssl }}/root.key
sudo chmod 644 /{{ pg_ssl }}/client.crt
sudo chmod 600 /{{ pg_ssl }}/client.key
sudo chmod 644 /{{ pg_ssl }}/etcd.crt
sudo chmod 600 /{{ pg_ssl }}/etcd.key
sudo chmod 644 /{{ pg_ssl }}/patroni.crt
sudo chmod 600 /{{ pg_ssl }}/patroni.key
sudo chmod 644 /{{ pg_ssl }}/patronietcd.crt
sudo chmod 600 /{{ pg_ssl }}/patronietcd.key
sudo chmod 644 /{{ pg_ssl }}/pgbouncer.crt
sudo chmod 600 /{{ pg_ssl }}/pgbouncer.key

Удаление временной директории на мастере#

Действие выполняется на мастере.

Удалите временную директорию на мастере:

sudo su - {{ USER }}
rm -rf /tmp/{{ pg_ssl }}

Генерация серверного сертификата#

Действие выполняется на реплике.

Заполните конфигурационный файл server.cnf, подставьте актуальное имя хоста и IP-адрес в разделе [alt_names]:

sudo su - {{ USER }}
vi /{{ pg_ssl }}/server.cnf

Содержимое файла server.cnf:

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[ssl_client]
extendedKeyUsage = clientAuth, serverAuth
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName = @alt_names
[v3_ca]
basicConstraints = CA:TRUE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
authorityKeyIdentifier=keyid:always,issuer
[alt_names]
DNS = {{ replica_host }}
IP = {{ replica_ip }}

Сгенерируйте серверный сертификат, подписывая его с помощью root:

sudo su - {{ USER }}

openssl req -new -nodes -text -out /{{ pg_ssl }}/server.csr -keyout /{{ pg_ssl }}/server.key -config /{{ pg_ssl }}/server.cnf -subj "/CN={{ replica_host }}"
openssl x509 -req -in /{{ pg_ssl }}/server.csr -text -days 365 -CA /{{ pg_ssl }}/root.crt -CAkey /{{ pg_ssl }}/root.key -CAcreateserial -extfile /{{ pg_ssl }}/server.cnf -extensions ssl_client -out /{{ pg_ssl }}/server.crt

sudo chown postgres:postgres /{{ pg_ssl }}/server.crt
sudo chown postgres:postgres /{{ pg_ssl }}/server.key
sudo chmod 644 /{{ pg_ssl }}/server.crt
sudo chmod 600 /{{ pg_ssl }}/server.key

sudo cp /{{ pg_ssl }}/root.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust

Конфигурирование etcd#

Корректировка конфигурационного файла#

Действие выполняется на реплике.

Скорректируйте конфигурационный файл etcd. Значение ETCD_INITIAL_CLUSTER следует взять с мастера.

sudo su - {{ USER }}
sudo vi /etc/etcd/etcd.conf

Пересоздание рабочих директорий#

Действие выполняется на всех хостах.

Примечание: Если в etcd не включена аутентификация или известен пароль root (внутренний пользователь etcd), можно удалить сбойный узел (member) из кластера etcd и добавить взамен него новый, не выключая весь кластер. В противном случае приходится пересоздавать узлы etcd полностью. Ниже приводится процедура полного пересоздания узлов etcd.

Процедура включения в кластер отдельного узла описана в документе «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», подразделе «Процедура 1. Мягкий способ без замены всех узлов».

Остановите службу etcd:

sudo su - {{ USER }}
sudo systemctl stop etcd

Пересоздайте рабочие директории etcd на каждом узле (они будут впоследствии заполнены автоматически во время первого старта):

sudo su - {{ USER }}
sudo rm -rf /var/lib/etcd
sudo mkdir -p /var/lib/etcd
sudo chown postgres:postgres /var/lib/etcd
sudo chmod 700               /var/lib/etcd

Старт etcd-кластера#

Действие выполняется на всех хостах.

Запустите службу etcd:

sudo su - {{ USER }}
sudo systemctl daemon-reload
sudo systemctl start etcd

Настройка аутентификации в etcd#

Действие выполняется на мастере.

Опишите пользователей в etcd и включите аутентификацию:

Примечание:

Пользователь root является техническим и используется только во время данного конфигурирования. Его возможно запомнить и использовать в дальнейшем, но по умолчанию он не используется после инсталляции.

Пароль можно сгенерировать с помощью команды: openssl rand -base64 24.

В примере в качестве пароля root использован параметр: {{ root_pass }}.

Примечание:

Пароль пользователя patronietcd можно сгенерировать с помощью команды: openssl rand -base64 24.

В примере в качестве пароля root использован параметр: {{ patronietcd_pass }}.

Затем пароль надо зашифровать (на хосте мастера и реплики), чтобы впоследствии поместить в postgres.yml. Команда, используемая для шифрования, запрашивает пароль и выдает его зашифрованный вид: pg_auth_password enc.

Примечание:

В командах ниже можно использовать либо серверный, либо клиентский сертификат postgres.

sudo su - postgres

ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  user add root:'{{ root_pass }}'
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  user add patronietcd:'{{ patronietcd_pass }}'
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' role add patroni
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  role grant-permission patroni readwrite --prefix=true /service/
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' user grant-role patronietcd patroni
ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' auth enable

ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt user add root:'{{ root_pass }}'
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt user add patronietcd:'{{ patronietcd_pass }}'
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' role add patroni
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt role grant patroni -path '/service/*' -readwrite
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' user grant patronietcd -roles patroni
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' auth enable
ETCDCTL_API=2 etcdctl --endpoints https://{{ master_host }}:2379 --cert-file=/{{ pg_ssl }}/server.crt --key-file=/{{ pg_ssl }}/server.key --ca-file=/{{ pg_ssl }}/root.crt -u root:'{{ root_pass }}' role revoke guest -path '/*' --readwrite

ETCDCTL_API=3 etcdctl --endpoints={{ master_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key member list -w table
ETCDCTL_API=3 etcdctl --endpoints={{ replica_host }}:2379 --cert=/{{ pg_ssl }}/server.crt --key=/{{ pg_ssl }}/server.key --cacert=/{{ pg_ssl }}/root.crt  --user=root:'{{ root_pass }}' user list

Конфигурирование Pangolin Managers#

Настройка конфигурационных файлов#

Действие выполняется на мастере и реплике.

Отредактируйте конфигурационные файлы Pangolin Manager на мастере и реплике, выполнив действия ниже:

sudo su - {{ USER }}
sudo vi /etc/pangolin-manager/postgres.yml

Выполните следующие действия:

• обновите пароль patronietcd, если он поменялся в пункте 2.4

• обновите пароль patroniyml - для этого сгенерируйте и зашифруйте его так же, как и для patronietcd

• убедитесь в корректности значения пароля для ldapbindpasswd и если есть необходимость сгенерируйте, зашифруйте и внесите его в postgres.yml в секцию pg_hba

• и др (по-необходимости)

Внимание:

Пароль, зашифрованный на мастере, должен быть указан в postgres.yml на мастере.

Пароль, зашифрованный на реплике, должен быть указан в postgres.yml на реплике.

Дополнительно на реплике выполните следующие действия:

• измените название параметра etcd.host на etcd.hosts, значение возьмите с мастера;

• добавьте параметры bootstrap.synchronous_mode и bootstart.synchronous_mode_strict так же, как на мастере;

• добавьте параметр postgresql.callbacks.on_role_change так же, как на мастере;

• измените значение параметра postgresql.parameters.installer.cluster_type, чтобы оно было таким же, как на мастере;

• приведите блок параметров pg_hba в соответствие с аналогичными параметрами на мастере (по умолчанию можно просто перенести все значения блока с мастера на реплику);

• при необходимости можно также произвести другие изменения.

Конфигурирование PostgreSQL#

Настройка директорий PostgreSQL#

Действие выполняется на реплике.

Пересоздайте директории PostgreSQL. Имена директорий следует скорректировать, если текущие названия на мастере отличаются от используемых в примере имен.

sudo su - {{ USER }}
sudo rm -rf /pgerrorlogs/05/
sudo rm -rf /pgdata/05/data/
sudo rm -rf /pgarclogs/05/
sudo rm -rf /pgdata/05/tablespaces/

sudo mkdir -p                /pgerrorlogs/05
sudo chown postgres:postgres /pgerrorlogs/05
sudo chmod 0700              /pgerrorlogs/05

sudo mkdir -p                /pgdata/05/data
sudo chown postgres:postgres /pgdata/05/data
sudo chmod 0700              /pgdata/05/data

sudo mkdir -p                /pgarclogs/05
sudo chown postgres:postgres /pgarclogs/05
sudo chmod 0700              /pgarclogs/05

sudo mkdir -p                /pgdata/05/tablespaces
sudo chown postgres:postgres /pgdata/05/tablespaces
sudo chmod 0700              /pgdata/05/tablespaces

sudo mkdir -p                /etc/postgres
sudo chown postgres:postgres /etc/postgres
sudo chmod 0700              /etc/postgres

Настройка прав sudo#

Действие выполняется на реплике.

Скорректируйте содержимое /etc/sudoers - скопируйте содержимое с мастера или заполните в соответствии с конфигурацией:

sudo su - {{ USER }}
sudo visudo --file /etc/sudoers

Внимание:

Файл /etc/sudoers - очень чувствительный элемент. В случае наличия в нем синтаксической ошибки можно потерять права sudo.

Чтобы проверить корректную работу sudo, можно выполнить переключение на другого пользователя, например: sudo su - postgres.

Одним из вариантов актуализации /etc/sudoers является перенос файла с мастера целиком. Пример выполнения:

• копирование файла во временную директорию на мастере (выполняется на стороне мастера):

sudo su - {{ USER }}
sudo cp /etc/sudoers /tmp/
sudo chown {{ USER }}:{{ USER }} /tmp/sudoers

• копирование файла из временной директории мастера в целевую директорию на реплике (выполняется на стороне реплики):

sudo su - {{ USER }}
sudo scp {{ USER }}@{{ master_ip }}:/tmp/sudoers /tmp/
sudo chown root:root /tmp/sudoers
sudo cp /tmp/sudoers /etc/sudoers
sudo rm /tmp/sudoers

• удаление временного файла на мастере (выполняется на стороне мастера):

sudo rm /tmp/sudoers

Настройка хранилища паролей для пользователя Pangolin Manager#

В данном разделе производится настройка хранилища паролей для пользователя patroni.

Если текущий пароль patroni неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на мастере и реплике. Если текущий пароль patroni известен - достаточно выполнить только пункт 4.3.2 на реплике.

Пароль, указывающийся с помощью параметра {{ patroni_pass }}, можно сгенерировать так же, как и для patronietcd (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста реплики с использованием средств автоматической инсталляции», подраздел «Настройка аутентификации в etcd»).

Начиная с версии 4.4.0 хранилище паролей (файл /etc/postgres/enc_utils_auth_settings.cfg) создается автоматически при установке Pangolin.

Пользователь patroni используется, как служебный пользователь кластера Pangolin, использующийся, в частности, для репликации (детали можно найти в /etc/pangolin-manager/postgres.yml).

Изменение пароля#

Действие выполняется на мастере.

Измените пароль в СУБД на мастере:

## ALTER USER "patroni" WITH ENCRYPTED PASSWORD '{{ patroni_pass }}';

Запись пароля в хранилище паролей#

Действие выполняется на мастере и реплике.

Выполните запись пароля в хранилище паролей (пароль запрашивается при выдаче команды pg_auth_config add):

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h localhost -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U patroni -d replication
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U patroni -d replication
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U patroni -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U patroni -d replication

pg_auth_config  add -s -h localhost -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U patroni -d replication
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U patroni -d replication
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U patroni -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U patroni -d replication

pg_auth_config show

Настройка хранилища паролей для пользователя backup_user#

В данном разделе производится настройка хранилища паролей для пользователя backup_user.

Если текущий пароль backup_user неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на мастере и реплике. Если текущий пароль backup_user известен - достаточно выполнить только пункт 4.4.2 на реплике.

Пароль, указывающийся с помощью параметра {{ backup_user_pass }}, можно сгенерировать так же, как и для patronietcd (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста реплики с использованием средств автоматической инсталляции», подраздел «Настройка аутентификации в etcd»).

Изменение пароля#

Действие выполняется на мастере.

Измените пароль в СУБД на мастере:

## ALTER USER "backup_user" WITH PASSWORD '{{ backup_user_pass }}';

Запись пароля в хранилище паролей#

Действие выполняется на мастере и реплике.

Выполните запись пароля в хранилище паролей:

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ master_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h {{ replica_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U backup_user -d postgres
pg_auth_config  remove -s -h 127.0.0.1 -p 5433 -U backup_user -d postgres

pg_auth_config  add -s -h {{ master_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ master_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h {{ replica_ip }} -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U backup_user -d postgres
pg_auth_config  add -s -h 127.0.0.1 -p 5433 -U backup_user -d postgres

pg_auth_config show

Настройка хранилища паролей для пользователя profile_tuz#

В данном разделе производится настройка хранилища паролей для пользователя profile_tuz.

Если текущий пароль profile_tuz неизвестен, то задается новый пароль, а затем он записывается в хранилища паролей на мастере и реплике. Если текущий пароль profile_tuz известен - достаточно выполнить запись пароля в хранилище паролей на реплике.

Пароль, указывающийся с помощью параметра {{ profile_tuz_pass }}, можно сгенерировать так же, как и для patronietcd (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста реплики с использованием средств автоматической инсталляции», подраздел «Настройка аутентификации в etcd»).

Изменение пароля#

Действие выполняется на мастере.

Измените пароль в СУБД на мастере:

## ALTER USER "profile_tuz" WITH PASSWORD '{{ profile_tuz_pass }}';

Запись пароля в хранилище паролей#

Действие выполняется на мастере и реплике.

Выполните запись пароля в хранилище паролей:

sudo su - postgres
pg_auth_config show

pg_auth_config  remove -s -h localhost -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h localhost -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h {{ master_host }} -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  remove -s -h {{ replica_host }} -p 5433 -U profile_tuz -d "First_db"

pg_auth_config  add -s -h localhost -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h localhost -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h {{ master_host }} -p 5433 -U profile_tuz -d "First_db"
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U profile_tuz -d postgres
pg_auth_config  add -s -h {{ replica_host }} -p 5433 -U profile_tuz -d "First_db"

pg_auth_config show

Установка пароля для пользователя kmadmin_pg#

Действие выполняется на мастере и реплике.

Если на мастере существует пользователь kmadmin_pg, то следует установить пароль на реплике соответственно:

sudo su - {{ USER }}
sudo passwd kmadmin_pg

Внимание:

Шаги подраздела «Конфигурирование PostgreSQL» выше (см. документ «Руководство администратора», «Часто встречающиеся проблемы и пути их устранения», раздел «Пересоздание хоста реплики с использованием средств автоматической инсталляции») приведены для стандартной конфигурации Pangolin 5.1.0. Если на практике конфигурация действующего кластера отличается (есть дополнительная функциональность, пользователи, и тп), то недостающие действия должны также быть также выполнены на реплике для полного соответствия мастеру.

Запуск реплики#

Актуализация нового конфигурационного файла на мастере#

Действие выполняется на мастере.

Актуализируйте новый файл postgres.yml и выведите Pangolin Manager из режима паузы:

sudo su - {{ USER }}
sudo systemctl restart pangolin-manager

sudo su - postgres
pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml resume

Старт Pangolin Manager на реплике и восстановление базы данных#

Действие выполняется на реплике.

Запустите Pangolin Manager, который восстановит реплику в соответствии с bootstrap-логикой файла postgres.yml. В результате получится работающий кластер.

sudo su - {{ USER }}
sudo systemctl start pangolin-manager

Конфигурирование Pangolin Pooler#

Примечание:

Данный блок является опциональным и необходим в случае наличия компонента Pangolin Pooler.

Корректировка конфигурационных файлов#

Действие выполняется на реплике.

Скорректируйте конфигурационные файлы Pangolin Pooler, сравнивая их с аналогичными файлами на мастере:

sudo su - {{ USER }}
sudo vi /etc/pangolin-pooler/pangolin-pooler.ini
sudo vi /etc/pangolin-pooler/userlist.txt
sudo vi /etc/logrotate.d/pangolin-pooler

Запуск Pangolin Pooler#

Действие выполняется на мастере и реплике.

Перезапустите службу Pangolin Pooler:

sudo su - {{ USER }}
systemctl restart pangolin-pooler

Пересоздание хоста реплики из дистрибутива#

Полностью утерян хост реплики. Необходимо восстановить только сбойный хост, а не весь кластер целиком. Для восстановления потребуется полностью новая виртуальная машина.

Процедура инициализации#

Примечание:

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

Примечание:

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

Узел мастера обозначается параметрами: {{ master_host }} и {{ master_ip }}. Например, srv1.db.dev, 10.4.0.1.

Узел реплики обозначается параметрами: {{ replica_host }} и {{ replica_ip }}. Например, srv2.db.dev, 10.4.0.2.

Узел арбитра обозначается параметрами: {{ arbiter_host }} и {{ arbiter_ip }}. Например, srv3.db.dev, 10.4.0.3.

Примечание:

В качестве пользователя с правами sudo используется параметр: {{ USER }}. Например core_dev.

Директория с сертификатами обозначается параметром: {{ pg_ssl }}. Например, pg_ssl или home/postgres/ssl. Имя директории с сертификатами следует выбрать так же, как на мастере.

В качестве пользователя nexus (репозиторий дистрибутивов) используется параметр: {{ nexus_login }}.

Примечание:

В случае необходимости конфигурации дополнительных компонентов, таких как RSYSLOG или SRC, следует обращаться к соответствующим материалам.

Подготовительные действия#

Для выполнения процедуры предполагается наличие новой виртуальной машины, на которой будет производиться инсталляция. Параметры виртуальной машины должны соответствовать сохранившимся хостам кластера Pangolin. Процедура может быть использована для различных версий Pangolin: 4.x.x - 5.x.x. Однако следует учитывать тот факт, что примеры команд и набор необходимых действий приводятся для версий Pangolin 5.1.0-5.2.0 и операционной системы Red Hat Enterprise Linux Server release 7.9. В других версиях могут отличаться имена файлов, директорий, набор компонентов, особенности конфигурации, влияющие на выбор того или иного формата команд, и др.

Скачивание дистрибутива#

Действие выполняется на реплике.

Скачайте дистрибутив. В качестве примера рассмотрим дистрибутив Pangolin 5.1.0. Версия дистрибутива должна совпадать с установленной на мастере версией.

sudo su - {{ USER }}
mkdir -p /tmp/pangolin_510
cd /tmp/pangolin_510
curl -O -u {{ nexus_login }} <URL>/Pangolin-D-05.001.00-40-distrib.tar.gz
tar -xvf /tmp/pangolin_510/Pangolin-D-05.001.00-40-distrib.tar.gz

Настройка репозиториев yum#

Действие выполняется на реплике.

Настройте репозитории yum. Для этого перенесите содержимое с аналогичных файлов на узле мастера или скопируйте сами файлы на узел арбитра и дайте такие же права.

sudo su - {{ USER }}
sudo vi /etc/yum.repos.d/D10.repo
sudo vi /etc/yum.repos.d/mirror.repo
sudo vi /etc/yum.repos.d/redhat.repo

Установка пакетов#

Действие выполняется на реплике.

Для дальнейшей работы требуется установить ряд необходимых пакетов.

Заполните вспомогательный файл prereq.txt:

sudo su - {{ USER }}
vi /home/{{ USER }}/prereq.txt

Файл prereq.txt должен содержать следующую информацию:

openssl
rsync
sshpass
python3-pip
python36
python36-devel
python36-virtualenv
rsyslog
postgresql-libs

Выполните установку пакетов как в следующем примере:

sudo su - {{ USER }}
sudo yum install $(cat /home/{{ USER }}/prereq.txt)

Создание пользователя postgres#

Действие выполняется на реплике.

Создайте пользователя postgres, если он отсутствует на узле реплики:

sudo su - {{ USER }}
sudo useradd -m -G postgres postgres

Заполните /home/postgres/.bash_profile - перенесите содержимое с мастера и скорректируйте имена хостов и IP-адреса для работы на хосте реплики:

sudo su - {{ USER }}

sudo vi /home/postgres/.bash_profile
sudo chown postgres:postgres /home/postgres/.bash_profile
sudo chmod 700               /home/postgres/.bash_profile

Создание установочной директории PostgreSQL#

Действие выполняется на реплике.

Создайте установочную директорию PostgreSQL. Имя директории следует выбрать таким же, как на мастере:

Примечание:

В нашем примере (Pangolin 5.1.0) используется имя директории: pgsql-se-05. В других версиях имя может быть иным.