Обновление#

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

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

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

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

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

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

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

Примечание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Внимание!

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

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

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

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

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

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

• pgbouncer.ini (в случае наличия pgbouncer);

• pg_hba.conf;

• postgresql.conf.

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

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

Схема процесса обновления СУБД 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)%');
    

  • в процедурах проверьте, что язык Python 2.х не используется (рекомендуется: использовать Python 3.x):

    -- Должен вернуться список процедур на python2u,pythonu // запускать необходимо для КАЖДОЙ БД
    SELECT format('%1$s.%2$s',ns.nspname,pp.proname) pr_name
    FROM pg_proc pp
    JOIN pg_catalog.pg_language pl ON pp.prolang =pl.oid
    JOIN pg_namespace ns ON pp.pronamespace =ns.oid AND pl.lanname SIMILAR TO 'plpython2?u%';
    

Список необходимых действий после завершения процесса обновления СУБД 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).

  Примечание:

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

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

Примечание:

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

Действие	Команда	Тип значения	Примеры выполнения команды
Название продукта	SELECT version();	строковое значение	PostgreSQL 11.7 (PostgreSQL Sber Edition 4.1.0) on x86_64-apple-darwin19.4.0, compiled by Apple clang version 11.0.0 (clang-1100.0.33.17), 64-bit
Номер open-source версии	SHOW server_version;	строковое значение	11.7
	SHOW server_version_num;	числовое значение	110007
Номер Pangolin версии	SHOW server_se_version;	строковое значение	4.1.0
	SELECT sber_version();	строковое значение	4.1.0

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

Внимание!

В случае, если все пароли указывались в открытом виде, параметры --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=${} 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=${} \
     stand=${}"
     

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

     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=${} \
     stand=${}"
     

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

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

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

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

   • 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

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

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

