====== 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 /<путь где лежит ключ>/ 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 - номер, проверяемого порта > - адрес проверяемого узла Пример, проверяем доступность порта 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:** | | Почтовый адрес администратора Платформы Tantor | | **Tantor Platform administrator name:** | | Имя администратора Платформы Tantor | | **Tantor Platform domain name:** | | Доменное имя Платформы 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 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, ' 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/