Обновление#

Данный раздел рассматривает процесс обновления СУБД Pangolin.

В составе дистрибутива (папка installer) расположены два скрипта, для установки обновления:

• Скрипт-разведчик — скрипт проверки перед обновлением.

• Скрипт-обновление — основной скрипт, при запуске которого происходит установка обновления.

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

• Обновление, при котором осуществляется замена старых файлов (исполняемых, конфигурационных, файлов расширений) на их обновленные версии, либо добавляются новые утилиты, которые отсутствовали в предыдущих версиях. Характеризуется малым временем выполнения и возможностью обновления без прерывания работы сервиса.

• Обновление, при котором, помимо обновления файлов, осуществляется изменение структуры или состава данных в системных каталогах обновляемых БД. Характеризуется дополнительным набором предварительным проверок, обновлением с прерыванием работы сервиса и рекомендацией по созданию резервной копии перед обновлением.

Примечание:

Под изменением структуры или состава данных понимается:

• изменение состава системных таблиц;

• изменение состава системных представлений;

• изменение состава системных функций;

• изменение списка встроенных типов данных;

• изменение формата хранения данных (включая изменения в алгоритме шифрования).

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

В СУБД Pangolin предусмотренно два сценария обновления:

• обновление исполняемых данных (обновление первого уровня сложности) – процесс обновления, в ходе которого достаточно просто заменить старые файлы (исполняемые, конфигурационные, файлы расширений) их обновленными новыми версиями, либо обновить версии утилит, входящих в состав дистрибутива. Такое возможно, так как формат внутреннего хранилища при таких модификациях не изменяется. Данное обновление необходимо проводить, например, при изменении конфигурационных файлов, используемых утилит и расширений или при доработке кода самой БД, когда в формат внутреннего хранилища БД не вносятся никакие изменения, в том числе ни один из критериев перечисленных в списке «Критерии определяющие необходимость проведения обновления СУБД Pangolin с переносом данных» не выполняется. В старой терминологии для обозначения этого типа обновления использовалось «минорное обновление СУБД»;

• обновление с переносом данных (обновление второго уровня сложности) – процесс обновления более сложный, чем просто замена одних файлов другими. В данном случае процесс дополнительно усложнен необходимостью проведения тестов, проверяющих возможность обновиться, а также миграцией данных, так как при этом типе обновления вносятся изменения в формат внутреннего хранилища БД. Данное обновление необходимо проводить в случае, если выполняется один или несколько критериев перечисленных в списке «Критерии определяющие необходимость проведения обновления СУБД Pangolin с переносом данных». В старой терминологии для обозначения этого типа обновления использовалось «мажорное обновление СУБД».

Критерии определяющие необходимость проведения обновления СУБД Pangolin с переносом данных:

• изменение мажорной версии ванильного PostgreSQL;

• изменение состава или структуры системных каталогов;

• изменение состава или структуры встроенных функций;

• изменение состава или структуры встроенных представлений;

• изменение файловой структуры, в том числе алгоритма шифрования;

• изменение состава конфигурационных файлов;

• изменение списка встроенных типов данных.

Общая информация по обновлению СУБД Pangolin#

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

• выводит список установленных extensions (в процессе обновления они не будут перенесены в новую версию СУБД Pangolin):

  • сторонние/не входящие в текущую версию продукта СУБД Pangolin;

  • запрещенные расширения;

  • расширения, несовместимые с новой версией СУБД Pangolin;

  • полный список ограничений, для администраторов автоматизированной системы (в случае их наличия);

• проверит возможность создания резервной копии (РК). Локальная РК является необходимым условием для работы механизма автоматического отката к исходной версии СУБД в случае возникновения любых внештатных ситуаций в процессе работы механизма обновления.

  Внимание!

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

• проверит наличие дубликатов в конфигурационном файле Pangolin Manager (postgres.yml);

• проверит наличие специальных символов в конфигурационных файлах postgres.yml, pg_hba.conf, postgresql.conf.

В процессе обновления будет обновлена СУБД Pangolin и версии всех утилит, входящих в состав продукта.

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

• postgres.yml (в случае наличия Pangolin Manager);

• pangolin-pooler.ini (в случае наличия Pangolin Pooler);

• pg_hba.conf;

• postgresql.conf.

Важно! При обновлении с pgbouncer на Pangolin Pooler ДО обновления patroni на Pangolin Manager необходимо:

• проверить наличие файла /etc/patroni/reload_pgbouncer.sh

• изменить содержимое файла: строку sudo systemctl restart pgbouncer заменить на sudo systemctl restart pangolin-pooler

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

Примечание:

Перед запуском скрипта обновления добавьте в файлы sudoerc основного узла, реплики и арбитра строку user_ansible ALL=(ALL:ALL) NOPASSWD: ALL.

Схемы процесса обновления#

Схема процесса обновления СУБД Pangolin второго уровня сложности для конфигурации standalone: реализация внутренних процессов#

Схема процесса обновления СУБД Pangolin второго уровня сложности для конфигурации cluster: реализация внутренних процессов#

Список ограничений перед проведением обновления СУБД Pangolin#

• WARNINGS (рекомендуется устранить, решение за пользователем):

  • проверьте наличие расширений, установленных в схему public или в системный каталог (рекомендуется: перенести в схему ext);

  • в случае использования конфигурации СУБД cluster-patroni-etcd-pgbouncer (версии СУБД Pangolin до 5.1.0) при обновлении, утилита confd будет автоматически удалена. Поэтому до обновления измените строку подключения к СУБД (проверьте значения портов) и убедитесь что в строке указаны оба узла кластера (active и standby). Например, если раньше было:

    jdbc:postgresql://127.0.0.1:6544,127.0.0.2:6544/dbname?prepareThreshold=0`
    

    исправьте на:

    jdbc:postgresql://127.0.0.1:6544,127.0.0.2:6544/dbname?targetServerType=master&prepareThreshold=0
    

• ERRORS (обязательно должны быть устранены, иначе обновление не будет доступно):

  • проверьте, что в БД не используются данные следующих типов abstime, reltime, tinterval (рекомендуется: не использовать перечисленные типы данных):

    -- поиск устаревших типов данных // запускать необходимо для КАЖДОЙ БД
    SELECT format('%1$s.%2$s(%3$s)',ns.nspname,cl.relname,att.attname) tbl_fld
    FROM pg_attribute att
    JOIN pg_type tp ON att.atttypid =tp.oid
    JOIN pg_class cl ON att.attrelid =cl.oid
    JOIN pg_namespace ns ON cl.relnamespace = ns.oid
    WHERE tp.typname IN ('abstime','reltime','tinterval') AND NOT (ns.nspname SIMILAR TO '(pg_|information_schema)%');
    

  • убедитесь, что значение параметра max_worker_process конфигурационного файла не превышает сумму количества баз данных на узле (включая системные template1, postgres) + 6. Например, если количество БД = 26, то значение параметра должно быть не меньше 32.

Список необходимых действий после завершения процесса обновления СУБД Pangolin#

• WARNINGS (рекомендуется устранить, решение за пользователем):

  • необходимо учесть, что файл recovery.conf более не используются в логике работы СУБД (для кластерной конфигурации);

  • в работе автоматизированной системы (приложение работающее с СУБД Pangolin) необходимо учесть, что была расширена информация о клиентских сертификатах SSL в представлении pg_stat_ssl и колонка clientdn была переименована в client_dn;

  • в работе автоматизированной системы необходимо учесть, что были изменены параметры хранения и ротации WAL-файлов, параметр wal_keep_segments был объявлен устаревшим, поэтому необходимо перейти на использование параметра wal_keep_size;

  • обращаем внимание, что начиная с версии СУБД Pangolin 5.1.0 введено понятие TRUSTED EXTENSIONS, таким образом определенные расширения (список таких расширений можно получить с помощью запроса SELECT DISTINCT name FROM pg_available_extension_versions WHERE TRUSTED ORDER BY name;) в дальнейшем могут быть созданы пользователями с правами CREATE (пользователи входящие в as_admin группу) на уровне базы данных;

  • в работе автоматизированной системы необходимо учесть, что в новой версии СУБД Pangolin могли быть изменены некоторые вендорские процедуры, а именно, мог измениться состав или порядок аргументов для них (например, функции sec_admin, в которых убран аргумент current_database).

  Примечание:

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

Таблица поддерживаемых для обновления версий СУБД#

Обновление на версию 6.2.0#

Внимание!

Обновление стендов с разным набором СЗИ возможно только с версии 5.4.0 и выше.

Внимание!

В остальных случаях (не отраженных в таблице) обновление невозможно.

Примечание:

Тип конфигурации определен следующим образом:

• с СЗИ – включено хотя бы одно из СЗИ (TDE, защита конфигурации, защита от привилегированных пользователей) включено;

• без СЗИ – СЗИ отключены.

Как определить версию, установленную на сервере#

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

Проверка готовности к обновлению#

Внимание!

В случае, если все пароли указывались в открытом виде, параметры --ask-vault-pass и --vault-password-file=название_файла_с_ключом добавлять не нужно!

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

1. Скачайте и распакуйте дистрибутив на сервере.