{{ 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

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

RLM.FAIL__SSL настроен, но выключен в конфигурации БД. Возможно в кандидате на обновление уже был ранее настроен SSL. Для продолжения обновления необходимо удалить настройки БД, связанные с ssl и повторить запуск обновления.__RLM.FAIL

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

{{ control_name }}.FAIL__SSL не был настроен корректно. Возможно в кандидате на обновление уже был ранее настроен SSL. Для продолжения обновления необходимо удалить настройки БД, связанные с ssl и повторить запуск обновления.__{{ control_name }}.FAIL

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

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

Где item - 3 файла: ключ (например /home/postgres/ssl/client.key), сертификат (например /home/postgres/ssl/client.crt) и корневой сертификат (например /home/postgres/ssl/root.crt).

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

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

{{ 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", "5.2.0", "5.2.1", "5.3.0" ]

update_version_matrix: {
"table":[
{"to": "5.4.0", "from": ["4.6.1", "4.6.2", "4.6.3"], "admin_protection": false, "tde": false, "update_type": "update_major", "pg_upgrade_mode": "hardlink"},
{"to": "5.4.0", "from": ["4.6.1", "4.6.2", "4.6.3"], "admin_protection": false, "tde": true, "update_type": "unsupported", "pg_upgrade_mode": "not defined"},
{"to": "5.4.0", "from": ["4.6.1", "4.6.2", "4.6.3", "5.2.0", "5.2.1", "5.3.0"], "admin_protection": true, "tde": false, "update_type": "unsupported", "pg_upgrade_mode": "not defined"},
{"to": "5.4.0", "from": ["4.6.1", "4.6.2", "4.6.3", "5.2.0", "5.2.1", "5.3.0"], "admin_protection": true, "tde": true, "update_type": "unsupported", "pg_upgrade_mode": "not defined"},
{"to": "5.4.0", "from": ["5.2.0", "5.2.1", "5.3.0"], "admin_protection": false, "tde": false, "update_type": "update_minor", "pg_upgrade_mode": "not defined"},
{"to": "5.4.0", "from": ["5.2.0", "5.2.1", "5.3.0"], "admin_protection": false, "tde": true, "update_type": "update_minor", "pg_upgrade_mode": "not defined"}
]
}

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

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

{{ 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) из таблицы соответствия для текущей версии, то происходит анализ данных параметров и выводится сообщение:

RLM.ARGS__{\"update_complexity_level\": \"update_complexity_level_2\"}__RLM.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 (отображается в логе как «локальный бэкап») складывается из следующих параметров:

• Размер кластера СУБД (текущего каталога 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"

Проверка типа файловой системы для каталогов текущая 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

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

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

{{ control_name }}.FAIL__В кандидате на обновление обнаружено некорректное расположение PGDATA. Сейчас - pgdata_real. Должно быть - pgdata_should_be__{{ control_name }}.FAIL

Для версии ниже 4.3.0 эталонное значение - /pgdata/11/data.

Для версии с 4.3.0 до 5.1.0 - /pgdata/<мажорная версия, пример 04>/data.

Для версии начиная с 5.1.0 и выше - /pgdata/<мажорная версия, пример 05>/data.

Проверка работоспособности клиентского сертификата postgres, который уже есть на стенде#

Проверяется возможность подключения к БД с использованием сертификата. При успешном подключении осуществляется выполнение тестового запроса на active:

SELECT version();

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

{{ control_name }}.FAIL__Локальный для {{ inventory_hostname }} пользователь postgres не может подключиться к БД используя сертификаты. Возможные причины: \
1.Проверьте валидность дат сертификатов командами: \
openssl x509 -in {{ pg_certs_pwd.postgres_cert }} -noout -enddate; \
openssl x509 -in {{ pg_certs_pwd.root_ca }} -noout -enddate; \
2.Проверить принадлежность сертификатов  к одному УЦ с помощью команд: \
openssl x509 -in {{ pg_certs_pwd.postgres_cert }} -noout -text; \
openssl x509 -in {{ pg_certs_pwd.root_ca }} -noout -text; \
openssl x509 -in <значение параметра ssl_cert_file из конфига postgresql.conf> -noout -text; \
3.Проверьте наличие строки подключения в pg_hba 'hostssl all postgres {{ ansible_default_ipv4.address }}/32 cert'__{{ 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-заменителя#

Для стендов с KMS-заменителем реализована перелинковка библиотек в процессе обновления с /usr/pgsql-se-05/lib/libconnector_plugin.so -> plugins/libvault_plugin.so на /usr/pgsql-se-05/lib/libconnector_plugin.so -> plugins/libkms_substitute_plugin.so. Перед этим действием производится проверка на наличие включенного TDE и определение рабочего файла .so:

SELECT check_tde_is_on();

Если исходная СУБД Pangolin работала с KMS-заменителем, будет произведена перелинковка, если нет, то действие по перелинковке будет пропущено.

Примечание:

Для стендов с исходной версией СУБД Pangolin 5.1.0 и KMS-заменителем до начала обновления будет производиться подмена некорректного плагина KMS-заменителя, который будет входить в состав дистрибутива и находиться в каталоге plugins/5.1.0/RedHat/libkms_substitute_plugin.so. В случае падения во время обновления, скрипты восстановления к исходной версии производить возврат некорректного плагина KMS-заменителя не будут.

Проверка структуры каталогов 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. В задаче распечатана информация для анализа различий.

Проверка наличия записей в схеме public#

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

SELECT format('{{ item.datname }}.%1$s.%2$s',table_schema,table_name) data_public
FROM information_schema.tables
WHERE table_schema = 'public' AND table_name NOT LIKE 'pathman%' AND table_name NOT LIKE 'pg_stat_state%';

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

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

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

Под пользователем 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'"
  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

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

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

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

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

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

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

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

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

Под пользователем 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

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

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

{{ control_name }}.WARNING__Пользователь {user_for_backup} не имеет прав на выполнение функции {fuction}. Для данного пользоватея необходимо будет добавить права на выполнение данной функции. В противном случае, служба СРК после обновления не сможет создавать РК в процессе своей работы.__{{ control_name }}.WARNING

Проверка confd#

Если установлен 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

Проверка расширений установленных в системный каталог или в схему public#

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

SELECT format('%2$s.%1$s',extname,nspname) extname
FROM pg_catalog.pg_extension ex
JOIN pg_namespace ns ON ex.extnamespace =ns.oid
WHERE (ns.nspname='public') OR (ns.nspname SIMILAR TO '(pg_|information_schema)%' AND ex.extrelocatable);

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

{{ control_name }}.WARNING__Установка расширений в схему public или в системный каталог противоречит ВНД. Список расширений, установленных в них (<имя схемы>.<имя расширения>): extension_name__{{ control_name }}.WARNING

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

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

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

Проверка наличия процедур с использованием Python 2.x#

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

SELECT format('%1$s.%2$s',ns.nspname,pp.proname) pr_name
FROM pg_proc pp
JOIN pg_catalog.pg_language pl ON pp.prolang =pl.oid
JOIN pg_namespace ns ON pp.pronamespace =ns.oid AND pl.lanname SIMILAR TO 'plpython2?u%';

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

{{ control_name }}.FAIL__Прекращена поддержка языка Python 2.х. Список процедур, использующих их (<имя схемы>.<имя процедуры>): procedure_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-dbms и postgresql-sber-edition, если они оба установлены, то будет выведено сообщение:

"{{ control_name }}.FAIL__На стенде установлено 2 разных пакета Pangolin - platform-v-pangolin-dbms и 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

Вывод информационного сообщения 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 на версию 5.4.0 не производится обновление ролевой модели, пользовательских БД, схем и настройка расширений, которые были добавлены к развертыванию в версиях 5.2.x и выше;

• в рамках обновления СУБД Pangolin на версию 5.4.0 не производится пересоздание хранилища паролей, а также добавление новых записей, которые были добавлены к развертыванию в версиях 5.2.x и выше;

• в рамках обновления СУБД Pangolin на версию 5.4.0 не производится автоматическое обновление компонента rsyslog. Для этого используется отдельная роль, расположенная в компоненте installer;

• в рамках обновления СУБД Pangolin на версию 5.4.0 не производится автоматическая постановка и снятие с паузы monitoring;

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

• в рамках обновления СУБД Pangolin на версию 5.4.0 обновление стендов с включенной защитой от привилегированных пользователей не рассматривается (такие стенды в дальнейшем будут обновляться в рамках отдельного/специального типа обновления);

• к минимальным версиям для установки обновления относятся версии 4.6.1 (и выше) и 5.2.x (и выше). Таблица с поддерживаемыми версиями обновления приведена ниже;

• сторонние расширения (не входящие в состав продукта), а также запрещенные и не поддерживаемые новой версией СУБД Pangolin при обновлении СУБД Pangolin на версию 5.4.0:

  • должны быть заранее заменены аналогами из списка разрешенных расширений;

  • данные расширения в процессе обновления исключаются из shared_preload_library;

  • после миграции данных с помощью утилиты pg_upgrade, версии расширений НЕ переносятся принудительно в схему ext, так как такое действие может вызвать нарушение функционала АС. При обнаружении расширений в схеме public устанавливается предупреждение warning;

• в случае наличия утилиты haproxy, конфигурационный файл haproxy.cfg не обновляется, остается его версия до обновления;

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

• не настраивается защищенное SSL-соединение как между компонентами кластера (patroni, etcd, pgbouncer), так и для внешних подключений - SOC, KMS, WatchDog, Zabbix, Tenable, pg_cron, pg_profile. Для этих настроек может быть использован отдельный пользовательский сценарий, реализация которого будет осуществлена позже, или же обновление, отличное от рассматриваемого уровня сложности, подразумевающее обновление конфигурации СУБД;

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

• изменился подход к ограничению на снятие РК во время обновления. Вместо запрета на подключение к БД для УЗ backup_user запрещается выполнение функции pg_start_backup. Также во время обновления происходит подмена скриптов manage_backup.sh и pg_se_archlogs.sh на скрипты-заглушки при вызове которых будeт выдан код возврата 164 и сообщение [WARNING] На данный момент СУБД Pangolin находится в процессе обновления, снятие РК невозможно [WARNING], что позволяет запретить снятие РК и WAL-ов во время обновления. После окончания обновления или в процессе автоматического отката данные скрипты возвращаются обратно. При успешном обновлении скрипты manage_backup.sh и pg_se_archlogs.sh будут обновлены. После окончания обновления или в процессе автоматического отката будут возвращены права УЗ backup_user на выполнение функции pg_start_backup;

• запрещено запускать скрипты обновления, если на стенде установлен TimescaleDB.

Обновление 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 - абсолютный путь до загруженного и распакованного дистрибутива Platform V Pangolin;

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

• stand - dev или prom стенд.

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

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

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

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

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

После завершения обновления у пользователя postgres в его корневой директории будет сгенерирован файл с названием .process_work_statuses. В нем будет отображатьcя состояние корректности установленных обновлений. Ниже приведен пример данного файла с конфигурации продукта 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

Добавленные изменения в обновлении#

В обновлении присутствует ряд дополнительных функций описанных ниже:

1. В рамках обновления СУБД Pangolin на версию 5.4.0 производится обновление установленных и доступных для СУБД Pangolin расширений с использованием sql-скрипта.