Содержание

Tantor: Базовая архитектура стенда

Tantor: Базовая архитектура стенда

(Этап 1) Проверка, подготовка.

Для инсталляции СУБД Tantor необходимо удостовериться, что версия операционной системы соответствует документации по развертыванию продукта.

Для практики нам понадобится 6 виртуальных сервера c предустановленной ОС ALSE 1.8 и сетевой связанностью.
Например имена хостов:
tplatform.example – сервер для палатформы Tantor (4 cpu / 8гб ram / 40гб HDD)
db1 db2 db3 – сервера для СУБД по (2 cpu / 2гб ram / 20гб HDD)
haproxy1 haproxy2 – для балансировщика по (2 cpu / 2гб ram / 20гб HDD)

Для платформы Tantor обязательно домен второго уровня, так как при установке дистрибутива в запросах инсталятора будет просить DNS имя, которое после установки будет использоваться адрестной строке браузера для доступа к графическому интерфейса

Если планируете проходить практику на своем стенде, то для создания ВМ платформы Tantor обязательно используем host-passthrough в настройках ВМ гипервизора (прямой доступ к аппаратным ресурсам процессора) с доступам к инструкциям sse и avx.

Иначе не заработает модуль Advanced analytics

Как проверить что все хорошо - на вывод команд в CLI на хосте tplatform

Обе инструкции должны выводить ответ:

lscpu | grep -i sse
lscpu | grep -i avx

После создания ВМ подключаемся к серверам по ssh.

Пример в нашем практикуме через bastion хост:
ssh -i /<путь где лежит ключ>/<XX.key> tantor@<Внешний IP>

ssh -i /home/test/.shh/00.key -p 2222 tantor@62.62.62.62

Далее с bastion подключаемся на хосты tplatform, db1, db2, db3, haproxy1, haproxy2

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

ssh tplatform
ssh db1
ssh db2
ssh db1
ssh haproxy1
ssh haproxy2

Прибивка статики ip на хостах (!! На стендах практикума делать не нужно).

На этапе подготовки важно, чтобы IP на хостах не менялись, так как Платформа Tantor будет подключать агентов по IP На стендах практикума это уже сделано, но приводим пример как это настроить через CLI linux.

Убедиться, что используется interfaces или NetworkManager. NetworkManager – более современный менеджер сетей. Обычно он идет в комплекте с графическими окружениями Linux.

NetworkManager включен, он может игнорировать interfaces.

nmcli device status

Смотрим вывод в колонке STATE, если без управления, переходим в настройку interfaces Если да, в таком случае настройки лучше делать через nmcli # (утилита терминале)

Установить статический IP на eth0

sudo nmcli con add type ethernet con-name "my-eth" ifname eth0 ipv4.method manual ipv4.addresses 10.2.0.11/24 ipv4.gateway 10.2.0.1 ipv4.dns "10.2.0.254" ipv4.dns-search "example.dn"

Активировать подключение

sudo nmcli con up "my-eth"

или

nmtui # (текстовый интерфейс) в песевдографике терминала.

Настройка interfaces.

Редактируем фал настроек сетевого интерфейса пример:

sudo nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address 10.2.0.11
  network 10.2.0.0
  netmask 255.255.255.0   ## или 24
  gateway 10.2.0.1
  mtu 1420

  dns-nameservers 10.2.0.254
  dns-search example.dn   ## суфикс как пример

