Это старая версия документа!
Содержание
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 СУБД нужной версии и скрипт инсталяции предварительно на к себе носитель из:
## be-версия Tantor СУБД для тестового использования можно скачать
Устанавливаем пакет СУБД Tantor на db1 db2 db3. https://docs.tantorlabs.ru/tdb/ru/16_6/be/binary-download-execute.html
1. Установка через доступ интернета 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
2. Способ установки локально, если закрытый сегмент. Предварительно копируем файлы с носителя на хосты по сети
—————————————————————-
## Пример копирования файлов на стенд из практикума ## Скачиваем файллы из личного кабинета астры 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
1. Способ при наличии доступа в интернет
—————————————————————-
## Загрузим инсталлятор на хост 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
2. Способ, если закрытый сектор, и вам дали доступ временно в сети заказчика.
——————————————————————————-
## Скачиваем файллы из личного кабинета астры 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: ## Почтовый адрес администратора Платформы Tantor, пример admin@astralinux.ru Tantor Platform administrator name: ## Имя администратора Платформы Tantor, пример <admin> Tantor Platform domain name: ## Доменное имя Платформы Tantor, пример <tplatform.example> 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 и последующем добавлении инстанса СУБД в платформу необходимо перейти на сервер СУБД и произвести предложенные Платформой действия. https://docs.tantorlabs.ru/tp/5.3/instance_adding.html
!! Установку агента всегда начинаем на лидере в кластере !!
1. Открыть рабочее пространство в Платформе 2. Добавить новый инстанс (сервер СУБД) Add instance 3. Выбрать тип инстанса (в наше примере Tantor) 4. Указать IP адрес, порт и имя БД 5. Платформа сообщает, что агент не установлен на выбранном инстансе и предлагает выбрать тип и версию ОС инстанса 6. Далее необходимо выполнить ряд предлагаемых Платформой действий на узле сервера СУБД, для исключения ошибки скопировать каждое действие в буфер можно кликнув на пиктограмму в конце каждой строки.
## Узнаем 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-систем (онлайн-аналитическая обработка)) -- эталонный тест, эмулирующий работу приложений бизнес-аналитики, состоит из набора бизнес-ориентированных специальных запросов и одновременных модификаций данных, анализирует большие объемы данных, выполняют запросы высокой степени сложности.
1. pgbench -- программа для запуска эталонных тестов на PostgreSQL, выполняет последовательность команд SQL, вычисляет среднюю скорость транзакций (транзакций в секунду), использует сценарий, основанный на TPC-B, включающий пять команд SELECT, UPDATE и INSERTна транзакцию, также ПО позволяет протестировать собственный сценарий транзакций;
2. go-tpc -- набор инструментов тестирования рабочих нагрузок на основе тестов TPC для СУБД PostgreSQL, выполняющий тест TPC-H. https://github.com/pingcap/go-tpc
3. sysbench -- это универсальный инструмент для стресс-тестирования
4. 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 для пейджер.
Остальное само изучение или курсы по DBA1, DBA2
Доп утилиты в ОС для работы с postgres, которые начинаются на pg* https://docs.tantorlabs.ru/tdb/ru/17_5/se/reference-client.html
sudo su - postgres
psql pg_ctl –help pg_basebackup –help pg_dumpall –help pg_dump –help pg_upgrade –help pg_isready –help
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 Нужно будет также установить все зависимости руками. При этом инициализация инстанса СУБД не будет производиться автоматически. Если нужно создать инстанс СУБД или пересоздать чистую конфигурацию в другой каталог, инициализация СУБД Tantor производится под пользователем postgres следующим образом:
## Переходим в УЗ postgres
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/