2. Перейдите в каталог с распакованным дистрибутивом, а затем в каталог installer.

3. Перед запуском обновления заполните файл hosts.ini, в зависимости от установленного решения, добавив информацию о хостах и учетных данных пользователя, которые будет использовать Ansible.

   Внимание!

   Данные должны содержать те же параметры, что и при установке. Примеры заполнения файлов описаны в разделе «Установка».

4. Заполните настраиваемый конфигурационный файл custom_file_sample.yml.

5. Заполните конфигурационный файл all.yml.

6. Чтобы удостовериться в готовности к обновлению, используйте ansible-сценарий проверки. Пример команды:

    ansible-playbook playbook_scouting.yaml -i inventories/standalone/hosts.ini -t always,standalone --ask-vault-pass -vv --extra-vars "local_distr_path=${} segment=${} custom_config=${} pangolin_license_path=${} stand=${}"
   

   Ниже приведены шаблоны сценариев для различных решений:

   • Проверка односерверного решения:

   ansible-playbook playbook_scouting.yaml
   -i inventories/standalone/hosts.ini
   -t always,standalone
   –ask-vault-pass
   -vv
   –extra-vars "local_distr_path=${}
   segment=${}
   custom_config=${}
   pangolin_license_path=${}
   stand=${}"

   
   - Проверка кластерного решения:
   
   ```bash
   ansible-playbook playbook_scouting.yaml \
   -i inventories/cluster/hosts.ini \
   -t always,cluster \
   --ask-vault-pass \
   -vv \
   --extra-vars "local_distr_path=${} \
   segment=${} \
   custom_config=${} \
   pangolin_license_path=${} \
   stand=${}"
   

   Описание параметров:

   • custom_config — абсолютный путь к файлу конфигурации custom_file_template.yml;

   • local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

   • segment — сегмент сети;

   • pangolin_license_path - полный путь к каталогу, где расположены файлы лицензии

   • stand — стенд для тестирования или конечной инсталляции (dev или prom).

   Значения используемых в команде запуска Ansible ключей:

   • -i — путь к inventory-файла;

   • --extra-vars — переменные, которые по приоритету важнее переменных из inventory;

   • -t — теги для запуска;

   • -v — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;

   • --ask-vault-pass или --vault-password-file — расшифровка зашифрованных файлов во время выполнения.

     Внимание!

     Для шифрования паролей в примерах выше, использовался следующий ansible-vault пароль: postgreSQL_SE_654321.

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

Проверки и информационные сообщения процесса разведки#

Проверки начинаются с разблокировки пользователя postgres в OC и выставления бессрочного пароля на время работы скрипта.

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

Происходит загрузка custom_file_sample.yml и словаря update.yml, содержащего дополнительные переменные с информацией для выводимых сообщений и поддерживаемых расширений.

Проверка установленной версии ansible#

Если текущая версия ansible меньше поддерживаемой версии, то выводится блокирующая дальнейшее выполнение сценария ошибка:

Current ansible version: {{ hostvars['127.0.0.1'].ansible_version.full }}. Needed ansible version: {{ ansible_ver }} or higher

Проверка корректности конфигурационного файла postgresql.conf#

Если конфигурационный файл содержит какие-либо ошибки, то выводится сообщение:

"{{ control_name }}.FAIL__В кандидате на обновление для хоста {host} в конфигурационном файле postgresql.conf обнаружены ошибки заполнения.__{{ control_name }}.FAIL"

Проверка того, что для узлов master и/или replica существует только одно FQDN-имя#

Если для узлов master и/или replica существует более одного FQDN-имени, то выводится сообщение:

"{{ control_name }}.FAIL__В кандидате на обновление для хоста {ansible_fqdn} обнаружен дублирующий fqdn {double_fqdn}.__{{ control_name }}.FAIL"

Проверка того, что значение search_path всегда не пустое#

Если search_path для одной из ролей равен пустому значению (не заполнен), то выводится сообщение:

"{{ control_name }}.FAIL__В кандидате на обновление обнаружено незаполненное значение для поля search_path для следующих пользовательских ролей {roles}. Поле search_path не должно иметь пустое значение, это необходимо для корректного конфигурирования СУБД в процессе обновления.__{{ control_name }}.FAIL"

Проверка поддерживаемой версии к обновлению#

В случае невозможности обновления будет получена ошибка вида:

"{{ control_name }}.FAIL__Обновление невозможно при наличии включенных СЗИ (TDE, защита конфигурации, защита от привилегированных пользователей) в автоматическом режиме для версии (pg_current_version). Обратитесь к администраторам СУБД для осуществления обновления вручную.__{{ control_name }}.FAIL"

Для осуществления обновления вручную необходимо обратиться к администратору.

Проверка символьной ссылки до плагина, реализующего взаимодействие с физическим сервером VAULT#

В случае невозможности обновления по данной причине будет получено следующее сообщение:

"{{ control_name }}.FAIL__На стенде обнаружено использование VAULT заменителя. Произвести обновление будет невозможно. Необходимо перевести стенд на использование физического VAULT сервера и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка пароля postgres_db_pass, передаваемого в пользовательском конфигурационном файле#

Ожидается зашифрованное с помощью ansible-vault значение. В случае ошибки будет получено следующее сообщение:

"{{ control_name }}.FAIL__Для корректного обновления пароль от суперпользователя postgres должен быть задан в открытом виде, либо в виде ansible-хэша. Скорректируйте значение для параметра postgres_db_pass в пользовательском конфигурационном файле '{}' и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка корректной записи хеша пароля суперпользователя postgres во временный файл для корректной инициализации БД#

В случае ошибки будет получено сообщение вида:

"{{ control_name }}.FAIL__В процессе формирования хэша для пароля суперпользователя postgres что-то пошло не так. Пароль не был записан во временный файл '{}'. Инициализация БД невозможна. Произведите проверку корректно заполненного параметра postgres_db_pass в пользовательском конфигурационном файле '{}' и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка наличия пароля суперпользователя postgres в исходной БД#

При возникновении ошибки будет получено следующее сообщение:

"{{ control_name }}.FAIL__Пароль от суперпользователя postgres в исходной БД не задан. Произвести обновление будет невозможно. Скорректируйте значение для параметра postgres_db_pass в пользовательском конфигурационном файле '{}' и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка идентичности паролей суперпользователя postgres в исходной БД с паролем, переданным в пользовательском конфигурационном файле#

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

"{{ control_name }}.FAIL__Пароль от суперпользователя postgres в пользовательском конфигурационном файле не совпадает с текущим паролем в БД. Скорректируйте значение параметра 'postgres_db_pass' в пользовательском конфигурационном файле '{}' и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка корректного расположения утилиты secret_storage_client#

Для осуществления проверки готовности защищенного хранилища VAULT к последующему обновлению, скрипты используют утилиту secret_storage_client, которая входит в состав дистрибутива.

Утилита расположена в папке utilities/secret_storage_client_bundle/bin/. При отсутствии утилиты будет выведено предупреждающее сообщение (процесс работы скриптов при этом не останавливается).

В случае если утилита не обнаружена, будет получено предупреждение:

"{{ control_name }}.WARNING__Утилита secret_storage_client не обнаружена. Проверки готовности защищенного хранилища VAULT к обновлению будут пропущены.__{{ control_name }}.WARNING"

Проверка наличия конфигурационного файла VAULT#

При отсутствии файла будет выведено сообщение:

"{{ control_name }}.FAIL__В кандидате на обновление не был обнаружен конфигурационный файл VAULT '{}'. Произведите проверку состояния стенда на предмет подключения к защищенному хранилищу VAULT и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка наличия успешного подключения к защищенному хранилищу VAULT#

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

"{{ control_name }}.FAIL__Не удалось обнаружить ни одного успешного подключения к защищенному(ым) хранилищу(ам) VAULT. Возникли следующие ошибки: {}. Произведите проверку состояния стенда на предмет подключения к защищенному хранилищу VAULT и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Получение общего списка параметров из защищенного хранилища VAULT#

В случае возникновения ошибок будет получено сообщение вида:

"{{ control_name }}.FAIL__В процессе получения списка параметров из защищенного хранилища VAULT возникли ошибки: '{}'. Причиной может быть отсутствие конфигурационного файла '{}' с параметрами подключения к защищенному хранилищу VAULT. Произведите проверку состояние подключения к VAULT серверу(ам) и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка корректного значения для параметра secure_config на защищенном хранилище VAULT#

Если состояние стенда показало, что защита конфигурации включена, ожидается значение on:

"{{ control_name }}.FAIL__Значение параметра secure_config на защищенном хранилище VAULT не соответствует полученным данным о состоянии стенда. При включенной защите параметров конфигурации значение для параметра secure_config должно быть 'on' на защищенном хранилище VAULT. Произведите проверку состояние стенда на наличие подключенных СЗИ и корректность сконфигурированного id на сервере VAULT. После повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

В случае отключенной защиты конфигурации значение параметра secure_config будет off:

"{{ control_name }}.FAIL__Значение параметра secure_config на защищенном хранилище VAULT не соответствует полученным данным о состоянии стенда. При выключенной защите параметров конфигурации значение для параметра secure_config должно быть 'off' на защищенном хранилище VAULT. Произведите проверку состояние стенда на наличие подключенных СЗИ и корректность сконфигурированного id на сервере VAULT. После повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка корректного значения для параметра is_tde_on на защищенном хранилище VAULT#

В случае, когда состояние стенда показало включенное TDE, ожидается значение on/true:

"{{ control_name }}.FAIL__Значение параметра is_tde_on на защищенном хранилище VAULT не соответствует полученным данным о состоянии стенда. При включенном прозрачном шифровании (TDE) значение для параметра is_tde_on должно быть 'on' на защищенном хранилище VAULT. Произведите проверку состояние стенда на наличие подключенных СЗИ и корректность сконфигурированного id на сервере VAULT. После повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

В случае, если TDE выключено, значение параметра is_tde_on будет соответствовать off/false:

"{{ control_name }}.FAIL__Значение параметра is_tde_on на защищенном хранилище VAULT не соответствует полученным данным о состоянии стенда. При выключенном прозрачном шифровании (TDE) значение для параметра is_tde_on должно быть 'off' на защищенном хранилище VAULT. Произведите проверку состояние стенда на наличие подключенных СЗИ и корректность сконфигурированного id на сервере VAULT. После повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка идентичности значений pg_ident на защищенном хранилище VAULT и в локальном конфигурационном файле#

В случае ошибки будет получено сообщение вида:

"{{ control_name }}.FAIL__Значение параметра pg_ident на защищенном хранилище VAULT должно соответствовать значению в локальном конфигурационном файле '{}/pg_ident.conf'. Произведите проверку на предмет корректно сконфигурированного id на сервере VAULT и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Проверка состояния параметра KillUserProcesses в файле /etc/systemd/logind.conf#

Если параметр KillUserProcesses в файле /etc/systemd/logind.conf находится в положении yes, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__На хосте host_name в файле /etc/systemd/logind.conf включен параметр KillUserProcesses=yes, для дальнейшей работы требуется переключить данный параметр в положение KillUserProcesses=no и перезапустить хост.__{{ control_name }}.FAIL

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

Скрипт проверки осуществляет проверку предыдущих обновлений и фиксирует неудачные попытки. Если предыдущие попытки обновления были неуспешными, либо, если при неудачном обновлении был некорректно произведен автоматический откат, то скрипт прервется и создаст файл /home/postgres/.update_pgse/update_disallowed. Пользователю выведется сообщение:

{{ control_name }}.FAIL__Зафиксирована неудачная попытка обновления версии СУБД Pangolin. Перед повторным запуском сценария обновления, необходимо полностью восстановить состояние кластера предыдущей/исходной версии СУБД Pangolin. Обратитесь к администраторам БД__{{ control_name }}.FAIL

В этом случае необходимо вручную откатить стенд на исходное состояние (см. раздел «Откат»), удалить файл /home/postgres/.update_pgse/update_disallowed, а затем перезапустить разведку.

Проверка включения полного внутреннего резервного копирования данных#

Проверяется значение параметра is_inner_full_backup. Если параметр имеет значение false, то выводится информационное сообщение:

{{ control_name }}.INFO__За процедуру резервного копирования данных, на случай непредвиденных ошибок в процессе обновления, отвечает отдельная от Механизма обновления служба.__{{ control_name }}.INFO

Затем производится проверка необходимых linux-пакетов и, в случае отсутствия, их установка, подготовка виртуального окружения python, определение текущего active и standby.

Проверка, что переданный адрес active соответствует действительности#

В случае, если мастер не соответствует переданному в конфигурации hosts.ini, скрипт прервется с ошибкой:

{{ control_name }}.FAIL__В кандидате на обновление текущий active в СУБД не соответствует значению, полученному на вход. На текущий момент обновление невозможно, необходимо выполнить switchover__{{ control_name }}.FAIL

Выполнение роли (checkup/prepare_update.yml) перед обновлением#

Роль получает текущее значение переменных, таких как:

• pg_current_version;

• PGDATA_OLD;

• PGHOME_OLD;

• PGPORT_OLD;

• PGBOUNCERPORT_OLD;

• CLNAME_OLD;

• PGHOME_OLD_NAME.

Получение состояний компонентов для определения типа установленной конфигурации#

Если нет имени кластера, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Укажите актуальное имя кластера в .bash_profile в параметре '- export CLNAME= '__{{ control_name }}.FAIL

Если файлы сертификатов отсутствуют, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Файл сертификата {{ item }} не найден__{{ control_name }}.FAIL

Примечание:

Скрипты обновления не осуществляют проверку валидности сертификатов.

Проверка соответствия установленных компонентов кластера с текущим типом конфигурации#

Если не соответствует, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Текущий тип конфигурации согласно конфигурационному параметру СУБД {type_configuration}, при этом обнаружены несоответствующие конфигурации компоненты: {component}. Для продолжения обновления требуется удалить несоответствующие компоненты.__{{ control_name }}.FAIL

Проверка минимальной поддерживаемой версии Postgres SE, над которой может быть выполнен сценарий разведки/обновления#

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

{{ control_name }}.FAIL__Обновление невозможно. Текущая версия (pg_current_version) не поддерживается. Минимальная поддерживаемая версия: min_actual_pangolin_ver__{{ control_name }}.FAIL

Матрица поддерживаемых версий:

list_versions_to_update: [ "4.6.1", "4.6.2", "4.6.3", "4.6.4", "4.6.5", "4.6.6", "4.6.7", "5.2.0", "5.2.1", "5.2.2", "5.2.3", "5.2.4", "5.2.5", "5.2.6", "5.3.0", "5.3.2", "5.3.3", "5.4.0", "5.4.1", "5.4.3", "5.5.0", "5.5.1", "5.5.2", "5.5.3", "5.5.4", "6.1.0", "6.1.1", "6.1.2", "6.1.4", "6.1.5" ]

update_version_matrix: {
"table": [
{ "to": "6.2.0", "from": [ "6.1.0", "6.1.1", "6.1.2", "6.1.4", "6.1.5" ], configure_ist: true, "update_type": "update_minor", "pg_upgrade_mode": "not defined" },
{ "to": "6.2.0", "from": [ "6.1.0", "6.1.1", "6.1.2", "6.1.4", "6.1.5" ], configure_ist: false, "update_type": "update_minor", "pg_upgrade_mode": "not defined" },
{ "to": "6.2.0", "from": [ "5.4.0", "5.4.1", "5.4.3", "5.5.0", "5.5.1", "5.5.2", "5.5.3", "5.5.4" ], configure_ist: true, "update_type": "update_major", "pg_upgrade_mode": "hardlink" },
{ "to": "6.2.0", "from": [ "4.6.1", "4.6.2", "4.6.3", "4.6.4", "4.6.5", "4.6.6", "4.6.7", "5.2.0", "5.2.1", "5.2.2", "5.2.3", "5.2.4", "5.2.5", "5.2.6", "5.3.0", "5.3.2", "5.3.3", "5.4.0", "5.4.1", "5.4.3", "5.5.0", "5.5.1", "5.5.2", "5.5.3", "5.5.4" ], configure_ist: false, "update_type": "update_major", "pg_upgrade_mode": "hardlink" },
{ "to": "6.2.0", "from": [ "4.6.1", "4.6.2", "4.6.3", "4.6.4", "4.6.5", "4.6.6", "4.6.7", "5.2.0", "5.2.1", "5.2.2", "5.2.3", "5.2.4", "5.2.5", "5.2.6", "5.3.0", "5.3.2", "5.3.3" ], configure_ist: true, "update_type": "unsupported", "pg_upgrade_mode": "not defined" }
]
}

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

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

{{ control_name }}.FAIL__Тип установленной конфигурации: tag. Процесс обновления для данного типа недоступен. Предварительно необходимо привести тип конфигурации к одному из поддерживаемых типов (как за счет чистой установки новой СУБД, так и за счет ручного изменения типа конфигурации)__{{ control_name }}.FAIL

Не поддерживаемые версии описаны в custom_file_template.yml в параметре not_support_type_installed_configuration:

not_support_type_installed_configuration: ['standalone-postgresql-only']

Определение типа обновления#

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

Алгоритм действий проверки. На текущей СУБД запрашивается информация:

• текущая версия;

• включена или нет функциональность «прозрачное шифрование данных (TDE)»;

• включена или нет функциональность «защита от привилегированных пользователей (AP)»;

Если тип обновления равен unsupported для текущей версии, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Обновление невозможно. При включенной функциональности защиты от привилегированных пользователей (AP) обновление в автоматическом режиме не поддерживается для версии (pg_current_version). Обратитесь к администраторам СУБД для осуществления обновления вручную.__{{ control_name }}.FAIL

Если успешно получены параметры для определения типа обновления(update_complexity_level) из таблицы соответствия для текущей версии, то происходит анализ данных параметров и выводится сообщение:

PANGOLIN.ARGS__{\"update_complexity_level\": \"update_complexity_level_2\"}__PANGOLIN.ARGS

Проверка свободного места#

Проверка свободного места в точке монтирования PGBACKUP (пример: /pgarclogs/04). Требуется минимум 1 Гб. Если места не хватает, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Точка монтирования {{ PGBACKUP }} имеет {{ pgdata_mp_free }} Гб свободного пространства, но требуется не менее 1 Гб.__{{ control_name }}.FAIL

• Для типов update_complexity_level_2/update_complexity_level_3 выполняется проверка размера СУБД. Если размер СУБД больше чем задано в параметре maximum_dbms_size_to_update (параметр максимальный размер СУБД для обновления в настраиваемом конфигурационном файле), то выводится блокирующая дальнейшее выполнение сценария ошибка:

  {{ control_name }}.FAIL__Автоматическое обновление ограничено размером кластера СУБД в maximum_dbms_size_to_update Гб. Текущая СУБД имеет размер current_dbms_size Гб.__{{ control_name }}.FAIL
  

• Для типов update_complexity_level_2/update_complexity_level_3 и полного внутреннего резервного копирования данных проверяется наличие на active каталога local_backup_path (путь для локального резервного копирования), задающийся в настраиваемом конфигурационном файле или переданным на вход скрипта в виде extra vars. Если отсутствует, то выводится блокирующая дальнейшее выполнение сценария ошибка:

  {{ control_name }}.FAIL__Не найден каталог /pgarclogs, указанный в параметре local_backup_path.__{{ control_name }}.FAIL
  

Проверка свободного места для точки монтирования local_backup_path#

Проверка наличия свободного места для осуществления резервного копирования в директорию local_backup_path (отображается в логе как «локальный backup») складывается из следующих параметров:

• Размер кластера СУБД (текущего каталога pgdata).

• Вычисляется процент от размера кластера СУБД. Процент задается в параметре local_backup_coefficient в настраиваемом конфигурационном файле (по умолчанию равен 1%).

• 1 Гб, если точка монтирования local_backup_path совпала с точкой монтирования для PGBACKUP.

Если в точке монтирования для local_backup_path не хватает места, то выводится ошибка:

{{ control_name }}.SPACE.FAIL__Не достаточно свободного места для локальной резервной копии в local_backup_path_folder. Доступно local_backup_path_free_mb Мб. Требуется >= local_size_backup_mb Мб.__{{ control_name }}.SPACE.FAIL

Проверка точек монтирования#

Производится проверка прав для записи в каталоги, которые могут быть точками монтирования - PGDATA, PGBACKUP и PGLOGS.

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

"FAIL__Инсталлятор не может записать файлы в директорию dir. Проверьте маску директории или назначьте владельца postgres.__FAIL"

Проверка расположения виртуальных сред#

При проверке расположения заранее подготовленных виртуальных сред, в случае их расположения в директории $PGHOME/postgresql_venv, выводится ошибка:

"{{ control_name }}.FAIL__В конфигурационном файле обнаружен недопустимый путь до {} данный путь не должен совпадать с корневым путем установки {} {}. Для продолжения установки/обновления требуется скорректировать данный путь в конфигурационном файле.__{{ control_name }}.FAIL"

Проверка консистентности виртуальных сред#

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

"INFO_Директория указанная в конфигурационном файле {} пуста или в ней отсутствуют пакеты для дальнейшей установки/обновления. Для дальнейшего процесса установки/обновления будет создано виртуальное окружение автоматически_INFO"

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

Проверка типа файловой системы для каталогов текущая PGDATA, новая PGDATA, PGBACKUP, local_backup_path#

Проверка в скрипте выполняется для типа обновления update_complexity_level_2/update_complexity_level_3.

Для каталогов запрашивается тип файловой системы. Список каталогов:

текущая pgdata (пример: /pgdata/04/data)
новая pgdata (пример:/pgdata/05/data)
pgbackup (пример: /pgarclogs/04)
local_backup_path (пример: /pgarclogs)

Для типов обновления update_complexity_level_2/update_complexity_level_3 типы файловой системы для каталогов должны совпадать. Если типы файловой системы не равны, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Для продолжения обновления необходимо, чтобы директории с текущей pgdata, новой pgdata, pgbackup и local_backup_path находились в одной файловой системе. Тип файловой системы: текущая pgdata: pgdata_old_file_system_type, новая pgdata: pgdata_file_system_type, pgbackup: pgbackup_file_system_type, local_backup_path: local_backup_path_file_system_type.__{{ control_name }}.FAIL

Проверка наличия библиотеки cracklib#

Осуществляется запрос проверки наличия библиотеки и словарей в каталоге PGHOME.

Список необходимых файлов:

libcrack.so
pw_dict.hwm
pw_dict.pwd
pw_dict.pwi

Если хотя бы один файл отсутствует, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Библиотека cracklib не найдена. Обратитесь к администраторам СУБД за решением__{{ control_name }}.FAIL

Если соединение с БД не установлено, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Не удалось осуществить тестовое соединение к БД на {{ inventory_hostname }}. Обратитесь к администраторам СУБД за помощью__{{ control_name }}.FAIL

Проверка использования KMS-заменителя#

Обновление стендов с включенным КМС-заменителем произвести будет невозможно. В скриптах разведчика организована проверка на случай таких стендов. Сообщение скрипта-разведчика будет выглядеть следующим образом:

{{ control_name }}.FAIL__На стенде обнаружено использования VAULT заменителя. Произвести обновление будет невозможно.__{{ control_name }}.FAIL

Проверка структуры каталогов PGDATA#

Скрипт запрашивает структуру каталогов на active и standby для кластерной конфигурации. Если структура каталогов отличается, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Разная структура каталогов в каталоге pgdata на серверах. Обратитесь к администраторам БД для анализа проблемы. Со структурой можно ознакомиться в логе задачи (имя таски: pgdata directory structure).__{{ control_name }}.FAIL

Проверка символических ссылок в PGDATA#

Скрипт запрашивает на active и standby список всех символических ссылок в каталоге PGDATA и определяет куда они направлены. Если символические ссылки отличаются, то выводится блокирующая дальнейшее выполнение сценария ошибка:

{{ control_name }}.FAIL__Отличаются символические ссылки в каталоге pgdata на серверах. Обратитесь к администраторам БД для анализа проблемы. Со списком символических ссылок можно ознакомиться в логе задачи (имя таски: symlinks in pgdata).__{{ control_name }}.FAIL

При обработке ошибки необходимо перейти в лог выполнения задачи и поиском найти задачу symlinks in pgdata. В задаче распечатана информация для анализа различий.

Проверка установленных расширений с поддерживаемыми расширениями#

Под пользователем postgres выполняется запрос к БД:

SELECT format('{{ item.datname }}.%1$s.%2$s',nspname,extname) extname FROM pg_catalog.pg_extension ex
JOIN pg_namespace ns ON ex.extnamespace =ns.oid
WHERE ex.extname not in ({{ legal_extensions.third_party }}, {{ legal_extensions.contrib }});

В запросе происходит сравнение установленных расширений с поддерживаемыми.

legal_extensions:
  third_party: "'pg_profile', 'orafce', 'postgis', 'pgrouting', 'pg_squeeze', 'pg_cron', 'pg_pathman', 'pg_repack', 'pgse_backup', 'pg_hint_plan', \
                'pg_outline', 'oracle_fdw', 'tds_fdw', 'psql_lockmon', 'pg_stat_kcache', 'psql_rotate_password', 'fasttrun', 'fulleq', 'mchar', 'psql_diagpack', \
                'pg_store_plans', 'pg_orphaned', 'pg_background'"
  contrib: "'adminpack', 'amcheck', 'auth_delay', 'auto_explain', 'autoinc', 'bloom', 'btree_gin', 'btree_gist', 'citext', 'cube', 'dblink', 'dict_int', 'dict_xsyn', \
            'earthdistance', 'file_fdw', 'fuzzystrmatch', 'hstore', 'hstore_plperl', 'hstore_plperlu', 'hstore_plpython2u', 'hstore_plpython3u', 'hstore_plpythonu', \
            'insert_username', 'intagg', 'intarray', 'isn', 'jsonb_plperl', 'jsonb_plperlu', 'jsonb_plpython2u', 'jsonb_plpython3u', 'jsonb_plpythonu', 'lo', 'ltree', \
            'ltree_plpython2u', 'ltree_plpython3u', 'ltree_plpythonu', 'moddatetime', 'pageinspect', 'pg_buffercache', 'pg_freespacemap', 'pg_prewarm', 'pg_stat_statements', \
            'pg_trgm', 'pg_visibility', 'pgcrypto', 'pgrowlocks', 'pgstattuple', 'plperl', 'plperlu', 'plpgsql', 'plpython2u', 'plpythonu', 'pltcl', 'pltclu', 'postgres_fdw', \
            'refint', 'seg', 'sslinfo', 'tablefunc', 'tcn', 'timetravel', 'tsm_system_rows', 'tsm_system_time', 'unaccent', 'uuid-ossp', 'xml2', 'bool_plperlu', 'bool_plperl'"

Для обновления с типом update_complexity_level_1 в поддерживаемые добавляется расширение: timescaledb. Если список не пустой, то для типа обновления update_complexity_level_1 выводится предупреждающее сообщение:

{{ control_name }}.WARNING__Текущая версия СУБД содержит следующие расширения, не входящие в состав Pangolin (<имя базы>.<имя схемы>.<имя расширения>): extension_name. Для дальнейшей работы данных расширений необходимо после обновления проверить их работоспособность.__{{ control_name }}.WARNING

Если список не пустой, то для типа обновления update_complexity_level_2/update_complexity_level_3 выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Текущая версия СУБД содержит следующие расширения, не входящие в состав Pangolin или для данных расширений обновление не поддерживается (<имя базы>.<имя схемы>.<имя расширения>): extension_name.__{{ control_name }}.FAIL

Проверка портов по умолчанию в БД, Pangolin Pooler#

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

netstat -tulpn 2>/dev/null | grep -E "postgres|pgbouncer" | awk '{print $4}' | awk -F ":" '{print $2}'

Если вывод отличается от значений портов в конфигурации, то будут показаны предупреждения:

{{ control_name }}.WARNING__В кандидате на обновление обнаружено использование старого порта > PGPORT = pgport_old, нерекомендуемого безопасностью.__{{ control_name }}.WARNING

{{ control_name }}.WARNING__В кандидате на обновление обнаружено использование старого Pangolin Pooler > порта pgbouncerport_old, нерекомендуемого \безопасностью.__{{ control_name }}.WARNING

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

Под пользователем postgres выполняется скрипт:

SELECT usename
FROM pg_user
WHERE usesysid != all
((SELECT grolist FROM pg_group WHERE groname = 'as_admin') ||
(SELECT grolist FROM pg_group WHERE groname = 'db_admin') ||
(SELECT grolist FROM pg_group WHERE groname = 'as_TUZ') ||
(SELECT grolist FROM pg_group WHERE groname = 'pg_read_all_settings') ||
(SELECT grolist FROM pg_group WHERE groname = 'as_admin_read') ||
(SELECT grolist FROM pg_group WHERE groname = 'all-sa-pam-group'))
AND usename NOT IN ('backup_user', 'postgres', 'auditor', 'pgbouncer', 'pstgcmdb',
'masteromni', 'patroni', 'cron', 'profile_tuz', 'sec_admin_backup', 'sec_admin')

Если скрипт вернет не пустое значение (список пользователей), то выводится предупреждение:

{{ control_name }}.WARNING__Пользователь {{ list_wrong_users | join(', ') }} не соответствует ролевой модели. Его настройка произведена не будет__{{ control_name }}.WARNING

Проверка, что в СРК используется УЗ backup_user (только для промышленной эксплуатации)#

Проверяется наличие скрипта manage_backup.sh и, если он отсутствует, то выводится блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Файл manage_backup.sh не существует. Обратитесь к администраторам БД__{{ control_name }}.FAIL

В случае, если на ПРОМ-стенде в инструменте резервного копирования обнаружено использование другой УЗ, то выводится блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Техническая учетная запись backup_user не используется в процессе резервного копирования. Обратитесь к администраторам БД__{{ control_name }}.FAIL

Проверка статуса состояния снятия РК (только для промышленной эксплуатации)#

Проверяется статус снятия РК через представление backup.history. При получении значений статуса, отличного от failed, complited или waiting_from_wal_backup, будет выведена ошибка, блокирующая выполнение сценария:

{{ control_name }}.FAIL__На текущий момент обновление невозможно так как активна сессия снятия РК. Дождитесь окончания снятия РК со стенда__{{ control_name }}.FAIL

Если установлен confd, то выводится предупреждающее сообщение:

{{ control_name }}.WARNING__В случае использования конфигурации СУБД cluster-patroni-etcd-pgbouncer (версии СУБД Pangolin до 5.1.0) \
при обновлении СУБД Pangolin версии 5.2.0, утилита confd будет автоматически удалена. Поэтому до обновления необходимо изменить строку подключения \
к СУБД (проверить значения портов) и убедиться что в строке указаны оба узла кластера (active и standby). Например, если раньше было \
«jdbc:postgresql://127.0.0.1:6544,127.0.0.2:6544/dbname?prepareThreshold=0», то необходимо исправить на «jdbc:postgresql://127.0.0.1\
:6544,127.0.0.2:6544/dbname?targetServerType=master&prepareThreshold=0»__{{ control_name }}.WARNING

Вывод информационного сообщения с набором действий, которые необходимо произвести после завершения процесса обновления СУБД#

{{ control_name }}.TODO.AFTER__Набор действий, необходимых произвести ПОСЛЕ завершения процесса обновления СУБД:

1) Необходимо учесть, что файл recovery.conf более не используются в логике работы СУБД (для кластерной конфигурации).
2) В работе автоматизированной системы необходимо учесть, что была расширена информация о клиентских сертификатах SSL в представлении pg_stat_ssl и колонка clientdn была переименована в client_dn.
3) В работе автоматизированной системы необходимо учесть, что были изменены параметры хранения и ротации WAL-файлов, параметр wal_keep_segments был объявлен устаревшим, поэтому необходимо перейти на использование параметра wal_keep_size.
4) Обращаем внимание, что начиная с версии СУБД Pangolin 5.1.0 введено понятие TRUSTED EXTENSIONS, таким образом определенные расширения (список таких расширений можно получить с помощью запроса SELECT DISTINCT name FROM pg_available_extension_versions WHERE TRUSTED ORDER BY name;) в дальнейшем могут быть созданы пользователями с правами CREATE (пользователи входящие в as_admin группу) на уровне базы данных.
5) В работе автоматизированной системы необходимо учесть, что в новой версии СУБД Pangolin могли быть изменены некоторые вендорские процедуры, а именно, мог измениться состав или порядок аргументов для них (например, функции sec_admin, в которых убран аргумент current_database).
Рекомендация: перед началом обновления версии СУБД необходимо внимательно изучить release notes новой версии.__{{ control_name }}.TODO.AFTER

Вывод информационного сообщения для типа обновления update_complexity_level_3#

Если тип обновления update_complexity_level_3, то выводится информационное сообщение:

{{ control_name }}.INFO__Для миграции данных БД используется специальная утилита pg_upgrade. В ходе миграции данные в новую версию БД будут перенесены в режиме копирования, что повлечет дополнительное увеличение времени обновления СУБД.__{{ control_name }}.INFO

Вывод информационного сообщения о недоступности СУБД#

{{ control_name }}.INFO__На время выполнения обновления база данных будет недоступна. Просим вас это учесть при проведении работ.__{{ control_name }}.INFO

Проверка не поддерживаемых типов данных#

Выполняется запрос к БД:

SELECT format('%1$s.%2$s(%3$s)',ns.nspname,cl.relname,att.attname) tbl_fld
FROM pg_attribute att
JOIN pg_type tp ON att.atttypid =tp.oid
JOIN pg_class cl ON att.attrelid =cl.oid
JOIN pg_namespace ns ON cl.relnamespace = ns.oid
WHERE tp.typname IN ('abstime','reltime','tinterval') AND NOT (ns.nspname SIMILAR TO '(pg_|information_schema)%');

Если результат запроса не пустой, то выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Удалена поддержка типов данных abstime, reltime, tinterval. Список таблиц, использующих их (<имя схемы>.<имя таблицы>(<имя колонки>)): table_name__{{ control_name }}.FAIL

Проверка массива типов из information_schema#

Выполняется запрос к БД:

SELECT format('%1$s.%2$s(%3$s)',ns.nspname,cl.relname,att.attname) tbl_fld
FROM pg_attribute att
JOIN pg_type tp ON att.atttypid =tp.oid
JOIN pg_class cl ON att.attrelid =cl.oid
JOIN pg_namespace ns ON cl.relnamespace = ns.oid
WHERE tp.typname IN ('cardinal_number','character_data','sql_identifier','time_stamp','yes_or_no') AND NOT (ns.nspname SIMILAR TO '(pg_|information_schema)%');

Если результат запроса не пустой, то выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Не поддерживаются массивы типов из information_schema. Список таблиц, использующих их (<имя схемы>.<имя таблицы>(<имя колонки>)): table_name__{{ control_name }}.FAIL

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

Выполняется запрос к БД:

WITH RECURSIVE src AS (
SELECT
pc.relnamespace::regnamespace,
pa.attrelid::regclass,
pa.attname,
pa.atttypid::regtype,
pc.relkind
FROM pg_catalog.pg_attribute pa
JOIN pg_catalog.pg_class pc ON pa.attrelid = pc.oid
WHERE
pa.atttypid::regtype::text IN ('xid','xid[]') AND
pa.attnum > 0 AND
pc.relkind != 'v'
UNION ALL
SELECT
pc.relnamespace::regnamespace,
pa.attrelid::regclass,
pa.attname,
pa.atttypid::regtype,
pc.relkind
FROM pg_catalog.pg_attribute pa
JOIN pg_catalog.pg_class pc ON pa.attrelid = pc.oid
JOIN pg_catalog.pg_type pt ON pt.oid = pa.atttypid
JOIN src ON pt.typrelid = src.attrelid
WHERE
pa.attnum > 0 AND
pc.relkind != 'v'
)
SELECT format('%1$s(%2$s)',attrelid,attname) tbl_xid
FROM src 
WHERE relnamespace::regnamespace::text !~ '^(information_schema|pg_)';

Если результат запроса не пустой, то выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Обнаружена(ы) таблица(ы) в которой(ых) присутствует(ют) поле(я) с типом xid. В новой версии СУБД Pangolin применяется 64-битный счетчик транзакций. Необходимо удалить поле(я) с типом xid в таблице(ах). Список таблиц, использующих их (<имя таблицы>(<имя колонки>)): table_name__{{ control_name }}.FAIL

Проверка наличия установленного RPM-пакета Pangolin на серверах#

Производится проверка установленного RPM-пакета Pangolin с новой версией, если пакет обнаружен, то выводится блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Найден установленный пакет package_name с версией на которую планируем обновляться. Обновление не может быть продолжено. Просьба удалить пакет и повторить попытку снова.__{{ control_name }}.FAIL

Удаление каталога для временных файлов#

{{ local_backup_path }}/scout_temp_data

Проверка наличия каталога для временных файлов#

{{ local_backup_path }}/scout_temp_data`