source /etc/network/interfaces.d/*.cfg

Проверить синтаксис файла (опционально) без отключения loopback

sudo ifdown -a --exclude=lo && sudo ifup -a

Перезагрузка сервиса networking для применения конфигурации

sudo systemctl restart networking

Проверяем версии ОС Astra Linux и уровня защищенности на всех узлах.

cat /etc/astra_license
cat /etc/astra/build_version

Режимы защищенности Astra Linux (0 - Орел, 1 - Воронеж, 2 - Смоленск) Проверить уровень защищенности ОС согласно требования заказчика:

sudo astra-modeswitch get
sudo astra-modeswitch getname

если необходимо сменить уровень защищенности, при условии, что у заказчика имеется лицензия на Astra Linux server (1 - Воронеж или 2 - Смоленск).

sudo astra-modeswitch set 0  ## или 1 или 2
sudo reboot                  ## перезагрузить ОС

Просмотр подключенных репозиториев для получения или обновления пакетов и ОС.

grep -r ^deb /etc/apt/sources.list /etc/apt/sources.list.d

Для каждой версии ОС используются свои публичные интернет репозитории, читайте тех док к ОС.
https://docs.astralinux.ru/1.7/guide/compound/repo
https://docs.astralinux.ru/1.8/guide/compound/repo
стандартные путь сслылок на публичные репозитории для ОС описаны тут:

sudo nano /etc/apt/sources.list

 или

sudo apt edit-sources

Как правило указаны frozen ветки /uu/* оперативного обновления для того, чтобы не произошло непреднамеренного обновление на самую последнюю версию ОС по ветке, которая может привести к не стабильной работе ПО Tantor.
для получения более свежего релиза пакетов достаточно сменить uu/1 на uu/2, сохранить.
В закрытом сегменте заказчика используются свои репозитории или ISO образы с личного кабинета Астра.

deb https://download.astralinux.ru/astra/frozen/1.8_x86-64/1.8.1/uu/2/extended-repository/ 1.8_x86-64 main non-free non-free-firmware contrib
deb https://download.astralinux.ru/astra/frozen/1.8_x86-64/1.8.1/uu/2/main-repository/ 1.8_x86-64 main non-free non-free-firmware contrib

Затем выполнить обновление списка пакетов

sudo apt update

Если необходимо обновить всю ОС в зависимости от ситуации и требования заказчика.

sudo apt dist-upgrade

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

locale -a                  ## смотрим какие уже скопмилированы
sudo nano /etc/locale.gen   ## убрать комментарий   en_US.UTF-8 и ru_RU.utf8
sudo locale-gen

Проверим файл hosts и имена для каждого из хостов.

Вывод имени хоста

hostname -f

Изменить имя хоста, если необходимо на каждом сервере свое

sudo hostnamectl set-hostname <новое_имя_хоста>

Внести список хостов на каждом сервере и сохранить, если нет DNS сервера в сети. Но в целом это хорошая практика, если даже DNS сервер есть, его аварии не исключены.

sudo nano /etc/hosts

Пример:

10.2.0.2 tplatform.example tplatform

10.2.0.11 db1

10.2.0.12 db2

10.2.0.13 db3

10.2.0.21 haproxy1

10.2.0.22 haproxy2

Проверим

cat /etc/hosts

Установка утилит и пакетов.

На все хосты устанавливаем

sudo apt install htop iperf wget chrony nmap bash-completion -y

Зависимости нужны для Tantor СУБД на хостах db1 db2 db3

sudo apt install libllvm13 libpython3.11 libxsldb1.1 libz3-4 lsof apt-transport-https gnupg -y

При установке пакета СУБД Tantor их сам запросит и установит через сетевой репозиторий.

На хосте tplatform устанавливаем графику и браузер, а также Docker не менее 20.10.13 версии

sudo apt install docker.io docker-compose firefox xrdp fly-all-main -y

Проверить Docker версию на хосте tplatform

docker -v && docker-compose -v

Полный вывод

docker version
docker-compose version

Cлужба синхронизации времени, Выполняем на всех хостах.

Ставим автозагрузку службы

sudo systemctl enable chrony

Проверка статуса

sudo systemctl status chrony
sudo chronyc tracking         ## проверка текущего состояния
sudo chronyc sources -v       ## список NTP-серверов
sudo chronyc makestep         ## немедленная корректировка времени

В Chrony список серверов задаётся в конфигурационном файле /etc/chrony/chrony.conf После редактирования перезапустит службу sudo systemctl restart chrony

timedatectl                   ## вывести текущий часовой пояс и время
timedatectl list-timezones    ## вывести варианты ЧП
sudo timedatectl set-timezone <название_часового_пояса>

Проверка сетевой доступности портов

На узле СУБД утилита iperf запускается в режиме сервера (ключ -s), по умолчанию используется протокол TCP, выбран порт 5432 (ключ -p)

Пример проверки порта запускаем iperf в режиме сервера на хостах СУБД db1 db2 db3

iperf -s -p 5432

На tplatform запускается в режиме клиента (указывается узлы СУБД по очереди)

iperf -p 5432 -c db1
iperf -p 5432 -c db2
iperf -p 5432 -c db3

или через утилиту nmap:

-sT - проверка по протоколу TCP
-p - номер, проверяемого порта
<IP адрес> - адрес проверяемого узла

Пример, проверяем доступность порта db1, команду выполняем например с узла tplatform

sudo nmap -sT -p 5432 db1
sudo nmap -sT -p 5432 db2
sudo nmap -sT -p 5432 db3

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

ss -ntlup

(Этап 2) Подготовка

Скачиваем пакет СУБД Tantor и скрипт инсталятор на db1 db2 db3. https://docs.tantorlabs.ru/tdb/ru/16_6/be/binary-download-execute.html

Скачиваем скрипт установки через публичный репозиторий Tantor Будем работать под root, но можно также и через sudo

sudo -i
mkdir distr
cd distr
wget https://public.tantorlabs.ru/db_installer.sh
chmod +x db_installer.sh

Если закрытый сегмент, скачиваем пакеты Платформы Tantor СУБД нужной версии и скрипт инсталяции предварительно на к себе носитель из: https://lk.astralinux.ru

be-версия Tantor СУБД для тестового использования можно скачать https://nexus-public.tantorlabs.ru

Устанавливаем пакет СУБД Tantor на db1 db2 db3. https://docs.tantorlabs.ru/tdb/ru/16_6/be/binary-download-execute.html

Установка через доступ интернета be-версия

Определим репозиторий

export NEXUS_URL="nexus-public.tantorlabs.ru"

Установка из интернета через скрипт установки СУБД Tantor
Описание ключей можно посмотреть внутри скрипта
–do-initdb инициализация инстанса СУБД разу после установки
–major-version=16 указываем мажорную версию СУБД
–edition=be сборка be-версия

./db_installer.sh \
  --do-initdb \
  --major-version=16 \
  --edition=be

Пример установки в фоновом режиме с выводом в лог файл Конструкция в Linux системах «nohup * > install_tantor_be_serever.log 2>&1 &» Работает для любого выполнения команд или скриптов, рекомендую изучить дополнительно через поиск в интернете работу с Linux CLI

nohup ./db_installer.sh \
  --do-initdb \
  --major-version=16 \
  --edition=be > install_tantor_be_serever.log 2>&1 &

Чтение изменения лога в реальном времени

tail -1000f install_tantor_be_serever.log

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

Пример копирования файлов на стенд из практикума Скачиваем файллы из личного кабинета астры https://lk.astralinux.ru к себе например в каталог /tmp
Перейдите в каталог, куда скачали установочный пакет СУБД.

cd /tmp

Копируем сначала на bastion в /tmp

scp -i /home/test/.shh/00.key -P 2222 tantor-be-server-16_16.8.0_amd64.deb tantor@62.62.62.62:/tmp
scp -i /home/test/.shh/00.key -P 2222 db_installer.sh tantor@62.62.62.62:/tmp

Далее подключившись по ssh на bastion и с него копируем на db1 db2 db3

ssh -i /home/test/.shh/00.key -p 2222 tantor@62.62.62.62
cd /tmp
scp tantor-be-server-16_16.8.0_amd64.deb tantor@db1:/tmp
scp db_installer.sh tantor@db1:/tmp
scp tantor-be-server-16_16.8.0_amd64.deb tantor@db2:/tmp
scp db_installer.sh tantor@db2:/tmp
scp tantor-be-server-16_16.8.0_amd64.deb tantor@db3:/tmp
scp db_installer.sh tantor@db2:/tmp

Подключаемся через bastion к хостам db1, db2, db3

ssh db1
sudo -i
cd /tmp
chmod +x db_installer.sh

Установка пакета через скрипт с инициализацией БД

./db_installer.sh \
--from-file=/tmp/tantor-be-server-16_16.8.0_amd64.deb \
--do-initdb

После установки пакета СУБД, назначаем права пользователя postgres на структуру каталогов на хостах db1, db2, db3.

sudo chown -R postgres:postgres /var/lib/postgresql

Сменим пароль на УЗ postgres в операционной системе на хостах db1, db2, db3

запомните или запишите, далее пригодится при настройке модуля платформы Tantor

sudo passwd postgres

Посмотрим информацию о БД

sudo -iu postgres pg_controldata /var/lib/postgresql/tantor-be-16/data

посмотреть процесс работы инстанса

sudo -iu postgres cat /var/lib/postgresql/tantor-be-16/data/postmaster.pid
sudo -iu postgres psql -c "SELECT pid, backend_type, backend_start FROM pg_stat_activity;"

Допускается установка нескольких экземпляра разной версии СУБД на один узел. При этом название экземпляров, используемые порты и расположение каталогов с данными должны быть разными.

Проверка службы и автозагрузка сервиса СУБД Tantor.

Ключи утилиты systemctl:
status - показать запущен (loaded) сервис и его состояние (active) работает

sudo systemctl enable tantor-be-server-16.service
sudo systemctl status tantor-be-server-16.service

Посмотреть запущенные процессы

ps -efH | grep tantor

Проверка запуска сервиса СУБД Tantor по журналам Проверка осуществляется запуском утилиты journalctl с ключем -u , казывающим наименование сервиса, в нашем случае tantor-be-server-16.service.

sudo journalctl -u tantor-be-server-16.service

Настройка сетевых соединений к серверу СУБД производится в файлах параметров postgresql.conf и pg_hba.conf в соответствии с требованием заказчика.
По умолчанию сетевые настройки в файле pg_hba.conf позволяют подключиться только суперпользователю postgres СУБД Tantor непосредственно с сервера через local unix socket.
Для разрешения подключения с других узлов необходимо внести соответствующие строки в файлы pg_hba.conf и postgresql.conf.
В конце листинга есть FAQ доп информация:

(Этап 3) Установка Платформы Tantor.

Скачиваем и Распаковываем архив с Платформой Tantor. https://docs.tantorlabs.ru/tp/5.3/wizard.html

Способ при наличии доступа в интернет

Загрузим инсталлятор на хост tplatform согласно документации. Всегда смотрите новую версию по ссылке выше.

sudo -i
mkdir distr
cd distr
wget https://public.tantorlabs.ru/tantor-eco-5.3.0.tar.gz -O tantor-eco-5.3.0.tar.gz

Распакуем из архива

tar -xvf tantor-eco-5.3.0.tar.gz

Способ, если закрытый сектор, и вам дали доступ временно в сети заказчика.

Скачиваем файллы из личного кабинета астры https://lk.astralinux.ru к себе например в каталог /tmp

cd /tmp
wget https://public.tantorlabs.ru/tantor-eco-5.3.0.tar.gz -O tantor-eco-5.3.0.tar.gz

Пример копирования файлов на стенд tplatform из практикума Копируем сначала на bastion в /tmp

scp -i /home/test/.shh/00.key -P 2222 tantor-eco-5.3.0.tar.gz tantor@62.62.62.62:/tmp

Далее подключившись по ssh на bastion и с него копируем на tplatform

ssh -i /home/test/.shh/00.key -p 2222 tantor@62.62.62.62
cd /tmp
scp tantor-eco-5.3.0.tar.gz tantor@tplatform:/tmp

Далее с bastion хоста подключаемся на хост tplatform

ssh tplatform
sudo -i
cd /tmp

Распакуем из архива

tar -xvf tantor-eco-5.3.0.tar.gz

Инсталяция Платформы Tantor.

https://docs.tantorlabs.ru/tp/5.3/wizard.html

Для установки Платформы на Astra Linux версии 1.8.2 необходимо переключить уровень безопасности для docker на astra-sec-level-6

sudo mkdir -p /etc/docker/
sudo nano /etc/docker/daemon.json

Вставляем и сохраняем

{
        "debug" : true,
        "astra-sec-level" : 6
}

Перезапускаем службу docker

sudo systemctl restart docker

Запуск установки из каталога, куда разархивировали данные:

sudo ./installer

В ходе интерактивной установки будут запрошены данные:

Параметр	Значение	Описание
Tantor Platform administrator email:	admin@astralinux.ru	Почтовый адрес администратора Платформы Tantor
Tantor Platform administrator name:	<admin>	Имя администратора Платформы Tantor
Tantor Platform domain name:	<tplatform.example>	Доменное имя Платформы Tantor
SSL certificates match domain name:	N	Cертификаты SSL для имени домена Платформы, если имеется у заказчика
Сreate the self-signed certificates:	Y	Если в предыдущем пункет N
set integration with SMTP server:	N	Настройки сервера почты в рамках практикума пропускаем

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

Параметр	Описание
SMTP server domain name:	доменное имя сервера электронной почты, если имеется, для практики не требуется
SMTP server domain name port	порт сервера электронной почты
SMTP server user email	имя постового ящика на который будут отправляться оповещения от Платформы Tantor
SMTP server user password	пароль почтового ящика

Если не указали настройки почты, и после установки хотите до настроить, смотрите раздел «FAQ доп информация» в конце листинга.

Параметр	Описание
Which platform setup deployment you want to install? (1/2/3): 3	выбор конфигурации Платформы Tantor

ВАЖНО!!! После установки, скопировать password для смены пароль администратора .

Tantor Platform version 5.3.0 is installed and running.
Please connect to Tantor Platform using:
Tantor Platform URL: https://tplatform.example
Tantor Platform administrator email/login: admin@astralinux.ru
Tantor Platform administrator password: dCU18MzQbBWVcR7P

Подключение к Платформе, активация и настройка агента на узле сервера СУБД.

подключаемся по RDP на хост tplatform и выполняем выше указанные действия в браузере. Доступ по RDP на tplatform <внешний IP>:7389
login: tplatform
pass: !@34%^78()test

Первое подключение к Платформе с помощью браузера, смена пароля,
Согласиться с политикой лицензирования и нажать Ок
Установить новый пароль суперпользователя Платформы
Зайти в тенант
Создать новое рабочее пространство New workspace (имя произвольно)

Проверки успешности установки и запуска сервисов Платформы. Состояние контейнеров Платформы можно посмотреть командами.

Убедиться, что контейнеры Платформы запущены и работают (STATUS Up)

docker ps

Если необходимо перезагрузить платформу

cd /opt/tantor/eco/
docker-compose stop
docker-compose start
docker-compose ps

Порты на узле Платформы

ss -ntlup

Запуск утилиты диагностики для Платформы sdc-tantor, идет в комплекте архива. В случае неудачного завершения установки или обновления платформы.

https://docs.tantorlabs.ru/tp/5.3/admin_diagnostic_utility.html

cd distr

chmod 755 ./sdc-tantor

./sdc-tantor

Архив создан и сохранён в: sdc-report_tplatform_20250620_163622.tar.gz

Будет выполнен сбор системной конфигурации и диагностической информации в основном о работе докер контейнеров и информации о хосте.
Приложите этот файл в созданную в техническую поддержку заявку.

(этап 4) установка агента Tantor и последующем добавлении инстанса СУБД в платформу

Для установки агента Tantor и последующем добавлении инстанса СУБД в платформу необходимо перейти на сервер СУБД и произвести предложенные Платформой действия. https://docs.tantorlabs.ru/tp/5.3/instance_adding.html

!! Установку агента всегда начинаем на лидере в кластере !!

Элемент ненумерованного спискаОткрыть рабочее пространство в Платформе
Элемент ненумерованного спискаДобавить новый инстанс (сервер СУБД) Add instance
Элемент ненумерованного спискаВыбрать тип инстанса (в наше примере Tantor)
Элемент ненумерованного спискаУказать IP адрес, порт и имя БД
Элемент ненумерованного спискаПлатформа сообщает, что агент не установлен на выбранном инстансе и предлагает выбрать тип и версию ОС инстанса
Элемент ненумерованного спискаДалее необходимо выполнить ряд предлагаемых Платформой действий на узле сервера СУБД, для исключения ошибки скопировать, каждое действие в буфер можно кликнув на пиктограмму в конце каждой строки.

Узнаем IP адрес нашего сервера СУБД

ip a

пример вывода:

inet 10.2.0.11/24 brd 10.2.0.255 scope global eth0

Установка PMA агента Платформы Tantor при условии если везде вход по паролю и через графический интерфейс команда не проходит, то установку делаем через доп ключи читайте оф документацию https://docs.tantorlabs.ru/tp/5.3/ug_agents_config.html пример:

pmaagent configure --config_postgres_patroni -h 10.2.0.11 -p 5432 -d postgres -U postgres -W postgres -P 8008 -D

дополнительно смотрите тех документацию по ссылке выше, а также help агента после его установки

pmaagent --help
pmaagent instances add --help

Проверка службы старта агента.

sudo systemctl daemon-reload
sudo systemctl start pmaagent.service
sudo systemctl status pmaagent.service

Если нет связи с агентом, перезапустить демон агента

systemctl stop pmaagent.service
systemctl start pmaagent.service

Конфиг агента
/var/lib/pma/agent/agent.yml
Лог агента
/var/lib/pma/agent/logs/pmaagent.log

Установка дополнительных элементов для взаимодействия Птатформы и СУБД. (расширений / EXTENSION в СУБД Tantor)(pg_stat_statements, pg_store_plans, Advanced analytics)

https://docs.tantorlabs.ru/tp/5.3/pg_monitor_installation.html

Для работы Advanced analytics, создание ключей RSA под root на сервере tplatform

sudo -i
ssh-keygen -t rsa

Скопируйте в нужные директории созданные ключи следующей командой:

cp /root/.ssh/id_rsa* /opt/tantor/eco/ssh/

Скопируйте созданный публичный ключ на сервер базы данных, выполнив следующую команду:

ssh-copy-id -i /opt/tantor/eco/ssh/id_rsa postgres@db1
ssh-copy-id -i /opt/tantor/eco/ssh/id_rsa postgres@db2
ssh-copy-id -i /opt/tantor/eco/ssh/id_rsa postgres@db3

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

ssh postgres@db1
ssh postgres@db2
ssh postgres@db3

Настройка параметров и расширений / EXTENSION на наблюдаемой СУБД: pg_stat_statements, pg_store_plans, Advanced analytics.

Текущий вариант через «alter system set», создаст отдельный файл /var/lib/postgresql/tantor-be-16/data/postgresql.auto.conf , который будет преобладать в приоритете при запуске СУБД над файлом postgresql.conf, что очень удобно, если мы хотим отделить изменяемые параметры от дефолтных.
Данный способ работает только в рамках текущего сервера СУБД в standalone.

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

Подключаемся к одному из серверов, где установлена СУБД Tantor, например db1 В дальнейшем эти операции нужно выполнить на каждой наблюдаемой БД.

sudo -iu postgres psql

Выполняем команды на создание расширений и параметров: Если в параметре shared_preload_libraries уже указаны другие расширения, то добавить pg_stat_statements, pg_store_plans через запятую.

create EXTENSION pg_stat_statements;
create EXTENSION pg_store_plans;
alter system set shared_preload_libraries = pg_stat_statements, pg_store_plans, auto_explain;
alter system set logging_collector = on;
alter system set log_line_prefix = '%m [%p:%v] [%d] %r %a ';
alter system set log_lock_waits = on;
alter system set lc_messages = 'en_US.UTF-8';
alter system set track_io_timing = on;
alter system set deadlock_timeout = 1000;
alter system set log_min_duration_statement = 1000;
alter system set log_filename = 'postgresql-%F.log';
alter system set log_destination = 'stderr';
alter system set log_statement = 'all';

Перезагрузка СУБД и проверка сервиса СУБД, должно быть active (running)

sudo systemctl restart tantor-be-server-16.service
sudo systemctl status tantor-be-server-16.service

Добавляем параметры auto_explain

sudo -iu postgres psql

alter system set pg_store_plans.min_duration = 1000;
alter system set auto_explain.log_min_duration = 1000;
alter system set auto_explain.log_nested_statements = 'true';
alter system set auto_explain.log_analyze = on;
alter system set auto_explain.log_buffers = on;
SELECT pg_reload_conf();

Сколько параметров установлено в файлах параметров конфигурации

select sourcefile, count(*) from pg_settings group by sourcefile;

Какие параметры из каких файлов конфигурации были считаны и применены при запуске экземпляра Так же через этот вывод можно проверить себя, правильно ли вы задали параметры до перезагрузки СУБД.

select name, setting, substring(sourcefile, 39) file, sourceline, applied from pg_file_settings;

Для корректной работы модуля Advanced Analytics требуется добавить следующее разрешение в файле pg_hba.conf:

nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf

host     postgres         postgres         127.0.0.1/32             trust

Чтобы новые параметры pg_hba.conf применились, выполните:

sudo -iu postgres psql -c "SELECT pg_reload_conf();"

или restart наблюдаемой СУБД.

sudo systemctl restart tantor-be-server-16.service

Чтобы изменения вступили в силу для Advanced analytics, на сервере tplatform перезапустите контейнер

docker restart pg_monitor_collector

Посмотрите результат в Платформе, обновив страницу Overview с открытым инстансом БД в браузере. Должны появится графики
В модуле Advanced analytics инстансом БД также должны появиться данные

Ротация и очистка логов СУБД Tantor ''/var/lib/postgresql/tantor-be-16/data/log.''

Эти параметры уже заданы, при необходимости измените под требования заказчика. Для просмотра или изменения можно использовать Платформу Tantor или командами в psql:
alter system set <параметр = значение>; – изменить
show <параметр>; – посмотреть

logging_collector = on              # Включение сбора логов
log_directory = 'log'               # Директория для логов (относительно PGDATA)
log_filename = 'postgresql-%F.log'  # Шаблон имени файла
log_rotation_age = 1d               # Ротация ежедневно
log_rotation_size = 10MB            # Или при достижении размера

Посмотреть логи по примеру, имя файла у вас будет свой:

less /var/lib/postgresql/tantor-be-16/data/log/postgresql-2023-10-01_135334.log

Даем привилегии УЗ postgres на использование crontab

sudo usermod -aG crontab postgres

Логинимся под УЗ postgres

su - postgres

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

nano cleanup_logs.sh

#!/bin/bash
find /var/lib/postgresql/tantor-be-16/data/log/ -type f -name "*.log" -mtime +14 -exec rm {} \;
find /var/lib/postgresql/tantor-be-16/data/log/ -type f -name "*.csv" -mtime +14 -exec rm {} \;

Применяем бит исполнения файла скрипта

chmod +x cleanup_logs.sh

Вставляем задание на выполнение в cron, сохраняем и проверяем.

crontab -e

0 0 * * * /var/lib/postgresql/cleanup_logs.sh  ## выполнение раз в день в 0:00

проверяем, что запись добавилась

crontab -l

(этап 5) Настройка репликации встроенными инструментами СУБД (ручной Failover/Switchover).

Выполняется на Master db1 10.2.0.11 :

Создадим отдельного пользователя для репликации repl - имя пользователя

sudo -iu postgres psql
CREATE ROLE repl WITH REPLICATION LOGIN ENCRYPTED PASSWORD '12345678';
\password  # сменим пароль на УЗ postgres внутри СУБД Tantor (пример пароль postgres)

Правим строчку в pg_hba, тут со стороны заказчика нужно указать, что куда добавить Правило подключения, если необходимо. Не всегда это нужно в рамках тестового пилота, Можно оставить так.

!!! чтобы не мучиться с корректировкой настроек после pg_rewind, для repl можно указать всю подсеть 10.2.0.0/24

sudo nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf

host    replication     repl         10.2.0.12/32            scram-sha-256
host    all             all          0.0.0.0/0               scram-sha-256

Добавляем параметры, ip адрес Master сервера в настройку инстанса

nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf

или через psql, параметры запишутся в postgresql.auto.conf

sudo -iu postgres psql

alter system set listen_addresses = 'localhost, 10.2.0.11'; -- можно '*', чтобы не перенастраивать после pg_rewind
alter system set wal_level = replica;
alter system set wal_log_hints = on;
alter system set max_wal_senders = 10;
alter system set fsync = on;
alter system set synchronous_commit = on;
alter system set hot_standby = on;
alter system set hot_standby_feedback = on;
alter system set synchronous_standby_names = '1 (db1, db2)'; -- для async репликации оставьте пустое значение
alter system set max_replication_slots = 10;
alter system set wal_keep_size = '1GB';  -- или больше, в зависимости от требований

После внесение изменений перезапускаем сервис

sudo systemctl restart tantor-be-server-16.service

Выполняем на Replica сервере db2 10.2.0.12 :

systemctl stop tantor-be-server-16.service
su - postgres
cd /var/lib/postgresql/tantor-be-16/

Сохраним архивную копию папки data если потребуется для восстановления или удаляем

tar -cvzf main_backup-`date +%s`.tgz data
rm -rf data/

Переносим папку data c Master сервера на Реплику с созданием слота репликации -C -S db2_replica:

export PGAPPNAME=db2
pg_basebackup -h db1 -U repl -p 5432 -D data -R -X stream -C -S db2_replica -c fast -P

PASSWORD '12345678'

Проверяем, появилась ли data каталог

ls -la data/

Исправим на правильный listen_addresses Если указывали listen_addresses = '*', то не нужно

nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf

или

nano /var/lib/postgresql/tantor-be-16/data/postgresql.auto.conf

listen_addresses = 'localhost, 10.2.0.12'

Корректируем правило в pg_hba.conf, для того чтобы после смены лидера, db1 смог подключаться к db2. Если указывали 10.2.0.0/24, то не нужно.

nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf

host    replication     repl         10.2.0.11/32            scram-sha-256

Запустим сервис

sudo systemctl start tantor-be-server-16.service
sudo systemctl status tantor-be-server-16.service

На мастере db1 10.2.0.11 проверить реплику

sudo -iu postgres psql -c "select client_addr, usename, application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn from pg_stat_replication;"

На реплике db2 10.2.0.12 , вывод должен быть true

sudo -iu postgres psql -c "select status,sender_host,sender_port, slot_name from pg_stat_wal_receiver;
SELECT pg_is_in_recovery();"

Проверим репликацию, создадим сущность данных в СУБД на мастере db1 10.2.0.11

sudo -iu postgres psql -c "create database tesdb2;"

Проверим на реплике db2 10.2.0.12

sudo -iu postgres psql -c "\l"

Смена лидера. (меняем роли местами мастер -> реплику).

Проверить статус репликации на db2 10.2.0.12 Должно вернуть true (реплика в режиме восстановления)

sudo -iu postgres psql
SELECT pg_is_in_recovery();

Проверить отставание на db2 10.2.0.12

SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();

смотрим статус синхронизации на мастере db1 10.2.0.11

sudo -iu postgres psql
\x
SELECT * FROM pg_stat_replication;

Перед переключением мастера на реплику, рекомендуется остановить режим записи СУБД на мастере db1, чтобы избежать потери данных.

Это можно сделать с помощью команды:

ALTER SYSTEM SET default_transaction_read_only = ON;
SELECT pg_reload_conf();

На реплике выполните db2 10.2.0.12 Относительно видео - скорректировано создание слота репликации db1_replica

SELECT pg_promote();
SELECT pg_is_in_recovery();   ## Должно быть `false` (теперь это мастер)
SELECT * FROM pg_create_physical_replication_slot('db1_replica'); ## создать слот репликации для новой реплики
SELECT slot_name, slot_type FROM pg_replication_slots;  ## проверим что новый слот создался

Остановить сервис tantor на мастере db1 10.2.0.11

sudo systemctl stop tantor-be-server-16.service

выполняем догон db1 10.2.0.11 , новой реплики относительно нового мастера.
Делаем pg_rewind под УЗ postgres, так как пользователь должен иметь права с доступом к функции pg_read_binary_file.
либо при создании УЗ repl дать привилегии, если планируете использовать ее для pg_rewind.
GRANT EXECUTE ON FUNCTION pg_read_binary_file(text, bigint, bigint, boolean) TO repl;
В PostgreSQL доступ к функции pg_read_binary_file ограничен по соображениям безопасности, так как она позволяет читать произвольные файлы на сервере. Обычно только суперпользователи (superuser) имеют к ней доступ.

su - postgres
pg_rewind --target-pgdata=/var/lib/postgresql/tantor-be-16/data --source-server="host=db2 port=5432 user=postgres dbname=postgres password=postgres" -P

Создайте файл standby.signal db1 10.2.0.11

touch /var/lib/postgresql/tantor-be-16/data/standby.signal
rm -f /var/lib/postgresql/tantor-be-16/data/postmaster.pid  ## на всякий случай

Настроить старый мастер db1 10.2.0.11 как новую реплику. Отредактируем строчки в файле
primary_slot_name = 'db1_replica'
host=db2 , application_name=db1

nano /var/lib/postgresql/tantor-be-16/data/postgresql.auto.conf

primary_conninfo = 'user=repl password=12345678 channel_binding=prefer host=db2 port=5432 application_name=db1 sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0 target_session_attrs=any load_balance_hosts=disable'
primary_slot_name = 'db1_replica'

Корректируем правило в pg_hba.conf, для того чтобы после смены лидера, db2 смог подключаться к db1. Если указывали 10.2.0.0/24, то не нужно.

nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf

host    replication     repl         10.2.0.12/32            scram-sha-256

Запустить сервис tantor на db1 10.2.0.11

sudo systemctl start tantor-be-server-16.service

Проверим на новом мастере db2 10.2.0.12:

sudo -iu postgres psql -c "select client_addr, usename, application_name, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn from pg_stat_replication;"

На новой реплике db1 10.2.0.11:

sudo -iu postgres psql -c "select status,sender_host,sender_port, slot_name from pg_stat_wal_receiver;
SELECT pg_is_in_recovery();"

Если мы хотим полностью разделить БД и сделать самостоятельными: synchronous_commit = off делать ненужно, это отключает синхронную фиксацию записи данных транзакции на диск, нарушит надежность сохранности данных.

SELECT pg_promote();
alter system set synchronous_standby_names = '';
SELECT pg_reload_conf();
SELECT  pg_is_in_recovery();                      ## убедитесь, что сервер действительно стал основным, должно быть false
select pg_drop_replication_slot('db1_replica');   ## на db2

(этап 6) Вариант сценария проведения нагрузочного тестирования.

Нагрузочное тестирование предназначено для проверки того, как cистема будет работать под большим количеством пользователей, одновременно, в течение ограниченного периода времени, чтобы смоделировать реальную ситуацию.
Количество моделируемых пользователей аналогично ожидаемому объему нагрузки пользователей в реальной жизни.
Проверяется время отклика Системы, обнаруживаются узкие места и различные ошибки, например такие, как проблемы с кодом и утечки памяти.
Тестирование позволяет определить какое количество пользователей может обработать Система, прежде чем производительность пострадает.

TPC-B , TPC-C (OLTP-систем (онлайн-транзакционная обработка))
* эталонный тест, используется для стресс-тестирования пиковой пропускной способности базы данных, имитирует рабочую нагрузку, состоящую из нескольких пользовательских сеансов, подключенных по сети, со значительной активностью дискового ввода-вывода, за исключением любых сетевых и интерактивных операций, чтобы обеспечить наилучшее измерение пропускной способности;

TPC-H (OLAP-систем (онлайн-аналитическая обработка))
* эталонный тест, эмулирующий работу приложений бизнес-аналитики, состоит из набора бизнес-ориентированных специальных запросов и одновременных модификаций данных, анализирует большие объемы данных, выполняют запросы высокой степени сложности.

pgbench – программа для запуска эталонных тестов на PostgreSQL, выполняет последовательность команд SQL, вычисляет среднюю скорость транзакций (транзакций в секунду), использует сценарий, основанный на TPC-B, включающий пять команд SELECT, UPDATE и INSERTна транзакцию, также ПО позволяет протестировать собственный сценарий транзакций;

go-tpc – набор инструментов тестирования рабочих нагрузок на основе тестов TPC для СУБД PostgreSQL, выполняющий тест TPC-H.

https://github.com/pingcap/go-tpc

sysbench – это универсальный инструмент для стресс-тестирования

HammerDB – поддерживающее TPC-C, TPC-H и другие сценарии. для само изучения более профессиональный инструмент

https://www.hammerdb.com/download.html https://www.hammerdb.com/document.html

Пример использования pgbench.

su - postgres ## логинимся под УЗ postgres

pgbench –help ## посмотреть доп параметры утилиты

Создаем пустую БД для тестирования

psql -c "create database tesdb2;"

Размер БД может быть изменен согласно запросу Заказчика до необходимого значения, например 1 ТБ.
Наполняем данными 1 гб (по требованию заказчика)
-i – опция инициализации; запуск команды с этой опцией создаст необходимые таблицы и загрузит тестовыми данными базу данных.
-s 68 – параметр scale factor, определяет объём данных.
100 000 ? 68 = 6 800 000 строк.

pgbench -h localhost -d tesdb2 -U postgres -i -s 68

Проверяем размер создавшейся БД Можно посмотреть результат в Платформе Tantor.

psql -c "\l+ tesdb2"

Выполняем эмуляцию нагрузки

pgbench -h localhost -p 5432 -c 90 -j 2 -t 100 tesdb2 ## 90 пользователей, 2 потока, 100 транзакций у каждого пользователя

pgbench -c 90 -j 25 -P 60 -T 200 tesdb2               ## нагрузить чтение/запись 25 потоков
pgbench -n -c 90 -j 25 -T 200 tesdb2 -b select-only   ## нагрузить только чтение

-c — количество конкурентных подключений -P — вывод информации каждые * сек -T — длительность теста в сек -j — число потоков -n — не запускать VACUUM перед тестом.

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

Latency - Низкие значения задержки (например, менее 10 мс) обычно считаются хорошими. Если задержка превышает 100 мс, это может указывать на проблемы с производительностью.

Пример использования sysbench.

Установка

sudo apt install sysbench
sysbench --help

Создание тестовой БД

sudo -iu postgres createdb testdb2

Инициализация данных в СУБД через локальное соединение:

sysbench oltp_common --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 prepare

Проведение теста: Сценарии oltp_read_write, oltp_read_only, oltp_update_non_index, и т.п. –threads – число параллельных потоков (клиентов).
–time – общее время теста в секундах.

sysbench oltp_read_write --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 --threads=10 --time=300 run

Очистка:

sysbench oltp_common --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 cleanup

Пример использования go-tpc.

Установка https://github.com/pingcap/go-tpc Подготовка БД для модели аналитических запросов

go-tpc tpch prepare -d postgres -U postgres -p 'postgres' -D benchmarkh -H 10.2.0.11 -P 5432 --conn-params sslmode=disable

Запуск эмуляции аналитического запроса

go-tpc tpch run -d postgres -U postgres -p 'postgres' -D benchmarkh -H 10.2.0.11 -P 5432 --conn-params sslmode=disable

FAQ доп информация, которая не рассматривалась в практикуме:

Для удобства отображения в psql редактируем содержание файла подсказки .psqlrc (~/.psqlrc)

Рекомендуется также настроить подсказку командного интерпретатора СУБД и вывести информацию по серверу, порту подключения, БД и пользователе. Настраиваем вид подсказки в файле .psqlrc в домашнем каталоге пользователя postgres при подключении к СУБД. переходим под пользователя postgres

sudo su - postgres

Редактируем конфигурационный файл

nano ~/.psqlrc

Добавляем в файл .psqlrc строку пример цветной промпт

\set PROMPT1 '%[%033[0;90m%][%p]%[%033[0m%] %[%033[0;31m%]%n%[%033[0m%]@%[%033[0;34m%]%m%[%033[0m%]:%[%033[0;32m%]%>%[%033[0m%] %[%033[0;36m%]%~%[%033[0m%] %[%033[0;33m%]%[%033[5m%]%x%[%033[0m%]%[%033[0m%]%R%# '
\set PROMPT2 '%[%033[0;90m%][%l]%[%033[0m%] %[%033[0;31m%]%n%[%033[0m%]@%[%033[0;34m%]%m%[%033[0m%]:%[%033[0;32m%]%>%[%033[0m%] %[%033[0;36m%]%~%[%033[0m%] %[%033[0;33m%]%[%033[5m%]%x%[%033[0m%]%[%033[0m%]%R%# '

Сохраняем и вызываем psql для проверки

psql

если мы работаем из под другого пользователя в системе с правами sudo, то можно подключиться к БД по локальному соединению так

sudo -iu postgres psql

Пояснение для подсказки '%M:%> %n@%/%R%#%x ': \set PROMPT1 '%M:%> %n@%/%R%#%x '

%M имя хоста сервера баз данных отображается «[local]», если соединение осуществляется через сокет домена Unix
%> прослушиваемый порт
%n имя пользователя сеанса
%/ текущая база данных
%R находитесь ли вы в однострочном режиме (^) или отключены (!), но обычно =
%# являетесь ли вы суперпользователем (#) или обычным пользователем (>)
%x статус транзакции - обычно пусто, если только не в блоке транзакции (*)

Пример вывода командной строки с подсказкой для сервера СУБД с IP 10.2.0.11, работающем на порту 5432, для пользователя postgres и БД test

10.2.0.11:5432 postgres@test=#

Cписок команд psql которые часто используются.

\l ## список БД
\dt ## список таблиц
\du ## список пользователей
\db ## список табличных пространств
\dn ## список схемы

\dx ## список установленных расширений
\dx+ pg_stat_statements ## Посмотрим содержимое расширения
SELECT * FROM pg_available_extensions; ## список доступных расширений

\d table_name ## структура таблицы
\c db_name ## подключиться к БД
\password user ## смена пароля УЗ в БД
\d+ pg_stat_wal_receiver ## вывести поля таблицы
\x ## задать параметр вывода следующим select таблицы по вертикали в читаемом виде, чтобы отключить также \x
select tantor_version(); ## посмотреть версию тантор

эти переменные также можно указать в .psqlrc

\pset pager on ## вкл постраничный пейджер, окно вывода команд с ожиданием в конце (end)
\pset pager off ## выкл постраничный пейджер
\pset pager ## статус постраничный пейджер
\pset linestyle unicode ## вывод таблиц будет отображаться линиями, вместо тире
\pset border 2
export PAGER='less -SXF' ## переменная окружения ОС, сменить утилиту вывода страницы в psql для пейджер.

Доп утилиты в ОС для работы с postgres, которые начинаются на pg*

https://docs.tantorlabs.ru/tdb/ru/17_5/se/reference-client.html

sudo su - postgres

</code> psql pg_ctl –help pg_basebackup –help pg_dumpall –help pg_dump –help pg_upgrade –help pg_isready –help </code> vacuumlo - (к вакуумированию (VACUUM) не имеет отношение) Это удобная для периодического запуска утилита удаления (вычистки) осиротевших больших объектов из баз данных кластера. Автоматизировать удаление осиротевших больших объектов можно разными способами (например, триггерами), эта утилита один из них. Расширение «lo» содержит функцию lo_manage() для использования в триггерах, предотвращающих появление осиротевших больших объектов.

pg_config –sharedir - директория с файлами расширения

ls -la /opt/tantor/db/16/share/postgresql

Если psql не запускается под пользователем postgres (bash: psql: команда не найдена), значит в переменной окружения path отсутствует путь до /opt/tantor/db/16/bin

редактируем переменную окружения

nano ~/.bashrc

добавляем и сохраняем

export PATH=/opt/tantor/db/16/bin:$PATH

Перезапускаем оболочку

exec bash

Проверяем подключение, пример

psql -p 5432 -h localhost -U postgres

!!! При необходимости, если есть отдельно требования заказчика.

Настройки правил подключения к БД. Документация по настройке pg_hba.conf: https://docs.tantorlabs.ru/tdb/ru/16_6/se/auth-pg-hba-conf.html#pg-hba-conf

sudo nano /var/lib/postgresql/tantor-be-16/data/pg_hba.conf

!!! При необходимости, если есть отдельно требования заказчика.
По умолчанию в параметрах конфигурации в файле postgresql.conf сервера СУБД не настроен вывод системных журналов СУБД в отдельных каталог и нет прямой ссылки на каталог данных.
Рекомендуется включить возможность вывода системных журналов отдельный каталог и указать прямую ссылку на каталог данных.

sudo nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf

Укажем путь сохранения log файлов

logging_collector = on;
log_directory = '/var/lib/postgresql/tantor-be-16/data/log/'

Применение параметров без перезагрузки сервера СУБД с проверкой

sudo -iu postgres psql
SELECT pg_reload_conf();
SHOW logging_collector;

посмотреть лог БД, пример:

less /var/lib/postgresql/tantor-be-16/data/log/postgresql-2024-05-04_194815.log

!!! не забудьте скорректировать скрипт Ротация логов.

При проверке системных журналов ОС

sudo journalctl -u tantor-be-server-16.service

Утилита сообщает, что журналы СУБД Tantor далее будут выводится в подкаталог log, каталога с данными БД. Далее, в нашем примере, процесс запуска СУБД Tantor Можно посмотреть в каталоге /var/lib/postgresql/tantor-be-16/data/log в содержании самого нового файла postgresql-<дата>.log

Сетевые настройки слушателя и порта инстанса СУБД.

sudo nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf

ищем и выставляем параметры

listen_addresses = '*'

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

listen_addresses = 'localhost, <ip>'

port = 5433

перезагружаем и проверяем

sudo systemctl restart tantor-be-server-16
sudo ss -tulnp | grep postgres

подключаемся к СУБД по новому порту

sudo -iu postgres psql -p 5433 -h 10.2.0.11 -U postgres

!!! При необходимости, если есть отдельно требования заказчика.
Можно перенести каталог с данными экземпларя СУБД на отдельный другой католог или точку монтирования (диск) в ОС

Останавливаем службу СУБД

sudo -i
systemctl stop tantor-be-server-16.service

Редактируем в postgresql.conf ссылку на новый каталог данных

nano /var/lib/postgresql/tantor-be-16/data/postgresql.conf

Прямая ссылка на новый каталог данных, мы просто меняем путь и сохраняем.

data_directory = '/new/data/directory'

Переносим data каталог через команду mv или копируем через cp -R в новый каталог

cp -R /var/lib/postgresql/tantor-be-16/data /new/data/directory

Назначаем права на новый каталог

sudo chown -R postgres:postgres /new/data/directory

Меняем путь в службе

sudo nano /lib/systemd/system/tantor-be-server-16.service

Environment=PGDATA=/new/data/directory

Запускаем экземпляр

sudo systemctl daemon-reload
sudo systemctl start tantor-be-server-16.service

Пакеты в ОС можно устанавливать через команды

sudo dpkg -i **.deb \\
<code>
>Нужно будет также установить все зависимости руками. \\

> При этом инициализация инстанса СУБД не будет производиться автоматически.

> Если нужно создать инстанс СУБД или пересоздать чистую конфигурацию в другой каталог, инициализация СУБД Tantor производится под пользователем postgres следующим образом: \\

----

Переходим в УЗ postgres

<code>
sudo su - postgres

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

/opt/tantor/db/16/bin/initdb -D /var/lib/postgresql/tantor-be-16/data2 --data-checksums

Правим порт, например 5433, если нужно, смотри комментарий ниже.

nano /var/lib/postgresql/tantor-be-16/data2/postgresql.conf

!!! Если планируется запускать параллельно несколько экземпляров, то порты конфигурации СУБД в postgresql.conf должны быть разные,
В продуктивных системах это не рекомендуется, так как нагрузка CPU и RAM между процессами может делиться неравномерно, но рамках тестирования допустимо.

Для параллельного запуска экземпляров одной и той же версии сборки СУБД создадим отдельный новый файл службы под root.

sudo -i
cp /lib/systemd/system/tantor-be-server-16.service /lib/systemd/system/tantor-be-server-16-data2.service
nano /lib/systemd/system/tantor-be-server-16-data2.service

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

Environment=PGDATA=/var/lib/postgresql/tantor-be-16/data2

Запустим новую службу

systemctl daemon-reload
systemctl enable --now tantor-be-server-16-data2
systemctl status tantor-be-server-16-data2.service

Ручной запуск инстанса СУБД без службы.

sudo su - postgres

/opt/tantor/db/16/bin/pg_ctl start -D /var/lib/postgresql/tantor-be-16/data2

Останавливаем

/opt/tantor/db/16/bin/pg_ct stop -D /var/lib/postgresql/tantor-be-16/data2

посмотреть все возможности pg_ctl

/opt/tantor/db/16/bin/pg_ct --help

!!! Если планируется установка нескольких версий сборок пакетов СУБД
Например Tantor 15, Tantor 16 версий, то путь до pg_ctl должен быть соответствующий версии.
Службы для разных версий СУБД после установки пакетов будут разные, создавать отдельно не нужно.

Обновление СУБД tantor по мажорной версии на, пример с 15 на 16.

Вариант 1 Возможен только между одинаковыми сборками СУБД.
se15 → se16

be15 → be16

se1c 15 → se1c 16

В противном случае при проверке будут ошибки, и тогда Вариант 2, обновление СУБД можно выполнить только через восстановление из бекапа pg_dumpall.

делаем логический бекап БД, pg_basebackup сюда не подойдет, так как pg_basebackup создаёт полную копию каталога данных.

pg_dumpall -U postgres > backup.sql

Установите пакет новой версии PostgreSQL c инициализацией новой БД процесс описан в начале файла. инициализацию можно выполнить руками если вы просто установили пакет.

/opt/tantor/db/16/bin/initdb -D /var/lib/postgresql/tantor-se-16/data --no-data-checksums

обновите права на подкаталоги

chown -R postgres:postgres /var/lib/postgresql

останавливаем все СУБД (рекомендуется для больших баз)

systemctl stop tantor-*

Проверьте совместимость кластеров

su - postgres

/opt/tantor/db/16/bin/pg_upgrade \
--old-datadir /var/lib/postgresql/tantor-be-15/data \
--new-datadir /var/lib/postgresql/tantor-be-16/data \
--old-bindir /opt/tantor/db/15/bin \
--new-bindir /opt/tantor/db/16/bin \
--check     ## добавьте -v для полного вывода

Вариант 1 Обновление СУБД через утилиту pg_upgrade.

Процесс скопирует данные из старого кластера в новый и настроит его для работы

/opt/tantor/db/16/bin/pg_upgrade \
--old-datadir /var/lib/postgresql/tantor-be-15/data \
--new-datadir /var/lib/postgresql/tantor-be-16/data \
--old-bindir /opt/tantor/db/15/bin \
--new-bindir /opt/tantor/db/16/bin

Если обновление успешно, можно удалить старую версию. будет сообщение: Не забудьте проверить postgresql.auto.conf, postgresql.conf и pg_hba.conf на новой инсталяции, если конфигурация дефолтная, перенесите со старой в новую.

Обновление завершено

Статистика оптимизатора утилитой pg_upgrade не переносится.
Запустив новый сервер, имеет смысл выполнить:
/opt/tantor/db/16/bin/vacuumdb –all –analyze-in-stages
При запуске этого скрипта будут удалены файлы данных старого кластера:
./delete_old_cluster.sh

Перенесите настройки из старого postgresql.conf и pg_hba.conf в новый кластер, если они отличаются.

запускаем кластер

/opt/tantor/db/16/bin/pg_ctl -D /var/lib/postgresql/tantor-be-16/data start

обновляем статистику

/opt/tantor/db/16/bin/vacuumdb --all --analyze-in-stages

подключаемся к бд и проверяем

psql
select tantor_version();
SELECT version();
\l
\q

удаляем старый кластер

./delete_old_cluster.sh

или вручную

rm -rf /var/lib/postgresql/tantor-<старая_версия>

удаляем старые пакеты

apt remove tantor-<старая_версия>

Вариант 2: pg_dump + pg_restore (если pg_upgrade недоступен из-за ошибо совместимости)

Перенесите настройки из старого postgresql.conf и pg_hba.conf в новый кластер пример:

cd /var/lib/postgresql/tantor-be-15/data
cp postgresql.conf postgresql.auto.conf pg_hba.conf /var/lib/postgresql/tantor-be-16/data

Запустите кластер новую версию СУБД

/opt/tantor/db/16/bin/pg_ctl -D /var/lib/postgresql/tantor-be-16/data start

Восстановите данные:

Если в бэкапе есть ошибки (например, из-за различий в версиях),добавьте флаг –no-sync для игнорирования мелких проблем.

psql -U postgres -f backup.sql

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

psql
select tantor_version();
SELECT version();
\l
\q

Если обновление успешно, можно удалить старую версию.

apt remove tantor-<старая_версия>
rm -rf /var/lib/postgresql/tantor-<старая_версия>

Если нужно перенастроить переменные платформы /opt/tantor/eco/platform.env

например: после установки внести настройки почты переходим в каталог

cd /opt/tantor/eco/

останавливаем докеры

sudo docker-compose --env-file=platform.env down

правим файл c переменными и сохраняем

nano platform.env
EMAIL_PORT=
EMAIL_USERNAME=
EMAIL_HOST=
EMAIL_PASSWORD=

поднимаем контейнеры с новыми параметрами

docker-compose --env-file platform.env up -d

проверяем платформу через браузер.

удаление платформы

sudo docker stop $(docker ps -aq)
sudo docker rm $(docker ps -aq)
sudo docker container prune
docker system prune -a
sudo docker rmi $(docker images -q)
sudo rm -rf /opt/tantor

удаление СУБД и агента

sudo apt purge tantor-be-server-16
sudo rm -rf /opt/tantor/
sudo rm -rf /var/lib/postgresql/tantor-be-16/

sudo apt purge pmaagent
sudo rm -rf /var/lib/pma/