Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

Установка СУБД

Есть несколько способов установить сервер СУБД PostgreeSQL. Основным способом является установка из репозитария вашей операционной системы, например в ALT Linux 10 можно выбрать любую версию по последнюю 16, а также кастомизированные версии для 1C, вероятно именно 1C и выпускаемые. Да, компания 1С выпускает кастомизированные версии Postgree SQL для работы со своим продуктом. Другим способом является сборка из исходных кодов, которая позволяет провести глубокую кастомизацию. Например изменить размер WAL для старых версий СУБД. Кроме этого портал сообщества postgresql.org поддерживает свои репозитарии с массой пакетов, которые позволяют, например, поставить современные версии СУБД на относительно старый Linux, по ссылке портал PostgreeSQL.org: описание установки для RHEL

Пример 01. Установка Postgree SQL для бизнес приложения КрАгрАн БЕССТ Сервер Linux развернут давно, Scientific Linux 7.х, в составе которого идёт из коробки старенький Postgres SQL 9.2, обеспечивающий функционирование программного продукта не первый год. Однако функционала PgSQL 9.2 во многом уже не хватает, нет транзакций внутри процедур, даже одноранговых, нет MERGE, разного нет - требуется установка новой версии СУБД и перенос данных

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

# конфигурируем YUM
yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
yum install -y postgresql15-server postgresql-contrib
# инициализируем кластер БД, полезно с ключом -k
/usr/pgsql-15/bin/postgresql-15-setup initdb
# включаем автостари сервиса
systemctl enable postgresql-15
systemctl start postgresql-15

После чего средствами pg_dumpall выгружаем кластер БД старой версии и перегружаем его во вновь инициализированный кластер БД новой версии, о чём есть отдельный обзор. Опционально доконфигурирование СУБД и разворачиваем статистические расширения СУБД, о чем мной подготовлено исследование обзор в отдельной статье

Пример 02. Установка Postgree SQL для 1С Здесь ситуация усложняется тем, что нужно либо самому собирать СУБД, наложив перед этим на исходные коды патчи от компании 1C, либо использовать дистрибутив, подготовленный компанией 1С. Изначально для установки подготовлен сервер RHEL 9.x. На сервере настроены репозитарии вендора для доустановки зависимостей. Также с сайта техподдержки 1С, раздела релизов, скачаны дистрибутив PgSQL 16.2-3.1C, расширения PgSQL 16.2-3.1C, требуемые дополнительные пакеты для RHEL 9.x. Доступ к пакетам есть только при наличии доступа к закрытому разделу сайта техподдержки 1С

Далее - полученные архивы развёрнуты и все пакеты внутри архивов установлены командой yum install. Сначала устанавливается группа дополнительных пакетов с сайта 1C redhat9.x86_64.tar, далее пакеты из архива postgresql_16.2_3.1C_x86_64_rpm.tar.bz2, далее группа пакетов из архива postgresql_16.2_3.1C_x86_64_addon_rpm.tar.bz2, причём только после включения DNF репозитария 09_codeready_builder, обеспечивающего установку зависимых пакетов

Так как часть расширений не получится поставить из репозитария сообщества, и в CONTRIB его нет - потребуется собирать руками. Это, например, касается расширений ps_wait_sampling, pg_store_plans, pg_stat_kcashe. Благо для 9 версии RHEL/OL всё собирается без эксцессов. Арзивы с исходниками необходимо распаковать, добавить в переменную PATH путь к каталогу с утилитой pg_congig, после чего последовательно зайти в корень исходников каждого расширения, собрать и установить каждое расширение двумя командами: make USE_PGXS=1 ; make USE_PGXS=1 install ; В целом описание процесса ручной сборки есть в документации к каждому расширению

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

# для RHEL9 из под root
yum install glibc-langpack-ru langpacks-core-font-ru langpacks-core-ru langpacks-ru
localectl set-locale ru_RU.UTF-8
# и перегружавем сервер
reboot

После инициализации кластера БД и старта сервера БД начальную установку можно считать состоявшейся, можно сконфигурировать сетевой доступ в hba.conf, создать пользователя БД и тестовую базу, и передать данные соединения администраторам 1С для подключения в БД и создания конфигураций 1C. Также можно модифицировать конфигурацию СУБД в соответствиями с рекомендациями от 1C 01, 02, 03, 04, 05, 06. Настройки резервного копирования, расширений, аналитика нагрузки - предмет отдельных разговоров

Создание кластера БД

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

log_connections = 'on'
log_disconnections = 'on'
log_hostname = 'on'
max_connections = '5000'
shared_buffers = '4096MB'
temp_buffers = '128MB'
work_mem = '120MB'
maintenance_work_mem = '128MB'
# vacuum_cost_limit выставил в потолок, чтобы важная задача вакуумизации не прерывалась по надуманному лимиту
# а она ещё и строки морозит, и статистику обновляет, и карты видимости и свободного пространства правит
vacuum_cost_limit = '10000'
max_stack_depth = '7MB'
# в последних версиях стоит по умолчанию, вместо старого 0.5
#checkpoint_completion_target = 0.9