Проверка с помощью утилиты pg_upgrade#

Проверка возможности обновления с помощью утилиты pg_upgrade check.

Если проверка завершается с ошибкой, то выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Не прошла одна из проверок pg_upgrade. Обратитесь к администраторам БД для анализа проблемы. \С ошибками можно ознакомиться в логе задачи (имя таски: journal pg_upgrade).__{{ control_name }}.FAIL

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

Проверка с помощью утилиты pg_dumpall#

Проверка осуществляется с помощью утилиты pg_dumpall --schema-only --no-tablespaces --no-privileges.

Проверка заключается в снятии дампа схемы на текущей БД и загрузка схемы в экземпляр основанный на новой версии

Во время выполнения будут выведены ошибки:

Если во время старта СУБД произошла неожиданная ошибка, то выводится блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Произошла неожиданная ошибка во время старта СУБД для проверки загрузки схемы данных. Обратитесь к администраторам БД для анализа проблемы. Список ошибок: list_errors.__{{ control_name }}.FAIL

Если во время загрузки схемы данных произошла неожиданная ошибка, то выводится блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Произошла неожиданная ошибка во время проверки загрузки схемы данных. Обратитесь к администраторам БД для анализа проблемы. Список ошибок: list_errors.__{{ control_name }}.FAIL

Если во время загрузки схемы данных происходит понятная ошибка, то выводится не блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__Найдены ошибки во время проверки загрузки схемы данных. Обратитесь к администраторам БД для анализа проблемы. Ссылка на схему данных в папке с логами: (ansible_fqdn)pg_scout_log_link/currentdb.sql. Список ошибок: list_errors. Если после анализа выявлено, что ошибка ложно положительная, то необходимо добавить эту ошибку в фильтр в переменную false_error_filter_for_data_schema настраиваемого конфигурационного файла.__{{ control_name }}.FAIL

Проверка минимальной конфигурации ЦПУ и ОЗУ на обновляемых стендах#

Проверка осуществляется путем сбора системных параметров стенда и сравнения с минимальными значениями, указанными в файле конфигурации custom_file_template.yml. Если проверка обнаружила несоответствие минимальным требованиям, будет выдана ошибка:

{{ control_name }}.FAIL__Хост {host_name} не соответствует минимальным требования по CPU. Минимальное значение {count_cpu}.__{{ control_name }}.FAIL
{{ control_name }}.FAIL__Хост {host_name} не соответствует минимальным требования по RAM. Минимальное значение {count_ram}.__{{ control_name }}.FAIL

Проверка наличия установленных пакетов Pangolin разной версии#