Параметры управления памятью системы и выставления приоритетов Linux OOM, рассмотренные в PG guide/ Kernel resource management, для Linux RHEL/Oracle по умолчанию удовлетворяют требованиям в части настройки параметрой ядра, требованию "системности" [postgresql_uid < SYS_UID_MAX@/etc/login.defs] пользователя - владельца СУБД при использовании systemd, приоритезации OOM. Хотя это нужно проверять для каждой пары ОС + СУБД. Параметр ядра net.core.somaxconn по умолчанию выставлен в 4096, и должен превышать разрешённое количество соединений. Параметр fs.file_max также нужно отслеживать, на на моих ОС он в безлимите по умолчанию. Что стоит проанализировать и, возможно, напроить - использование huge pages. но это касается только сверхнагруженных БД

Установка инструментов работы

Основным инструментом является консольная утилита psql, аналог sqlplus в Oracle. Она идёт в составе поставки сервера PostgreSQL, и умеет очень многое. Однако часто бывает удобнее использовать полноценную графическую утилиту. В составе поствкие Oracle идёт утилита SQL Developer, а вот для Postgree SQL штатно такой утилиты нет. Однако это мир OpenSource, и по факту в качестве такой утилиты обычно используется PgAdmin, который по 3 версию был обычным приложением, лежащим в репозитариях Linux. Однако он поддерживал нормально 8 - 9 релизы. В дальнейшем разработчик этого инструмента выпустил 4 поколение, которое умеет работать и консольно, и через WEB интерфейс. В репозитариях я его не видел, но на портале PostgreeSQL есть отдельный репизитарий, позволяющий поставить этот инструмент. Детали расписаны в ссылке на установку PgAdmin4

Административные расширения СУБД. Установки и конфигурирование

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

1. Подключить пакеты репозитариев postgresql.org в операционную систему сервера и установить требуемые пакеты расширений

2. Для тех расширений, которые отсутствуют на ресурсе postgresql.org скачать их исходные коды с репозитария git, скомпилировать и установить в СУБД. Для отдельной сборки от компании 1С 16 версии СУБД и версии Oracle Linux 9.х ряд расширений входит в т.н. пакет contrib, но поставить недостающие расширения из репозитария сообщества не получится - для них потребуется и сама СУБД именно от сообщества, которая без патчей для 1С непригодна. Тут придётся солбирпать расширения из исходных кодов. Примером таких расширений являются https://github.com/postgrespro/pg_wait_sampling, https://github.com/ossc-db/pg_store_plans, https://github.com/powa-team/pg_stat_kcache. Исходники можно скачать и собрать после того, как будет установлена сама СУБД, например от 1С, и пакеты разработки именно для неё. Сам процесс сборки использует данные, которые отдаются командой pg_config требуемой вам версии СУБД. Команды сборки типовые, кроме указания переменной USE_PGXS=1 и пути к pg_config:

export PATH=...+pg_config_path
make USE_PGXS=1 | tee ./make_log.out
make USE_PGXS=1 install | tee ./make_install_log.out

3. Сконфигурировать запуск установленных расширений на уровне СУБД, для чего добавить конфигурационные параметры в файл postgresql.conf. И явно рестартовать сервер. Файл postgresql.auto.conf не подойдёт, об этом не раз говорилось в документации к расширениям. Мои текущие предпочитаемые параметры для продукта КрАгрАн БеССт таковы:

shared_preload_libraries = 'pg_cron,pg_wait_sampling,pg_store_plans,pg_stat_statements,pg_stat_kcache'
compute_query_id = on
pg_stat_statements.max = 50000
pg_stat_statements.track = all
pg_stat_statements.track_utility = on
pg_stat_statements.track_planning = on
pg_wait_sampling.history_size = 10000000
pg_wait_sampling.history_period = 1000
pg_wait_sampling.profile_period = 1000
pg_wait_sampling.profile_pid = true
pg_wait_sampling.profile_queries = true
pg_store_plans.max = 1000000
pg_store_plans.track = all
pg_stat_kcache.linux_hz* = -1
pg_stat_kcache.track = all
pg_stat_kcache.track_planning = true
cron.database_name = 'crypta'

4. Создать расширения внутри требуемых вам БД. В случае, если вы хотите, чтобы расширения автоматически появились во всех новых базах кластера БД, расширения необходимо создавать также, насколько помню, и в БД template1 этого же кластера. Однако, если новые БД создаются с явным указанием не типового шаблона, расширения придётся создавать в них руками:

create extension mchar ;
create extension plpgsql ;
create extension adminpack ;
create extension fasttrun ;
create extension fulleq ;
create extension pg_buffercache ;
create extension pg_freespacemap ;
create extension pg_visibility ;
create extension pgstattuple ;
create extension pg_walinspect ;
create extension pgrowlocks ;
create extension pageinspect ;
create extension pg_wait_sampling ;
create extension pg_stat_statements ;
create extension pg_store_plans ;
create extension pg_stat_kcache ;
create extension pg_cron ;

5. Использовать свой код для доступа к данным расширений для их обработки и аналитики. Я пользуюсь своими инструментами, реализованными в составе КрАгрАн БеССт, а также

Белонин С.С. (С), февраль 2024 года
(даты последующих модификаций не фиксируются)