Происходит проверка наличия установленных пакетов platform-v-pangolin и postgresql-sber-edition, если они оба установлены, то будет выведено сообщение:

"{{ control_name }}.FAIL__На стенде установлено 2 разных пакета Pangolin - platform-v-pangolin и postgresql-sber-edition. Необходимо удалить неактуальный пакет__.{{ control_name }}.FAIL"

Проверка существования файлов блокирующих обновление#

Если во время повторного запуска обновления, были найдены файлы блокирующие обновление (disallow_update или .trigger_stop_update), то в зависимости от установленного рычага remove_block_update_tmp_files в конфигурационном файле они будут удалены. После удаления будет выведено сообщение об удалении данных файлов:

{{ control_name }}.INFO__Был найден и удален триггер прерывания обновления.__{{ control_name }}.INFO
{{ control_name }}.INFO__Был найден и удален файл предыдущего неудачного обновления.__{{ control_name }}.INFO

Проверка наличия логической репликации#

Происходит проверка наличия логической репликации в СУБД. Если она будет найдена, то будет выведено сообщение:

"{{ control_name }}.FAIL__На стенде {} обнаружено использование логической репликации, для продолжения обновления требуется удалить слот(ы) логической репликации: {}.__{{ control_name }}.FAIL"

Вывод информационного сообщения estimation_update_execution_time#

При успешном прохождении выше описанных проверок и наличия не пустого значения параметра estimation_update_execution_time в настраиваемом конфигурационном файле выводится информационное сообщение:

{{ control_name }}.INFO__{{ estimation_update_execution_time }}__{{ control_name }}.INFO

Проверка успешного завершения сценария#

При успешном прохождении выше описанных проверок выведется сообщение

{{ control_name }}.OK__Разведка перед обновлением успешно выполнена.__{{ control_name }}.OK

Обработка неизвестной ошибки#

В случае появления неожиданной ошибки, будет выводиться блокирующая выполнение сценария ошибка:

{{ control_name }}.FAIL__В процессе работы скрипта разведки произошла неожиданная ошибка. Обратитесь к администраторам БД для анализа проблемы.__{{ control_name }}.FAIL

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

Проверка установленного пакета СУБД Pangolin версии, на которую планируется обновление#

Если скриптом-разведчиком будет обнаружен установленный rpm-пакет СУБД Pangolin версии, на которую планируется обновление, то выводится ошибка:

"FAIL__На стенде установлен пакет Pangolin версии 05.005.00, на которую планируется обновление. Необходимо удалить данный пакет.__FAIL"

Проверка каталога исполняемых файлов в кластере СУБД Pangolin#

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

"FAIL__Зафиксировано несоответствие директории '/usr/pangolin-5.2.4', '/usr/pangolin-5.2.5' между узлами кластера. Необходимо произвести их корректировку.__FAIL"

Проверка наличия установленных расширений, которые не поддерживаются#

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

Если расширение установлено в базе данных, то будет выведена следующая ошибка:

FAIL__В кандидате на обновление обнаружены неподдерживаемые расширения. Для корректного обновления необходимо произвести удаление этих расширений (<имя БД>: <имя расширения>): {}: '{}'.FAIL

Если неподдерживаемое расширение находится в параметре shared_preload_libraries:

FAIL__В кандидате на обновление обнаружены неподдерживаемые расширения {} в параметре shared_preload_libraries.FAIL

Проверка наличия неподдерживаемых параметров в конфигурационном файле Pangolin#

Скрипт-разведчик выполняет проверку неподдерживаемых параметров в конфигурационном файле postgresql.conf, если такие параметры найдены, выводится ошибка:

FAIL__В кандидате на обновление обнаружены неподдерживаемые параметры {} в конфигурационном файле {}. Для корректного обновления необходимо произвести удаление этих параметров.FAIL

Проверка наличия неподдерживаемых значений параметра clientcert в правилах pg_hba#

Скрипт-разведчик выполняет поиск в файле pg_hba.conf неподдерживаемые значения для параметра clientcert, в случае обнаружения таких значение, выводится ошибка:

FAIL__В кандидате на обновление обнаружены неподдерживаемые параметры {} в правилах pg_hba. Для корректного обновления необходимо произвести удаление этих параметров.FAIL

Обновление Pangolin#

Внимание!

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

Чтобы выполнить обновление Pangolin:

1. Скачайте и распакуйте дистрибутив на сервере.

2. Перейдите в каталог с распакованным дистрибутивом, а затем в каталог installer.

3. Перед запуском обновления заполните файл hosts.ini в зависимости от установленного решения добавив информацию о хостах и учетных данных пользователя, которые будет использовать Ansible.

   Внимание!

   Данные должны содержать те же параметры, что и при установке. Примеры заполнения файлов описаны в разделе «Установка».

4. Заполните настраиваемый конфигурационный файл custom_file_sample.yml.

   Примечание:

   При обновлении в секции 3.1.HBA RULES не поддерживаются следующие параметры:

   • ldap_tls;

   • cert_dir;

   • openldap_config.

   Заполнять их нет необходимости.

5. Заполните конфигурационный файл all.yml.

6. Выполните ansible-сценарий.

   Ниже приведены шаблоны ansible-сценариев для обновления различных решений:

• Обновление односерверного решения:

  ansible-playbook playbook_updates.yaml \
  -i inventories/standalone/hosts.ini  \
  -t always,standalone \
  --ask-vault-pass \
  -vv \
  -e '{"update_complexity_level": "update_complexity_level_2"}' \
  --extra-vars "local_distr_path=${} \
  segment=${} \
  custom_config=${} \
  stand=${}"
  

• Обновление кластерного решения:

  ansible-playbook playbook_updates.yaml \
  -i inventories/cluster/hosts.ini  \
  -t always,cluster \
  --ask-vault-pass \
  -vv \
  -e '{"update_complexity_level": "update_complexity_level_2"}' \
  --extra-vars "local_distr_path=${} \
  segment=${} \
  custom_config=${} \
  stand=${}"
  

Описание параметров:

• custom_config - абсолютный путь к файлу конфигурации custom_config_sample.yml;

• local_distr_path - абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

• segment - сегмент сети;

• stand - стенд для тестирования или конечной инсталляции (dev или prom).

Значения используемых в команде запуска Ansible ключей:

• -i - путь к inventory-файлу;

• --extra-vars - переменные, которые по приоритету важнее переменных из inventory;

• -t - теги для запуска;

• -v - уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование.

После завершения обновления у пользователя postgres в его корневой директории будет сгенерирован файл с названием .process_work_statuses. В нем будет отображаться состояние корректности установленных обновлений. Ниже приведен пример данного файла с конфигурации продукта standalone-postgresql-pgbouncer:

Разведка перед обновлением СУБД Pangolin запущена, текущая конфигурация standalone-postgresql-pgbouncer , тип обновления update_major, режим обновления hardlink
Разведка перед обновлением СУБД Pangolin завершена, текущая конфигурация standalone-postgresql-pgbouncer , тип обновления update_major, режим обновления hardlink
Обновление СУБД Pangolin запущено, текущая конфигурация standalone-postgresql-pgbouncer , с версии 04.003.00 на версию 05.002.00, статус обновления: {u'aggregate': False, u'hosts': {u'replica': False, u'master': False, u'etcd': False}, u'components': {u'haproxy': False, u'pgbouncer': False, u'patroni': False, u'pg': False, u'etcd': False, u'configuration': False}, u'types': {u'etcd': {u'finally': False, u'main': False}, u'pg': {u'major_main_migrate_replica_db': False, u'remove_pgaudit': False, u'major_pre': False, u'major_post': False, u'bootstrap': False, u'role_switched': False, u'major_main_migrate_master_db': False, u'major_main_start_after_migrate_db': False, u'not_started_db': False, u'started_db': False}, u'patroni': {u'finally': False, u'main': False}}}, тип обновления update_major, режим обновления hardlink
Обновление СУБД Pangolin успешно завершено, текущая конфигурация standalone-postgresql-pgbouncer , с версии 04.003.00 на версию 05.002.00, статус обновления: {u'aggregate': False, u'hosts': {u'replica': False, u'master': False, u'etcd': False}, u'components': {u'haproxy': False, u'pgbouncer': False, u'patroni': False, u'pg': False, u'etcd': False, u'configuration': False}, u'types': {u'etcd': {u'finally': False, u'main': False}, u'pg': {u'major_main_migrate_replica_db': False, u'remove_pgaudit': False, u'major_pre': False, u'major_post': False, u'bootstrap': False, u'role_switched': False, u'major_main_migrate_master_db': False, u'major_main_start_after_migrate_db': False, u'not_started_db': False, u'started_db': False}, u'patroni': {u'finally': False, u'main': False}}}, тип обновления update_major, режим обновления hardlink

Обновление бинарных файлов#

Внимание! Скрипт обновления бинарных файлов pangolin_update_binary_script используется для применения исправлений и доработок в рамках одной мажорной версии.

Ручное обновление#

Чтобы выполнить обновление бинарных файлов Pangolin с использованием скрипта:

1. Убедитесь, что на стенде:

   • нет задержки репликации на узлах кластера Pangolin;

   • Pangolin работоспособный (есть доступ в базу данных);

   • отключен мониторинг (фоновых процессов и мониторинг статуса репликации) на время выполнения обновления бинарных файлов;

   • отсутствует активное резервное копирование.

2. Скачайте и распакуйте дистрибутив.

3. Из дистрибутива скопируйте rpm-файл файл platform-v-pangolin-<Версия Pangolin>-<Версия ОС>.rpm Pangolin на узлы кластера.

4. Проверьте наличие утилиты перешифрования в директории /etc/postgres на узлах Pangolin. Если файлы утилиты перешифрования есть, то скопируйте их из дистрибутива pg_auth_reencrypt в каталог /etc/postgres с правами root:root 755.

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

   sudo yum install platform-v-pangolin-dbms-<Версия Pangolin>-<Версия ОС>.rpm
   

6. Удалите старый каталог, затем создайте на него символьные ссылки:

   sudo rm -rf /usr/pangolin-5.5.0
   sudo ln -sf /usr/pangolin-6.2.0 /usr/pangolin-5.5.0
   

7. Выполните перезапуск Pangolin (restart) в зависимости от типа установки с помощью сервиса postgresql.service или patronictl.

8. Проверьте работоспособность Pangolin.

Автоматическое обновление#

Руководство по автоматическому обновлению бинарных файлов Pangolin:

1. Проверьте, что на стенде:

   • нет задержки репликации на узлах кластера Pangolin;

   • Pangolin работоспособный (есть доступ в базу данных);

   • отключен мониторинг (фоновых процессов и мониторинг статуса репликации) на время выполнения обновления бинарных файлов;

   • отсутствует активное резервное копирование.

2. Скачайте и распакуйте дистрибутив.

3. Скопируйте RPM-файл Pangolin и бинарный файл утилиты pg_auth_reencrypt в папку installer/scripts_external/pangolin_update_binary_script/roles/update_binary_script/files.

4. Настройте узлы в installer/scripts_external/pangolin_update_binary_script/inventories.

5. Ознакомьтесь с переменными по умолчанию в файле scripts_external/pangolin_update_binary_script/playbook_update_binary.yaml и при необходимости скорректируйте их:

    	- PG_PORT: 5433														#порт postgresql
        - REMOTE_TMP: /home/postgres/update_binary_cache_dir				#временная директория для хранения rpm на время выполнения скрипта 
        - RPM_NAME: platform-v-pangolin-dbms-<Версия Pangolin>-<Версия ОС>.rpm 	#имя rpm-файла
        - PGHOME: /usr/pangolin-5.5.2 										#расположение нового pghome
        - PGHOME_OLD: /usr/pangolin-5.5.0 								    #расположение старого pghome
        - patroni_conf_dir: /etc/patroni 									#расположение конфигурационных файлов patroni
        - clustername: clustername                               			#имя кластера
        - patronictl_path: /usr/patroni/patroni_venv/bin/patronictl 		#расположение patronictl
        - patroni_wait_seconds: 15 											#задержка после выполнения команд restart/switchover
        - LANG: en_US.UTF-8                                                 # язык интерфейса ОС
        - LC_ALL: en_US.UTF-8                                               # язык интерфейса ОС
   

6. Перейдите в каталог installer/scripts_external/pangolin_update_binary_script и запустите playbook:

• Обновление односерверного решения:

  ansible-playbook playbook_update_binary.yaml \ 
  -i inventories/standalone/hosts.ini -t standalone \ 
  --flush-cache -vv \
  --ssh-extra-args='-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' -vv
  

  • Обновление кластерного решения:

    ansible-playbook playbook_update_binary.yaml \ 
    -i inventories/cluster/hosts.ini -t cluster \ 
    --flush-cache -vv \
    --ssh-extra-args='-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' -vv
    

Проверки и информационные сообщения процесса обновления#

Проверка пароля через параметр postgres_db_pass#

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

FAIL__Пароль от суперпользователя postgres в пользовательском конфигурационном файле не совпадает с текущим паролем в БД. Скорректируйте значение параметра 'postgres_db_pass' в пользовательском конфигурационном файле.__FAIL

Проверка шифрования параметра postgres_db_pass#

Значение параметра postgres_db_pass не должно быть в виде scram-sha-256 или md5. Если пароль для УЗ postgres передан не в зашифрованном с помощью ansible-vault виде, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Пароль от суперпользователя postgres не должен быть задан в виде хэша 'SCRAM-SHA-256' или 'md5'.__FAIL"

В случае успешного прохождения проверки будет выведено:

"INFO__Проверка пароля от суперпользователя postgres завершилась успешно.__INFO"

Проверки для определения наличия СЗИ#

К проверкам для определения наличия СЗИ в процессе обновления относятся:

• проверка включенной защиты конфигурации (SHOW secure_config);

• проверка включенного TDE (SELECT check_tde_is_on());

• проверка включенной защиты от привилегированных пользователей (SELECT COUNT(1) FROM pg_catalog.pr_object WHERE datoid = 0 AND objoid = 0 AND objkind = 0).

Добавление новых параметров в локальный конфигурационный файл контролируется файлом diff.txt в скриптах развертывания/обновления. Данная доработка будет применяться к обновлению всех стендов независимо от наличия подключенных СЗИ; изменения коснулись только конфигурационных файлов СУБД (postgres.yml, postgresql.conf).

Пароль передается в момент инициализации, перед этим он переводится в хеш SCRAM-SHA-256. Строка запуска выглядит так:

# Установка
{{ PGHOME }}/bin/initdb -D {{ PGDATA }} -k -A scram-sha-256 --pwfile {{ postgres_pass }} --locale {{ locale }} --update-authid

# Обновление
{{ PGHOME }}/bin/initdb -D {{ PGDATA }} -k -A scram-sha-256 --pwfile {{ postgres_pass }} -E {{ old_postgres_encoding.query_result[0].server_encoding }} --update-authid --lc-collate {{ old_postgres_locale.settings.lc_collate.setting }} --lc-ctype {{ old_postgres_locale.settings.lc_ctype.setting }} --lc-messages {{ old_postgres_locale.settings.lc_messages.setting }} --lc-monetary {{ old_postgres_locale.settings.lc_monetary.setting }} --lc-numeric {{ old_postgres_locale.settings.lc_numeric.setting }} --lc-time {{ old_postgres_locale.settings.lc_time.setting }}

Примечание:

Значение параметра postgres_db_pass, отвечающего за проверку пароля, передаваемого в пользовательском конфигурационном файле, не должно быть в виде scram-sha-256 или md5.

Пароль суперпользователя (postgres) считывается в интерактивном режиме, а сам процесс миграции осуществляется с помощью SCRAM-SHA-256. Пароль будет считываться из параметра postgres_db_pass (старое название postgres_db_scram_pass) конфигурационного файла в зашифрованном ansible vault-виде.

Внимание!

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

Утилита secret_storage_client#

Утилита secret_storage_client служит для проверки наличия конфигурационных параметров СУБД Pangolin и их значений в хранилище секретов:

$ secret_storage_client -?
Usage:
  ./secret_storage_client <option>...
Options:
  --help             [-?]  this help
  --plugins-dir-path [-d]  path to directory containing plugins
  --plugin-log-level [-l]  plugin log level [DEBUG, LOG, INFO, NOTICE, WARNING (default), ERROR, FATAL, PANIC]
  --config                 use config file (/etc/postgres/enc_connection_settings.cfg) with settings
                           to connect to Secret storage [default]
  --interactive      [-i]  run in interactive mode
  --cluster          [-c]  cluster ID
  --host             [-h]  domain name or ip address of Secret storage
  --port             [-p]  secret storage server port
  --protocol               secret storage protocol [http (1), default: https (2)]
  --prefix           [-x]  secrets path prefix [default: kv]
  --suffix           [-s]  secrets path suffix [default: empty]
  --namespace        [-n]  secrets namespace [default: empty]
  --type             [-t]  auth type [userpass (1), approle (2)]
  --auth             [-a]  auth point [default: empty]
  --id               [-u]  login or role ID
  --root-ca          [-r]  file or folder with root certificate to check Secret storage server
  --skip-confirm     [-k]  input secret without confirmation

Pangolin product version information:
  --product_version        prints product name and version
  --product_build_info     prints product build number, date and hash
  --product_component_hash prints component hash string

The './secret_storage_client' utility is used to read secrets from Secret storage

Утилита поддерживает следующие варианты ввода параметров для подключения к хранилищу секретов:

• Чтение параметров из файла /etc/postgres/enc_connection_settings.cfg (аргумент --config). Данный способ используется, если файл предварительно был создан утилитой setup_kms_credentials.

• Интерактивный ввод параметров (аргумент --interactive).

• Если параметр отсутствует в аргументах, то будет запрошен ввод его значения. Ввод пароля или secretID осуществляется только интерактивно (аргумент --interactive).

Утилита возвращает список значений всех защищаемых конфигурационных параметров, поддерживаемых СУБД Pangolin, в формате:

имя параметра|||вариант защиты|||статус параметра|||значение:::имя параметра|||вариант защиты параметра|||статус параметра|||значение

В приведенном выше формате варианту защиты может соответствовать одно из значений:

• VST_ONLY_VAULT - параметру присваивается значение, полученное из хранилища секретов. В случае его отсутствия применяется значение по умолчанию для этого параметра;

• VST_STRICT_VAULT - для параметра допустимо применение значения, полученного только из хранилища секретов;

• VST_EITHER - параметру присваивается значение, полученное из хранилища секретов. В случае его отсутствия применяется значение из конфигурационного файла postgresql.conf;

• VST_BOTH - значение параметра в хранилище секретов должно совпадать со значением в конфигурационном файле postgresql.conf. В случае отсутствия параметра в одном из источников применяется значение по умолчанию для этого параметра.

Статус параметра может быть установлен как:

• present - присутствует в хранилище секретов;

• absent - отсутствует в хранилище секретов;

• null - присутствует в хранилище секретов, но значение не указано.

Ниже приведен пример:

secure_config|||VST_ONLY_VAULT|||present|||off:::password_encryption|||VST_ONLY_VAULT|||absent|||:::ssl|||VST_ONLY_VAULT|||present|||on:::allowed_servers|||VST_ONLY_VAULT|||absent|||:::ssl_ca_file|||VST_ONLY_VAULT|||absent|||:::ssl_ca_path|||VST_ONLY_VAULT|||absent|||:::ssl_cert_file|||VST_ONLY_VAULT|||absent|||:::ssl_crl_file|||VST_ONLY_VAULT|||absent|||:::ssl_crl_dir|||VST_ONLY_VAULT|||present|||/pg_ssl/crl/test/server:::ssl_key_file|||VST_ONLY_VAULT|||absent|||:::ssl_ciphers|||VST_ONLY_VAULT|||absent|||:::ssl_prefer_server_ciphers|||VST_ONLY_VAULT|||absent|||:::ssl_ecdh_curve|||VST_ONLY_VAULT|||absent|||:::ssl_dh_params_file|||VST_ONLY_VAULT|||absent|||:::ssl_passphrase_command|||VST_BOTH|||absent|||:::serverssl.pkcs12_config_path|||VST_ONLY_VAULT|||present|||/pg_ssl/server.p12.cfg:::pg_ident_conf|||VST_BOTH|||absent|||:::is_tde_on|||VST_ONLY_VAULT|||null|||:::password_policies_enable|||VST_ONLY_VAULT|||absent|||:::password_policy.deny_default|||VST_ONLY_VAULT|||absent|||:::password_policy.reuse_time|||VST_ONLY_VAULT|||absent|||:::password_policy.in_history|||VST_ONLY_VAULT|||absent|||:::password_policy.max_age|||VST_ONLY_VAULT|||absent|||:::password_policy.min_age|||VST_ONLY_VAULT|||absent|||:::password_policy.grace_login_limit|||VST_ONLY_VAULT|||absent|||:::password_policy.grace_login_time_limit|||VST_ONLY_VAULT|||absent|||:::password_policy.expire_warning|||VST_ONLY_VAULT|||absent|||:::password_policy.lockout|||VST_ONLY_VAULT|||absent|||:::password_policy.lockout_duration|||VST_ONLY_VAULT|||absent|||:::password_policy.max_failure|||VST_ONLY_VAULT|||absent|||:::password_policy.failure_count_interval|||VST_ONLY_VAULT|||absent|||:::password_policy.check_syntax|||VST_ONLY_VAULT|||absent|||:::password_policy.min_length|||VST_ONLY_VAULT|||absent|||:::password_policy.illegal_values|||VST_ONLY_VAULT|||absent|||:::password_policy.alpha_numeric|||VST_ONLY_VAULT|||absent|||:::password_policy.min_alpha_chars|||VST_ONLY_VAULT|||absent|||:::password_policy.min_special_chars|||VST_ONLY_VAULT|||absent|||:::password_policy.min_uppercase|||VST_ONLY_VAULT|||absent|||:::password_policy.min_lowercase|||VST_ONLY_VAULT|||absent|||:::password_policy.max_rpt_chars|||VST_ONLY_VAULT|||absent|||:::password_policy.track_login|||VST_ONLY_VAULT|||absent|||:::password_policy.max_inactivity|||VST_ONLY_VAULT|||absent|||:::password_policy.use_password_strength_estimator|||VST_ONLY_VAULT|||absent|||:::password_policy.password_strength_estimator_score|||VST_ONLY_VAULT|||absent|||:::password_policy.custom_function|||VST_ONLY_VAULT|||absent|||:::password_policy.allow_hashed_password|||VST_ONLY_VAULT|||absent|||:::psql_encrypt_password|||VST_ONLY_VAULT|||absent|||:::encrypt_new_tablespaces|||VST_ONLY_VAULT|||absent|||:::test_vst_both_restart_only|||VST_BOTH|||absent|||:::password_policy.transport_password_mark_automatic|||VST_ONLY_VAULT|||absent|||:::password_policy.transport_password_life_time|||VST_ONLY_VAULT|||absent|||:::performance_insights.masking|||VST_ONLY_VAULT|||absent|||:::masking_mode|||VST_ONLY_VAULT|||absent|||:::enabled_extra_auth_methods|||VST_ONLY_VAULT|||present|||trust,cert:::enabled_sec_admin_extra_auth_methods|||VST_ONLY_VAULT|||present|||trust