Перейти к основному содержимому

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

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

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

  • Автоматизированная проверка перед обновлением обусловлена обязательным запуском скрипта-разведчика (playbook_scouting.yaml), в задачи которого входит выполнение ряда проверок, сбора информации о стенде, а также вычислении типа обновления версии СУБД, необходимого для перехода на новую версию СУБД Pangolin. Все проверки происходит автоматически. В результате проверок могут быть либо выведены предупреждения, и дальнейшее обновление может быть продолжено, либо выведены ошибки, и дальнейшее обновление будет заблокировано. Со всеми возможными проверками, предупреждениями и ошибками вы можете ознакомиться в разделах далее.

  • Ручная проверка перед обновлением обусловлена ручным проведением необходимых проверок с помощью представленных рекомендаций в данном разделе. Является обязательным шагом для предотвращения возникновения возможных трудностей непосредственно в процессе обновления.

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

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

к сведению

Данные действия производятся автоматически при работе скрипта.

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

  1. Разблокируйте пользователя postgres в системе следующей командой:
sudo usermod -U postgres
  1. Установите новый пароль для пользователя postgres в системе:
sudo -i -u postgres
  1. Обновите пароль пользователя postgres в СУБД. Для этого подключеть к БД и выполните следующий SQL-запрос:
ALTER USER postgres PASSWORD '<new_pwd>';

Где new_pwd - пароль пользователя postgres, который вы установили в системе ранее.

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

Запуск автоматизированной проверки готовности к обновлению​

Сведения

Раздел описывает запуск скрипта-разведчика для автоматизированной проверки готовности к обновлению. При реализации ручной проверки пропустите данный раздел.

Обязательным условием запуска скриптов обновления СУБД, является запуск скрипта-разведчика (playbook_scouting.yaml).

Важно

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

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

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

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

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

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

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

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

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

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

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

    • custom_config — абсолютный путь к файлу конфигурации custom_file_template.yml;
    • local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;
    • pangolin_license_path - полный путь к каталогу, где расположены файлы лицензии.

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

    • -i — путь к inventory-файла;
    • --extra-vars — переменные, которые по приоритету важнее переменных из inventory;
    • -t — теги для запуска;
    • -v — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;
    • --ask-vault-pass или --vault-password-file — расшифровка зашифрованных файлов во время выполнения.
    Внимание!

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

Необходимые проверки перед обновлением​

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

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

Проверки для всех типов обновления​

Проверка установленной версии Ansible​

Производится проверка текущей установленной версии Ansible.

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

"{{ control_name }}.FAIL__E01002:Версия установленного ansible: {installed_ansible_version}. Для работы требуется версия: {min_ansible_version} или выше.__{{ control_name }}.FAIL"

Где:

  • installed_ansible_version - установленная версия Ansible на стенде;
  • min_ansible_version - минимально необходимая версия Ansible.

Проверка возможности скачивания зависимостей, необходимых для корректной работы скриптов автоматизации​

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

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

"{{ control_name }}.FAIL__E03028:Обнаружена ошибка во время проверки скачивания {package_manager} пакетов {list_of_packages}. Проверьте настройку репозиториев.__{{ control_name }}.FAIL"

Где:

  • package_manager - название менеджера пакетов;
  • list_of_packages - список пакетов, которые не удалось скачать.

Проверка поддерживаемых ОС и их версий​

Производится проверка типа и версии ОС стенда.

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

"{{ control_name }}.FAIL__E01006:Текущая ОС {current_os} не поддерживается. Список поддерживаемых ОС: {list_of_os}.__{{ control_name }}.FAIL"

"{{ control_name }}.FAIL__E01007:Используемый дистрибутив {current_distribution} версия: {current_distribution_version}. Поддерживаемый дистрибутив {current_distribution}: с версии {min_required_os} до {max_required_os}.__{{ control_name }}.FAIL"

Где:

  • current_os - ОС на узле стенда;
  • list_of_os - список поддерживаемых ОС;
  • current_distribution - название установленного на узле дистрибутива;
  • current_distribution_version - версия установленного на узле дистрибутива;
  • min_required_os - минимальная версия поддерживаемого дистрибутива;
  • max_required_os - максимальная версия поддерживаемого дистрибутива.

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

Данные проверки осуществляются, если стенд был настроен с помощью fqdn узлов и был включен параметр used_fqdn_host. По умолчанию данный параметр включен.

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

    "{{ control_name }}.FAIL__E01005:{inventory_hostname} имеет проблемы с получением сетевого имени от DNS сервера. Проверьте корректность файлов /etc/hosts и /etc/resolv.conf.__{{ control_name }}.FAIL"

    Где inventory_hostname - имя узла стенда, с которого был запущен скрипт автоматизации.

  2. Производится проверка доступности узлов по сетевому имени. Проверка осуществляет опрос DNS сервера на предмет получения IP-адресов для сетевых имен узлов стенда. Если данная проверка не пройдена, то будет выведена следующая ошибка:

    "{{ control_name }}.FAIL__E01043:В кандидате на обновление для хоста {} был определен следующий fqdn {}. Данный fqdn не прошел проверку доступности. Такое может быть, когда некорректно настроен DNS-сервер или указано некорректное DNS имя для хоста в /etc/hosts.__{{ control_name }}.FAIL"

  3. Производится проверка соответствия IP-адреса, полученного от DNS сервера и IP-адреса, указанного на узле. В случае неудачи данной проверки будет выведена следующая ошибка:

    "{{ control_name }}.FAIL__E01046:В кандидате на обновление для хоста {} определен следующий FQDN {}. Он не соответствует IP-адресу, полученному с хоста. Это может быть связано с некорректной настройкой DNS-сервера или неправильным указанием DNS-имени для хоста в /etc/hosts.__{{ control_name }}.FAIL"

Проверка файла лицензии​

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

Если файл лицензии не найден, будет выведена ошибка:

"{{ control_name }}.FAIL__E01021:Лицензия, переданная в параметре pangolin_license_path, не найдена. Для продолжения скорректируйте параметр pangolin_license_path, указав путь до лицензии.__{{ control_name }}.FAIL"

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

"{{ control_name }}.FAIL__E01022:Переданная лицензия невалидная.
{error_stdout}__{{ control_name }}.FAIL"

Где error_stdout - вывод результата проверки файла лицензии.

Проверка Machine ID​

Производится проверка наличия Machine ID на узлах стенда.

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

"{{ control_name }}.FAIL__E01015:На хосте {inventory_hostname}, не найден файл {path_to_file} или он пустой. Для продолжения нужно инициализировать данный файл.__{{ control_name }}.FAIL"

"{{ control_name }}.FAIL__E01016:На хосте {inventory_hostname}, содержимое файла /etc/machine_id не имеет hex формат. Для продолжения нужно переинициализировать данный файл.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - имя узла стенда;
  • path_to_file - путь до файла с Machine ID.

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

Производится проверка конфигурационного файла postgresql.conf на предмет ошибок заполнения.

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

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

Где inventory_hostname - имя узла стенда.

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

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

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

"{{ control_name }}.FAIL__E03017:Обновление невозможно, так как текущая версия ({current_db_version}) не поддерживается. Минимальная поддерживаемая версия: {min_db_version}. Рекомендуется обновиться на промежуточную версию.__{{ control_name }}.FAIL"

Где:

  • current_db_version - версия Pangolin, установленная на стенде;
  • min_db_version - минимально поддерживаемая версия Pangolin для обновления.

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

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

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

Если обнаружено наличие КМС-заменителя, будет выведена следующая ошибка:

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

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

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

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

"{{ control_name }}.FAIL__E01017:Переданный пароль от суперпользователя postgres не соответствует ни открытому виду, ни ansible-хешу. Требуется передать пароль в открытом виде или в виде ansible-хеша. Для продолжения работы необходим пароль.__{{ control_name }}.FAIL"

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

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

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

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

Где path_to_tmp_file - путь до временного файла с паролем.

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

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

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

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

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

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

Выполняется поиск конфигурационного файла для подключения к VAULT. При отсутствии файла будет выведено сообщение:

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

Где path_to_config - пути до конфигурационного файла для подключения к VAULT.

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

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

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

Где error_stdout - вывод ошибки в результате выполнения команды setup_kms_credentials show --plain.

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

/opt/pangolin-security-utilities/bin/setup_kms_credentials show --plain

Пример ожидаемого вывода команды:

+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |        host | port |     root CA path |     suffix | prefix | namespace |            cred type | auth point |              id |        status |
-----+----------+-------------+------+------------------+------------+--------+-----------+----------------------+------------+-----------------+----------------
|  0 |    https |  <ip-vault> | 8200 | /pg_ssl/root.crt | postgresql |     kv |           | Userpass Auth Method |   userpass | adminencryption |            Ok |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------+

Где ip-vault - IP-адрес Vault сервера.

:::

::::

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

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

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

Где:

  • error_stdout - вывод ошибки в результате выполнения команды ./secret_storage_client --config;
  • path_to_config - путь до конфигурационного файла для подключения к VAULT.

Проверьте корректность подключения к VAULT хранилищу. Для этого выполните следующую команду под пользователем postgres:

<path_to_dir>/secret_storage_client --config

Где path_to_dir - полный путь до каталога с бинарным файлом secret_storage_client. По умолчанию данный путь - /home/postgres/installer_cache_dir/secret_storage_client_bundle/bin/.

Пример ожидаемого вывода:

secure_config|||VST_ONLY_VAULT|||present|||on:::password_encryption|||VST_ONLY_VAULT|||present|||scram-sha-256:::ssl|||VST_ONLY_VAULT|||present|||on:::allowed_servers|||VST_ONLY_VAULT|||present|||:::sec_admin_default_auth|||VST_ONLY_VAULT|||present|||scram-sha-256:::pg_ident_conf|||VST_BOTH|||absent|||:::is_tde_on|||VST_ONLY_VAULT|||present|||on:::password_policies_enable|||VST_ONLY_VAULT|||present|||on:::password_policy.deny_default|||VST_ONLY_VAULT|||present|||off:::password_policy.reuse_time|||VST_ONLY_VAULT|||present|||365 days:::password_policy.in_history|||VST_ONLY_VAULT|||present|||4:::password_policy.max_age|||VST_ONLY_VAULT|||present|||0:::password_policy.min_age|||VST_ONLY_VAULT|||present|||0:::password_policy.grace_login_limit|||VST_ONLY_VAULT|||present|||0:::password_policy.grace_login_time_limit|||VST_ONLY_VAULT|||present|||3 days:::password_policy.expire_warning|||VST_ONLY_VAULT|||present|||7 days:::password_policy.lockout|||VST_ONLY_VAULT|||present|||on:::password_policy.lockout_duration|||VST_ONLY_VAULT|||present|||24 hours:::password_policy.max_failure|||VST_ONLY_VAULT|||present|||6:::password_policy.failure_count_interval|||VST_ONLY_VAULT|||present|||0:::password_policy.check_syntax|||VST_ONLY_VAULT|||present|||on:::password_policy.min_length|||VST_ONLY_VAULT|||present|||16:::password_policy.illegal_values|||VST_ONLY_VAULT|||present|||on:::password_policy.alpha_numeric|||VST_ONLY_VAULT|||present|||3:::password_policy.min_alpha_chars|||VST_ONLY_VAULT|||present|||0:::password_policy.min_special_chars|||VST_ONLY_VAULT|||present|||1:::password_policy.min_uppercase|||VST_ONLY_VAULT|||present|||1:::password_policy.min_lowercase|||VST_ONLY_VAULT|||present|||0:::password_policy.max_rpt_chars|||VST_ONLY_VAULT|||present|||0:::password_policy.track_login|||VST_ONLY_VAULT|||present|||0:::password_policy.max_inactivity|||VST_ONLY_VAULT|||present|||0:::password_policy.use_password_strength_estimator|||VST_ONLY_VAULT|||present|||on:::password_policy.password_strength_estimator_score|||VST_ONLY_VAULT|||present|||3:::password_policy.custom_function|||VST_ONLY_VAULT|||present|||:::password_policy.allow_hashed_password|||VST_ONLY_VAULT|||present|||on:::psql_encrypt_password|||VST_ONLY_VAULT|||present|||on:::encrypt_new_tablespaces|||VST_ONLY_VAULT|||present|||ddl:::test_vst_both_restart_only|||VST_BOTH|||absent|||:::test_vst_both_reload_restart|||VST_BOTH|||absent|||:::password_policy.transport_password_mark_automatic|||VST_ONLY_VAULT|||present|||off:::password_policy.transport_password_life_time|||VST_ONLY_VAULT|||present|||0:::performance_insights.masking|||VST_ONLY_VAULT|||present|||on:::masking_mode|||VST_ONLY_VAULT|||present|||disabled:::nonrestorable_deletion|||VST_ONLY_VAULT|||absent|||:::nonrestorable_wal_deletion|||VST_ONLY_VAULT|||absent|||:::integrity_check_delay|||VST_ONLY_VAULT|||absent|||:::integrity_check_wait|||VST_ONLY_VAULT|||absent|||:::integrity_check_select_wait|||VST_ONLY_VAULT|||absent|||:::loading_control.check_allow_list|||VST_ONLY_VAULT|||absent|||:::loading_control.check_hash|||VST_ONLY_VAULT|||absent|||:::enabled_extra_auth_methods|||VST_ONLY_VAULT|||present|||cert:::enabled_sec_admin_extra_auth_methods|||VST_ONLY_VAULT|||present|||cert:::enable_vault_params_cache|||VST_ONLY_VAULT|||absent|||:::enable_vault_certificates_cache|||VST_ONLY_VAULT|||absent|||:::vault_cache_expiration_at_fault|||VST_ONLY_VAULT|||absent|||:::vault_cache_expiration_timeout|||VST_ONLY_VAULT|||absent|||

Получение списка параметров, говорит о том, что подключение до Vault хранилище работает и проблем не наблюдается. В противном случае необходимо убедиться в наличии конфигурационного файла enc_connection_settings.cfg (по умолчанию располгается в /etc/postgres/enc_connection_settings.cfg) и устранить проблемы с подключением к Vault хранилищу.

:::

::::

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

Осуществляется проверка состояния параметра secure_config на стенде и в защищенном хранилище.

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

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

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

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

  1. Выполните следующую команду для получения значения параметра secure_config установленного в БД (под пользователем postgres):

    psql -c "SHOW secure_config;"

  2. Получите список всех параметров из Vault хранилища командой:

    <path_to_dir>/secret_storage_client --config

    Где path_to_dir - полный путь до каталога с бинарным файлом secret_storage_client. По умолчанию данный путь - /home/postgres/installer_cache_dir/secret_storage_client_bundle/bin/.

  3. Найдите параметр secure_config и сравните его значение со значением из первого пункта. Они должны совпадать.

    В случае, если значения параметров не совпадают, проверьте состояние стенда на наличие подключенных средств защиты информации и корректность сконфигурированного ID на сервере VAULT.

:::

::::

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

Осуществляется проверка состояния TDE на стенде и в защищенном хранилище.

В случае, когда состояние стенда показало включенное TDE, в защищенном хранилище ожидается значение on/true, в противном случае будет выведена ошибка:

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

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

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

  1. Выполните следующую команду для получения значения параметра is_tde_on установленного в БД (под пользователем postgres):

    psql -c "SHOW is_tde_on;"

  2. Получите список всех параметров из Vault хранилища командой:

    <path_to_dir>/secret_storage_client --config

    Где path_to_dir - полный путь до каталога с бинарным файлом secret_storage_client. По умолчанию данный путь - /home/postgres/installer_cache_dir/secret_storage_client_bundle/bin/.

  3. Найдите параметр is_tde_on и сравните его значение со значением из первого пункта. Они должны совпадать.

    В случае, если значения параметров не совпадают, проверьте состояние стенда на наличие подключенных средств защиты информации и корректность сконфигурированного ID на сервере VAULT.

:::

::::

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

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

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

Где path_to_dir - путь до директории в конфигурационном файле.

  1. Выполните следующую команду (под пользователем postgres) для получения значения параметра pg_ident из конфигурационного файла pg_ident.conf:

    cat /pgdata/06/data/pg_ident.conf | grep pg_ident

  2. Получите список всех параметров из Vault хранилища командой:

    <path_to_dir>/secret_storage_client --config

    Где path_to_dir - полный путь до каталога с бинарным файлом secret_storage_client. По умолчанию данный путь - /home/postgres/installer_cache_dir/secret_storage_client_bundle/bin/.

  3. Найдите параметр pg_ident и сравните его значение со значением из первого пункта. Они должны совпадать.

    В случае, если значения параметров не совпадают, проверьте состояние стенда на наличие подключенных средств защиты информации и корректность сконфигурированного ID на сервере VAULT.

:::

::::

Проверка подключения к базе данных​

Осуществляется проверка тестового подключения в БД.

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

"{{ control_name }}.FAIL__E01019:Пароль суперпользователя postgres в хранилище SecMan (системе хранения и управления секретами) не соответствует текущему паролю в базе данных.__{{ control_name }}.FAIL"

Если подключение к БД завершится неудачей из-за отсутствия некорректного доступа в pg_hba, будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E01048:Файл 'pg_hba.conf' не содержит корректной строки для подключения пользователя '{username}' к хосту '{inventory_hostname}' с использованием метода 'scram-sha-256'.__FAIL"

Где:

  • username - имя пользователя, под которым производилось тестовое подключение;
  • inventory_hostname - имя узла стенда.

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

"{{ control_name }}.FAIL__E01049:При выполнении тестового запроса к хосту '{inventory_hostname}' через порт '{db_port}' c текущими данными для подключения пользователя '{username}' в pg_hba.conf произошла непредвиденная ошибка. Оригинальный текст ошибки: \"'{error_stdout}'\"/. Устраните проблему и попробуйте снова.__{{ control_name }}.FAIL"

Где:

  • username - имя пользователя, под которым производилось тестовое подключение;
  • inventory_hostname - имя узла стенда;
  • db_port - порт, к которому производилось подключение;
  • error_stdout - оригинальный текст ошибки подключения.

Проверка наличия записей postgres в cron​

Выполняется проверка отсутствия/наличия записей postgres в cron.

Если в файле /etc/cron.allow не удалось найти записи postgres, будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E01044:В конфигурационном файле /etc/cron.allow не удалось обнаружить запись postgres. Для корректной работы скриптов развертывания/обновления необходимо добавить данную запись либо удалить файл.__{{ control_name }}.FAIL"

Если в файле /etc/cron.deny обнаружена запись postgres, будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E01045:В конфигурационном файле /etc/cron.deny была обнаружена запись postgres. Для корректной работы скриптов развертывания/обновления необходимо удалить данную запись.__{{ control_name }}.FAIL"

Проверка наличия задержки между узлами​

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

Если задержка между мастером и репликой будет превышать допустимое значение, установленное в кастомном конфигурационном файле (по умолчанию данное значение равно 100 мб), то будет выведена ошибка:

"{{ control_name }}.FAIL__E03082:В кандидате на обновление обнаружен недопустимый объем lag: {current_lag}. Для продолжения обновления  нужно синхронизировать кластер до максимального объема lag {max_lag}.__{{ control_name }}.FAIL"

Где:

  • current_lag - текущая задержка между мастером и репликой;
  • max_lag - пороговое значение задержки.

Необходимо проверить наличие задержки между мастером и репликой.

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

pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list <clustername>

Где clustername - имя кластера

Пример ожидаемого результата:

+ Cluster: clustername (cluster-id) -----------------+--------------+-----------+----+-----------+
| Member                | Host                       | Role         | State     | TL | Lag in MB |
+-----------------------+----------------------------+--------------+-----------+----+-----------+
|       srv-ip-1        |       srv-ip-1:5433        | Leader       | running   |  3 |           |
|       srv-ip-2        |       srv-ip-2:5433        | Sync Standby | streaming |  3 |         0 |
+-----------------------+----------------------------+--------------+-----------+----+-----------+

Обратите внимание на колонку Lag in MB. Оптимальным считается минимальное значение данного показателя.

Максимально рекомендуемое значение задержки между мастером и репликой при обновлении с переносом данных - 100 Мб, при обновлении системных каталогов - 0 Мб. :::

::::

Проверка прослушивания портов​

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

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

"{{ control_name }}.FAIL__E03106:Сервис {service_name} не прослушивает ни один из портов. Проверьте состояние сервиса или настройки конфигурационного файла.__{{ control_name }}.FAIL"

Где service_name - имя службы.

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

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

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

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

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

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

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

"{{ control_name }}.FAIL__E03021:Зафиксирована неудачная попытка обновления версии СУБД Pangolin. В ручном режиме восстановите полностью состояние кластера предыдущей/исходной версии СУБД Pangolin и удалите файл {path_to_file}.__{{ control_name }}.FAIL"

Где path_to_file - полный путь до файла update_disallowed.

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

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

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

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

"{{ control_name }}.FAIL__E03021:Зафиксирована неудачная попытка обновления версии СУБД Pangolin. В ручном режиме восстановите полностью состояние кластера предыдущей/исходной версии СУБД Pangolin и удалите файл {path_to_file}.__{{ control_name }}.FAIL"

Где path_to_file - полный путь до файла update_disallowed.

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

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

Проверяется значение параметра is_inner_full_backup.

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

"{{ control_name }}.WARNING__W03004:Создание локальной резервной копии СУБД было отключено пользователем. Процедура автоматического восстановления СУБД к исходному состоянию в случае непредвиденных ошибок в процессе обновления будет отключена.__{{ control_name }}.WARNING"

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

Проверка пути до директории для резервного копирования​

Осуществляется проверка пути до директории для резервного копирования.

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

"{{ control_name }}.FAIL__E03024:Обнаружены ошибки в процессе определения пути до каталога резервной копии. В директории {pgbackup_path} был обнаружен следующий перечень возможных путей '{list_of_dirs}'. Определить точный путь до резервной копии не удалось. Скорректируйте содержимое директории {pgbackup_path}, оставив только актуальный каталог с резервной копией и перезапустите механизм обновления.__{{ control_name }}.FAIL"

Где:

  • pgbackup_path - путь до директории для создания РК;
  • list_of_dirs - список директорий внутри pgbackup_path.

Проверка учетной записи для резервного копирования​

Выполняется следующий запрос к БД:

SELECT pg_roles.rolname FROM pg_roles WHERE rolname='{{ user_for_backup }}';

Где user_for_backup - имя УЗ для резервного копирования.

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

"{{ control_name }}.FAIL__E03015:Техническая учетная запись {user_for_backup} не используется в процессе резервного копирования. Рекомендуется проверить наличие указанного пользователя в конфигурационном файле компонента или произведите проверку наличия пользователя в БД.__{{ control_name }}.FAIL"

Где user_for_backup - имя УЗ для резервного копирования.

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

Производится проверка соответствия роли master, указанного в файле inventory, и фактического указания роли master на стенде.

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

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

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

Выполняется проверка наличия параметра CLNAME в bash_profile пользователя postgres.

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

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

Выполняется проверка наличия всех файлов сертификатов, указанных в пользовательском конфигурационно файле.

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

"{{ control_name }}.FAIL__E02002:Файл '{path_to_certs}' не найден на хосте {inventory_hostname}. Проверьте наличие файла и значение в кастомном конфиге - '{path_to_config}'__{{ control_name }}.FAIL"

Где:

  • path_to_certs - путь до сертификатов, указанный в пользовательском конфигурационном файле;
  • inventory_hostname - имя узла стенда;
  • path_to_config - путь до пользовательского конфигурационного файла.
примечание

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

:::

Проверка не требуется ввиду того, что действия производятся вручную, без средств автоматизации.

::::

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

Выполняется следующий запрос к БД:

SHOW installer.cluster_type;

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

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

"{{ control_name }}.FAIL__E03095:Текущий тип конфигурации, согласно конфигурационному параметру СУБД - {type_of_configuration}, при этом обнаружены несоответствующие конфигурации компоненты: {list_of_components}. Удалите несоответствующие компоненты.__{{ control_name }}.FAIL"

Где:

  • type_of_configuration - тип установленной конфигурации;
  • list_of_components - список несоответствующих компонент.

Проверка минимальной поддерживаемой версии СУБД, над которой может быть выполнен сценарий разведки/обновления​

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

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

"{{ control_name }}.FAIL__E03017:Обновление невозможно, так как текущая версия ({current_db_version}) не поддерживается. Минимальная поддерживаемая версия: {min_db_version}. Рекомендуется обновиться на промежуточную версию.__{{ control_name }}.FAIL"

Где:

  • current_db_version - версия Pangolin, установленная на стенде;
  • min_db_version - минимально поддерживаемая версия Pangolin для обновления.

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

Проверка поддержки версии Pangolin, на которую планируется обновление​

Производится проверка версии экземпляра СУБД Pangolin, на которую планируется обновление с помощью скриптов автоматизации.

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

"{{ control_name }}.FAIL__E03025:Обновление невозможно, так как версия, на которую производится обновление не поддерживается. Смотрите матрицу обновлений версий СУБД.__{{ control_name }}.FAIL"

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

Скрипт запрашивает информацию об установленном типе конфигурации и сравнивает его со списком неподдерживаемых.

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

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

Где configuration_type - тип установленной конфигурации.

Список поддерживаемых вариантов конфигурации:

  • cluster-patroni-etcd-pgbouncer;
  • standalone-postgresql-only;
  • standalone-postgresql-pgbouncer;
  • standalone-patroni-etcd-pgbouncer.

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

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

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

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

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

"{{ control_name }}.FAIL__E03026:Обновление в автоматическом режиме при наличии включенных средств защиты информации (TDE, защита конфигурации, защита от привилегированных пользователей) для версии ({current_db_version}) в текущей версии скриптов автоматизации невозможно.__{{ control_name }}.FAIL"

Где current_db_version - установленная версия СУБД.

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

Производится проверка свободного места в точке монтирования PGBACKUP (пример: /pgarclogs/0{major_version}). Требуется минимум 1 Гб.

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

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

Где current_free_space - количество свободного места в точке монтирования.

Сведения

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

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

"{{ control_name }}.FAIL__E03038:Автоматическое обновление ограничено размером табличных пространств кластера СУБД в {} Гб. Табличное пространство tbs_name имеет размер {} Гб.__{{ control_name }}.FAIL"

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

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

"{{ control_name }}.FAIL__E03014:Не найден каталог {local_backup_path}, указанный в качестве каталога для создания локального резервного копирования. Создайте каталог.__{{ control_name }}.FAIL"

:::

Необходимо проверить количество свободного места в точке монтирования PGBACKUP (пример: /pgarclogs/0{major_version}).

Для этого выполните следующие команды:

# Получение информации о точках монтирования в директории
mount | grep '<path_to_dir>'

# Получение информации о занятом пространстве для точки монтирования
df -h <path_to_mpoint>

Где:

  • path_to_dir - полный путь до каталога PGBACKUP
  • path_to_mpoint - полный путь до точки монтирования

Для точки монтирования PGBACKUP необходимо не менее 1 Гб свободного пространства.

::::

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

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

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

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

"{{ control_name }}.FAIL__E03089:Недостаточно свободного места для локального бэкапа в {local_backup_path}. Доступно {local_backup_path_free_mb} Мб. Требуется >= {pgdata_size_need_mb} Мб.__{{ control_name }}.FAIL"

Где:

  • local_backup_path - директория для создания локального бэкапа;
  • local_backup_path_free_mb - количество свободного места в local_backup_path, указано в МБ;
  • pgdata_size_need_mb - количество необходимого свободного места в local_backup_path, указано в МБ.

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

Производится проверка наличия свободного места для точек монтирования:

  • /usr/;
  • pangolin_ansible_cache;
  • pgdata;
  • PGBACKUP;
  • PGLOGS.

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

"{{ control_name }}.FAIL__E01012:Точка монтирования {dir} имеет {current_free_space} Гб свободного пространства, но требуется не менее {needed_free_space} Гб.__{{ control_name }}.FAIL"

Где:

  • dir - точка монтирования;
  • current_free_space - свободное пространство в точке монтирования;
  • needed_free_space - необходимый объем свободного пространства в точке монтирования.

Проверка свободного места для PGDATA на реплике​

Производится проверка свободного места в каталоге $PGDATA на реплике.

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

"{{ control_name }}.FAIL__E03043:Недостаточно свободного места в точке монтирования для pgdata на реплике ({replica_hostname}) для выполнения обновления. Доступно свободного места {current_free_space} Мб, требуется {needed_free_space} Мб__{{ control_name }}.FAIL"

Где:

  • replica_hostname - имя реплики из inventory файла;
  • current_free_space - текущий объем свободного места;
  • needed_free_space - необходимый объем свободного места.

Необходимо убедиться в том, что на реплике достаточно свободного места в каталоге PGDATA.

Для этого необходимо выполнить следующие действия:

  1. Определить размер каталога PGDATA на мастере командой:

    du -sk <path_to_pgdata> | awk '{print $1}'

    Где path_to_pgdata - полный путь до каталога PGDATA.

  2. Определяем необходимое количество свободного пространства для каталога PGDATA на реплике, необходимое для обновления. Рассчитать необходимое пространство можно по формуле:

    need_size_pgdata_replica = size_pgdata_master * 2 / 1024

    Где:

    • size_pgdata_master - размер каталога PGDATA на мастере;
    • need_size_pgdata_replica - расчетное значение необходимого пространства для каталога PGDATA на реплике.

  3. Определить точку монтирования, в которой каталог PGDATA расположен и выяснить его свободное место с помощью команды:

    df -h <path_to_mount>

    Где path_to_mount - полный путь до точки монтирования.

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

В случае если места на точке монтирования будет недостаточно, перед началом обновления его необходимо будет увеличить. :::

::::

Проверка наличия свободного места для точек монтирования, содержащих табличные пространства​

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

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

"{{ control_name }}.FAIL__E03044:Недостаточно свободного места в точке монтирования {mount_name} для выполнения обновления. Доступно свободного места {current_free_space} Мб, требуется {needed_free_space} Мб__{{ control_name }}.FAIL"

Где:

  • mount_name - название точки монтирования;
  • current_free_space - текущий объем свободного места;
  • needed_free_space - необходимый объем свободного места.

Проверка наличия точек монтирования в рабочем каталоге PGDATA​

Производится проверка наличия точек монтирования в рабочем каталоге PGDATA.

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

"{{ control_name }}.FAIL__E03072:В кандидате на обновление обнаружены точки монтирования в рабочем каталоге /pgdata: {mount_name}. Размонтируйте найденные каталоги для дальнейшего обновления.__{{ control_name }}.FAIL"

Где mount_name - название точки монтирования.

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

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

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

"{{ control_name }}.FAIL__E01013:Инсталлятор не может записать файлы в директорию {dir_path}. Проверьте маску директории или назначьте владельца postgres.__{{ control_name }}.FAIL"

Где dir_path - полный путь до директории.

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

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

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

"{{ control_name }}.FAIL__E03075:Не найдена директория со старой версий virutalenv в директории PGHOME на хосте: {inventory_hostname}. Для корректной проверки установите из дистрибутива rpm пакет pangolin-ansible-venv-controlled расположенный в {path_to_rpm} на хосте с которого запускается проверка перед обновлением.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - имя узла стенда;
  • path_to_rpm - полный путь до rpm-пакета.

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

Проверка наличия корректных прав для каталогов текущая PGDATA, PGBACKUP, local_backup_path​

Производится попытка создания тестовых файлов в каталогах PGDATA, PGBACKUP, local_backup_path под пользователя postgres.

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

"{{ control_name }}.FAIL__E03029:Пользователь postgres должен иметь rwx права на каталог '{dir_path}'. Приведите права на каталог к целевому виду.__{{ control_name }}.FAIL"

Где dir_path - полный путь до директории.

Проверка корректного местоположения каталога для сохранения локального бэкапа​

Производится проверка каталога для сохранения локальной резервной копии.

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

"{{ control_name }}.FAIL__E03083:Путь для сохранения локального бэкапа не должен находиться в /pgdata, /pgdata[0-99] или содержать кириллицу.__{{ control_name }}.FAIL"

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

"{{ control_name }}.FAIL__E03084:Локальный бэкап не может находиться в каталоге с табличным пространством.__{{ control_name }}.FAIL"

Проверка корректности расположения служб, при включенной функциональности «Отказ от root» в процессе эксплуатации​

Осуществляется проверка местоположения служб текущей версии Pangolin.

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

"{{ control_name }}.FAIL__E03078:Служба {service_list} находится в системном каталоге служб, так как другие компоненты находятся в пользовательской директории служб. Для продолжения мигрируйте сервисный файл в директорию пользователя.__{{ control_name }}.FAIL"

Где service_list - список сервисов, находящихся в системном каталоге служб.

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

Для этого выполните следующую команду под пользователем postgres для каждой службы, использующейся в СУБД:

systemctl status --user <service_name>

Где service_name - название службы.

:::

::::

Проверка состояния служб​

Осуществляется проверка состояния служб текущей версии Pangolin.

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

"{{ control_name }}.FAIL__E03079:Служба {service_name} не запущена. Проверьте состояние сериса__{{ control_name }}.FAIL"

Где service_name - название службы.

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

Скрипт запрашивает структуру каталогов на active и standby для кластерной конфигурации.

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

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

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

Скрипт запрашивает на active и standby список всех символических ссылок в каталоге PGDATA и определяет куда они направлены.

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

"{{ control_name }}.FAIL__E03037:Отличаются символические ссылки в каталоге 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 ({{ _list_extensions }}{{ additional_legal_ext }});

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

legal_extensions: "'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_plpython3u', \
            'insert_username', 'intagg', 'intarray', 'isn', 'jsonb_plperl', 'jsonb_plperlu', 'jsonb_plpython3u', 'lo', 'ltree', \
            'ltree_plpython3u', 'moddatetime', 'pageinspect', 'pg_buffercache', 'pg_freespacemap', 'pg_prewarm', 'pg_stat_statements', \
            'pg_trgm', 'pg_visibility', 'pgcrypto', 'pgrowlocks', 'pgstattuple', 'plperl', 'plperlu', 'plpgsql', 'pltcl', 'pltclu', 'postgres_fdw', \
            'refint', 'seg', 'sslinfo', 'tablefunc', 'tcn', 'tsm_system_rows', 'tsm_system_time', 'unaccent', 'uuid-ossp', 'xml2', 'bool_plperlu', 'bool_plperl', \
            'rum', 'oid2name', 'online_analyze', 'pg_backup', 'pg_standby', 'protected_dump', 'pg_profile', 'orafce', 'pg_squeeze', 'pg_cron', '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', 'psql_resources_consumption_limits'"
Внимание!

Расширения (pg_background, postgis, pgrouting, pgq, pgq_coop, pgqd, pgsql-http, pldebugger, plpgsql_check, pgcopydb, pgloader), не входящие в состав Pangolin, не поддерживаются скриптами автоматического обновления.

Для обновления исполняемых файлов, в поддерживаемые, добавляется расширение: timescaledb.

Если список не пустой, то:

  • для обновления исполняемых файлов выводится предупреждающее сообщение:

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

    Где extension_list - список неподдерживаемых расширений.

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

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

    Где:

    • list_of_extensions - список неподдерживаемых расширений в параметре shared_preload_libraries;
    • inventory_hostname - наименование узла стенда.

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

"{{ control_name }}.FAIL__E03069:В кандидате на обновление обнаружены неподдерживаемые расширения {list_of_extensions} в параметре shared_preload_libraries на хосте {inventory_hostname}.__{{ control_name }}.FAIL"

:::

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

Список поддерживаемых расширений смотрите в документе «Описание расширений продукта СУБД Pangolin».

Для того чтобы проверить наличие неподдерживаемых расширений, необходимо сделать следующее:

  1. Подключиться к каждой БД и выполнить следующий SQL-запрос для поиска расширений, не входящих в список поддерживаемых:

    SELECT format('<db_name>.%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 (<list_of_extension>);

    Где:

    • db_name - имя БД, к которой было выполнено подключение;
    • list_of_extension - список поддерживаемых расширений.

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

    cat <path_to_config> | grep shared_preload_libraries

    Где path_to_config - полный путь до конфигурационного файла postgresql.conf или postgres.yml

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

::::

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

Проверяется статус снятия РК через представление backup.history.

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

"{{ control_name }}.FAIL__E03092:Обновление невозможно, так как активна сессия снятия РК внешней службой. Дождитесь окончания снятия РК со стенда__{{ control_name }}.FAIL"

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

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

{{ local_backup_path }}/scout_temp_data`

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

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

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

"{{ control_name }}.FAIL__E03047:Хост {inventory_hostname} не соответствует минимальным требованиям по CPU. Минимальное количество ядер: {min_cpu}.__{{ control_name }}.FAIL"

"{{ control_name }}.FAIL__E03048:Хост {inventory_hostname} не соответствует минимальным требованиям по RAM. Минимальное значение {min_ram} Гб.__{{ control_name }} Гб.FAIL"

Где:

  • inventory_hostname - наименование узла стенда;
  • min_cpu - минимально допустимое количество ядер ЦПУ;
  • min_ram - минимально допустимое количество оперативной памяти, Гб.

Проверка достаточного количества оперативной памяти необходимой для обновления​

Проводится проверка достаточного количества оперативной памяти необходимой для обновления.

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

"{{ control_name }}.FAIL__E03034:В кандидате на обновление обнаружен недостаток свободной оперативной памяти. Для успешного выполнения операции разведки и последующего обновления shared_buffers тестовой базы необходимо не менее {need_ram} ГБ или не менее {need_percent_ram}% свободной оперативной памяти. Сейчас доступно {free_ram} ГБ.____{{ control_name }}.FAIL"

Где:

  • need_ram - необходимое количество свободной оперативной памяти, Гб;
  • need_percent_ram - процент необходимой свободной оперативной памяти;
  • free_ram - текущее количество свободной оперативной памяти.

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

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

Если проверка обнаружила несоответствие, будет выведена ошибка:

"{{ control_name }}.FAIL__E03049:Количество ядер CPU на мастере не соответствует количеству ядер CPU на реплике.__{{ control_name }}.FAIL"

"{{ control_name }}.FAIL__E03050:Количество оперативной памяти на мастере не соответствует количетву оперативной памяти на реплике.__{{ control_name }}.FAIL"

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

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

Если оба пакета установлены, то будет выведено сообщение:

"{{ control_name }}.FAIL__E03051:На стенде установлены несколько пакетов Pangolin: platform-v-pangolin-dbms и postgresql-sber-edition. Удалите неактуальный пакет.__{{ control_name }}.FAIL"

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

Выполняется проверка наличия файлов, блокирующих обновление.

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

Если рычаг remove_block_update_tmp_files выставлен в true, данные файлы будут автоматически удалены. После удаления будет выведено сообщение об удалении данных файлов:

"{{ control_name }}.INFO__I03003:Был найден и удален триггер прерывания обновления '{path_to_trigger}'.__{{ control_name }}.INFO"
"{{ control_name }}.INFO__I03004:Был найден и удален файл предыдущего неудачного обновления '{path_to_block_file}'.__{{ control_name }}.INFO"

Где:

  • path_to_trigger - полный путь до триггера, блокирующего обновление;
  • path_to_block_file - полный путь до файла, блокирующего обновление.

Если рычаг remove_block_update_tmp_files выставлен в false, данные файлы удалены не будут. В этом случае будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03022:Зафиксирован принудительный откат пользователем СУБД Pangolin. Перед перезапуском обновления удалите файл {filename}.__{{ control_name }}.FAIL"

Где filename - полный путь до файла, блокирующего обновление.

Проверка наличия утилиты vi на стенде:​

Производится проверка наличия утилиты vi на узлах стенда.

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

"{{ control_name }}.WARNING__W01002:Утилита vi не обнаружена. Отсутствие данной утилиты делает невозможным использование alias hba для пользователя postgres. После установки/обновления БД необходимо изменить данный алиас на используемый в системе редактор.__{{ control_name }}.WARNING"

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

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

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

"{{ control_name }}.FAIL__E03052:На стенде установлен пакет Pangolin версии 6.5.0, на которую планируется обновление. Удалите данный пакет.__{{ control_name }}.FAIL"

Где version - версия установленного на стенд пакета.

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

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

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

"{{ control_name }}.FAIL__E03076:Зафиксировано несоответствие установленных версий Pangolin между узлами кластера.__{{ control_name }}.FAIL"

Необходимо убедиться что компоненты pangolin-dbms и pangolin-dbms-client на мастере и на реплики одной версии. Для этого необходимо:

  1. При обновлении с версии без пакета для компонента pangolin-dbms-client. Необходимо выполнить команду:

    yum list installed | grep platform-v-pangolin-dbms (для rpm-based систем)

    dpkg -l | grep platform-v-pangolin-dbms (для deb-based систем)

    Пример ожидаемого вывода:

    platform-v-pangolin-dbms.x86_64      <version>-sberlinux8.8               @@commandline

    Где version - версия компонента.

  2. При обновлении с версии для которой пакет для компонента pangolin-dbms-client есть, необходимо выполнить команды:

    yum list installed | grep pangolin-dbms (для rpm-based систем)

    dpkg -l | grep pangolin-dbms (для deb-based систем)

    Пример ожидаемого вывода:

    pangolin-dbms-<version>.x86_64                6.4.3-sberlinux8.10                  @@commandline
    pangolin-dbms-<version>-client.x86_64         6.4.3-sberlinux8.10                  @@commandline

    Где version - версия компонента.

:::

::::

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

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

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

"{{ control_name }}.FAIL__E03002:На узлах не совпадет тип развертывания для компонента {name_of_component}. Для продолжения обновления необходимо, чтобы наличие компонента и его версия совпадали на всех узлах.__{{ control_name }}.FAIL"

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

"{{ control_name }}.FAIL__E03003:На узлах обнаружены различные версии компонента {name_of_component}. Для продолжения обновления необходимо, чтобы версии компонента на всех узлах совпадали.__{{ control_name }}.FAIL"

Где name_of_component - название проблемного компонента.

Проверка возможности обновления компонента pangolin-backup-tools​

Производится проверка возможности обновления компонента pangolin-backup-tools.

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

"{{ control_name }}.FAIL__E03004:Обновление компонента 'pangolin-backup-tools' невозможно, ввиду некорректной предыдущей установки.__{{ control_name }}.FAIL"

Проверка наличия конфигурационных файлов компонента pangolin-backup-tools​

Производится проверка наличия конфигурационного файла компонента pangolin-backup-tools.

Если конфигурационный файл /etc/pangolin-backup-tools/backup-tools-env не будет найден, то будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03056:На хосте '{inventory_hostname}' для компонента '{name_of_component}' не удалось обнаружить конфигурационный файл {path_to_config}. Необходимо проверить корректность настройки на стенде компонента {name_of_component}.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - наименование узла стенда;
  • name_of_component - название компонента;
  • path_to_config - полный путь до конфигурационного файла компонента.

Проверка соответствия настроек pangolin-backup-tools на узлах кластера​

Производится проверка соответствия настроек компонента pangolin-backup-tools между узлами кластера.

Если настройки pangolin-backup-tools не соответствуют друг другу на мастере и на реплике, будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03057:Обнаружено несоответствие настроек компонента 'pangolin-backup-tools' на нодах кластера. Необходимо привести состяния стенда на всех нодах к одному состоянию.__{{ control_name }}.FAIL"

Необходимо убедиться, что компонент pangolin-backup-tools установлен и на мастере и на реплике. Для этого необходимо выполнить следующие действия:

  1. В случае установки компонента pangolin-backup-tools с помощью пакетного менеджера, выполните следующую команду:

    yum list installed | grep pangolin-backup-tools (для rpm-based систем)

    dpkg -l | grep pangolin-backup-tools (для deb-based систем)

  2. В случае установки компонента pangolin-backup-tools без помощи пакетного менеджера, необходимо убедиться в наличии каталога с исполняемыми файлами внутри. Для этого выполните следующую команду:

    ls -la  /opt/omni/lbin/

В случае отсутствия компонента pangolin-backup-tools, а мастере или реплике, необходимо подставить данный компонент на проблемный узел перед началом обновления.

:::

::::

Проверка наличия рабочих файлов для утилиты pangolin-backup-tools​

Производится проверка наличия необходимых рабочих файлов для компонента pangolin-backup-tools.

Если на узлах кластера не будут обнаружены все файлы, необходимые для работы утилиты pangolin-backup-tools, то будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03059:На хосте '{inventory_hostname}' для компонента '{name_of_component}' был обнаружен не весь набор рабочих файлов. Необходимо проверить корректность настройки на стенде компонента {name_of_component}.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - наименование узла стенда;
  • name_of_component - название компонента.

Проверка наличия необходимых параметров в рабочем файле утилиты pangolin-backup-tools​

Производится проверка наличия необходимых параметров в рабочем файле компонента pangolin-backup-tools.

Если в рабочем файле не будут обнаружены необходимые параметры, а именно:

  • PGINSTANCE;
  • WALSTATE_FILE;
  • LOG_FILE.

Будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03091:На узле '{inventory_hostname}' для компонента '{name_of_component}' в процессе проверки содержимого рабочего файла '{path_to_config}' не удалось  обнаружить следующие значения в нем: '{name_of_parameters}'. Произведите проверку содержимого фалйла и добавьте недостающие значения.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - наименование узла стенда;
  • name_of_component - название компонента;
  • path_to_config - полный путь до рабочего файла;
  • name_of_parameters - название необходимых параметров.

Проверка корректности установки расширения pg_cron​

Производится проверка корректности установки расширения pg_cron.

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

"{{ control_name }}.FAIL__E03005:Расширение pg_cron не должно быть установлено в базу данных template0. Удалите расширение из template0.__{{ control_name }}.FAIL"

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

"{{ control_name }}.FAIL__E03006:Текущая СУБД содержит инсталляции расширения pg_cron в нескольких баз данных. (<имя базы>.<имя схемы>.<имя расширения>): \ {database_name}. Расширение должно быть установлено только в одной баз данных, имя которой указано именем в параметре cron.database_name. Удалите расширение из других баз данных.__{{ control_name }}.FAIL"

Где database_name - название баз данных, в которых установлено расширение pg_cron.

Проверка корректности работы СУБД с зашифрованным хранилищем​

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

/bin/pg_auth_config check

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

"{{ control_name }}.FAIL__E03045:Не прошла проверка доступа к базе данных с использованием зашифрованного хранилища паролей (pg_auth_config check), на стенде {inventory_hostname}. Ознакомьтесь с логами.__{{ control_name }}.FAIL"

Где inventory_hostname - наименование узла стенда.

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

Скрипт-разведчик выполняет сравнение каталогов с исполняемыми файлами на всех хостах с СУБД Pangolin.

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

"{{ control_name }}.FAIL__E03077:Зафиксировано несоответствие директории {path_to_dir} между узлами кластера. Необходимо произвести их корректировку__{{ control_name }}.FAIL"

Где path_to_dir - путь до проблемной директории.

Проверка корректности установки расширения pg_profile​

Производится проверка корректности установки расширения pg_profile.

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

"{{ control_name }}.FAIL__E03018:Обновление невозможно. Расширение 'pg_profile' должно быть установлено в схеме 'pgse_profile'. Текущее значение: {name_of_schema}. __{{ control_name }}.FAIL"

Где name_of_schema - имя текущей схемы, в которой установлено расширение pg_profile.

Проверки расширения timescaledb​

Производятся проверки расширения timescaledb.

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

    "{{ control_name }}.FAIL__E03085:Обновление расширения timescaledb версии {current_version} не поддерживается. Необходимо обновить расширение до версии {needed_version}. __{{ control_name }}.FAIL"

    Где:

    • current_version - текущая версия расширения timescaledb;
    • needed_version - необходимая версия расширения timescaledb;

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

    "{{ control_name }}.FAIL__E03086:В БД используется расширение timescaledb с неподдерживаемой лицензией {type_of_license}.__{{ control_name }}.FAIL"

    Где type_of_license - тип лицензии текущего расширения timescaledb.

Проверка возможности обновления расширения anon​

Производится проверка версии расширения anon на предмет возможности его обновления.

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

"{{ control_name }}.FAIL__E03104:Версии расширения anon из дистрибутива и БД: {current_version} не совпадают. Обновление расширения не поддерживается.__{{ control_name }}.FAIL"

Где current_version - текущая версия расширения anon.

Проверка корректности заполнения параметра shared_preload_liraries в конфигурационном файле​

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

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

"{{ control_name }}.FAIL__E03107:Обнаружено некорректное заполнение параметра shared_preload_libraries в конфгурационном файле postgresql.conf. Строка со значением параметра shared_preload_libraries в конфигурационном файле postgresql.conf не может заканчиваться запятой.__{{ control_name }}.FAIL"

Проверка соответствия информации об узлах кластера в конфигурационном файле и на самих узлах​

Производится проверка соответствия между DNS записями узлов в конфигурационном файле СУБД и DNS записями на самих узлах.

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

"{{ control_name }}.FAIL__E03087:В конфигурационном файле {path_to_config} на хосте {inventory_hostname}, присутствует несоответствие DNS записей с хостами кластера__{{ control_name }}.FAIL"

Где:

  • path_to_config - путь до конфигурационного файла;
  • inventory_hostname - наименование узла стенда.

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

Производится проверка наличия дублирующих параметров в конфигурационном файле postgres.yml.

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

"{{ control_name }}.FAIL__E03010:В файле {path_to_config}/postgres.yml найдены параметры: {list_of_parameters}, имеющие дубли. Удалите дубликаты параметров из конфигурационного файла.__{{ control_name }}.FAIL"

Где:

  • path_to_config - полный путь до директории с конфигурационным файлом;
  • list_of_parameters - список дублирующихся параметров.

Проверка наличия unicode символов в конфигурационных файлах​

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

  • pg_hba.conf;
  • postgresql.conf;
  • postgres.yml (при кластерной конфигурации).

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

"{{ control_name }}.FAIL__E03032:В файле {path_to_config} найден символ unicode. Необходимо скорректировать конфигурационный файл.__{{ control_name }}.FAIL"

Где path_to_config - полный путь до конфигурационного файла.

Проверка наличия include_file в конфигурационном файле​

Производится проверка наличия include_file в конфигурационном файле postgresql.conf.

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

"{{ control_name }}.FAIL__E03046:В конфигурационном файле postgresql.conf присутствуют дополнительные include из {include_file}. Перенесите конфигурационные параметры из {include_file} в postgres.conf и запустите проверку повторно.__{{ control_name }}.FAIL"

Где include_file - список подключенный к postgresql.conf файлов.

Проверка количества созданных табличных пространств​

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

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

"{{ control_name }}.FAIL__E03054:Количество созданных табличных пространств больше или равно значения параметра disk_check_tablespaces_count равному {disk_check_tablespaces_count_value}, указанного в конфигурационном файле СУБД. disk_check_tablespaces_count определяет максимально возможное число табличных пространств, для которых может быть включена проверка доступности дисков. Увеличьте значение параметра disk_check_tablespaces_count. Рекомендуем для расчета использовать формулу: disk_check_tablespaces_count = количество имеющихся tablespace + 32.__{{ control_name }}.FAIL"

Где disk_check_tablespaces_count_value - текущее значение параметра disk_check_tablespaces_count.

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

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

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

"{{ control_name }}.FAIL__E03068:Обновление невозможно, так как не удалось обнаружить параметры {parameter_names} в локальном конфигурационном файле баз данных {path_to_config}. Приведите файл в актуальное состояние, добавив необходимые настроечные параметры SSL и повторите запуск скрипта разведчика.__{{ control_name }}.FAIL"

Где:

  • parameter_names - список параметров, которые не удалось обнаружить;
  • path_to_config - полный путь до конфигурационного файла.

Проверка состояния близости БД к порогу заморозки транзакций autovacuum_freeze_max_age​

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

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

WARNING__W03007:База данных близка к порогу принудительной заморозки транзакций. Перед обновлением необходимо предварительно либо выполнить vacuumdb -a -F -v (заморозка транзакций в кластере баз), либо увеличить значение параметра autovacuum_freeze_max_age для таблиц в БД, исходя из формулы max_frozen_age > 0.8 * autovacuum_freeze_max_age
Список таблиц:
{list_of_tables}.WARNING

WARNING__W03009:База данных близка к порогу принудительной заморозки транзакций. Перед обновлением необходимо предварительно либо выполнить vacuumdb -a -F -v (заморозка транзакций в кластере баз), либо увеличить значение параметра autovacuum_freeze_max_age глобально, исходя из формулы max_frozen_age > 0.8 * autovacuum_freeze_max_age.WARNING

Где list_of_tables - список таблиц, для которых необходимо увеличить значение параметра autovacuum_freeze_max_age.

Проверка количества транзакций с незавершенным статусом​

Скрипт-разведчик выполняет поиск строк с незавершенным статусом транзакции.

Если количество подобных транзакций превышает 3,15 млн будет выведено предупреждение:

WARNING__W03008:Обнаружены базы данных с большим количеством транзакций с незавершенным статусом. Рекомендуется выполнить следующую команду перед запуском обновления: vacuumdb -v -d db_name  (запуск очистки базы данных ), где db_name - имя БД из списка. 
Список БД: {list_of_databases}.WARNING"

Где list_of_databases - список баз данных, в которых обнаружено большое количество незавершенных транзакций.

Пороговое количество транзакций определено исходя из максимального количества записей, которые могут содержаться в 1 журнале и количества самих журналов (эмпирически определено как 3).

Проверки для обновления с переносом данных​

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

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

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

текущая pgdata (пример: /pgdata/0{major_version}/data)
новая pgdata (пример:/pgdata/0{major_version}/data)
pgbackup (пример: /pgarclogs/0{major_version})
local_backup_path (пример: /pgarclogs)

Для обновления с переносом данных, типы файловой системы для каталогов должны совпадать.

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

"{{ control_name }}.FAIL__E03035:Для продолжения обновления необходимо, чтобы директории с текущей pgdata, новой pgdata, pgbackup и {local_backup_path} находились в одной файловой системе. Тип файловой системы: текущая pgdata: {pgdata_old_filesystem}, новая pgdata: {pgdata_new_filesystem}, pgbackup: {pgbackup_filesystem}, local_backup_path: {local_backup_filesystem}.__{{ control_name }}.FAIL"

Где:

  • local_backup_path - путь до директории с локальной резервной копией;
  • pgdata_old_filesystem - тип файловой системы в каталоге текущей PGDATA;
  • pgdata_new_filesystem - тип файловой системы в каталоге новой PGDATA;
  • pgbackup_filesystem - тип файловой системы в каталоге PGBACKUP;
  • local_backup_filesystem - тип файловой системы в каталоге локальной резервной копии.

Проверка наличия ссылок/директорий, необходимых для обновления​

Осуществляются проверки наличия ссылок/директорий, используемых в процессе обновления.

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

    "{{ control_name }}.FAIL__E03039:Уже существует директория {new_pgdata_tmp} для переноса данных после миграции. Удалите директорию для дальнейшего обновления.__{{ control_name }}.FAIL"

    Где new_pgdata_tmp - полный путь до директории в которую планируется перенос данных после миграции.

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

    "{{ control_name }}.FAIL__E03040:Уже существует директория {local_backup_path}, в которой будут созданы резервные копии обновляемой базы данных. Удалите или переименуйте директорию для дальнейшего обновления.__{{ control_name }}.FAIL"

    Где local_backup_path - директория до нового каталога, необходимого для создания локальной резервной копии.

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

    • Если существует директория для новой PGDATA:

      "{{ control_name }}.FAIL__E03041:Уже существует директория /pgdata/{new_pgdata_dir}, которая будет использоваться после обновления. Удалите или переименуйте директорию для дальнейшего обновления.__{{ control_name }}.FAIL"

      Где new_pgdata_dir - директория до каталога с новой PGDATA.

    • Если существует директория для pgbackup:

      "{{ control_name }}.FAIL__E03042:Уже существует директория {new_pgbackup_dir}, которая будет использоваться после обновления. Удалите или переименуйте директорию для дальнейшего обновления.__{{ control_name }}.FAIL"

      Где new_pgbackup_dir - директория до нового каталога pgbackup.

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

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

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__E03011:Удалена поддержка типов данных abstime, reltime, tinterval. В базе данных обнаружены таблицы, которые не будут поддерживаться после обновления. Список таблиц, использующих их (<имя схемы>.<имя таблицы>(<имя колонки>)): {list_of_tables}. В качестве альтернативы для abstime можно рассмотреть timestamp или timestamptz, для reltime daterange или tstzrange, tinterval может быть заменен на interval.__{{ control_name }}.FAIL"

Где list_of_tables - список таблиц.

Проверка массива типов из 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__E03012:Не поддерживаются массивы типов из information_schema, которые содержат запрещенные типы данных, такие abstime, reltime, tinterval. Список таблиц, использующих их (<имя схемы>.<имя таблицы>(<имя колонки>)): {list_of_tables}. Необходимо заменить запрещенные типы данных на разршенные: для abstime можно рассмотреть timestamp или timestamptz, для reltime daterange или tstzrange, tinterval может быть заменен на interval.__{{ control_name }}.FAIL"

Где list_of_tables - список таблиц.

Проверка отсутствия не поддерживаемых функций​

Осуществляется проверка наличия функций, неподдерживаемых в новой версии Pangolin.

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

"{{ control_name }}.FAIL__E03080:Зафиксированы функции, которые не поддерживаются в новой версии Pangolin. Список функций: {list_of_functions}__{{ control_name }}.FAIL"

Где list_of_functions - список неподдерживаемых функций.

Проверка наличия процедур, использующих устаревшую версию Python​

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

WITH pc(lanname,lanacl,lanowner) AS (
SELECT lanname,lanacl,lanowner FROM pg_language pl),
depr(lanname) AS (
VALUES
 ('internal'),
 ('c'),
 ('sql'),
 ('plpgsql')
)
SELECT pc.* FROM pc JOIN depr using(lanname) WHERE (pc.lanowner != 'postgres'::regrole OR coalesce(cardinality(pc.lanacl),0) >0 OR cardinality(pc.lanacl) =0);


SELECT
    format('%1$I.%2$I %3$s',pronamespace::regnamespace::TEXT,proname,lanname)
FROM pg_catalog.pg_proc pp JOIN pg_catalog.pg_language pl ON pp.prolang =pl.oid
AND pl.lanname IN('plpythonu','plpython2u');

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

"{{ control_name }}.FAIL__E03013:Прекращена поддержка языка Python 2.х. Список процедур, использующих их (<имя схемы>.<имя процедуры>): {list_of_procedures}. Удалите расширения на Python 2.х. и перепишите процедуры, использующие эту версию языка.__{{ control_name }}.FAIL"

Где list_of_procedures - список неподдерживаемых процедур.

Проверка наличия схем с oid 2200​

Осуществляется проверка наличия схем с oid = 2200.

Если обнаружены схемы с oid = 2200 отличные от схемы public, будет выведена следующая ошибка:

"{{ control_name }}.FAIL__E03088:В кандидате на обновление обнаружены схемы с oid 2200 отличные от public в следующих базах данных: {list_of_databases}. Для продолжения обновления необходимо произвести переименование схем в public.__{{ control_name }}.FAIL"

Где list_of_databases - список баз данных.

Проверка наличия поддерживаемых операторов​

Осуществляется проверка наличия операторов, не поддерживаемых в новой версии Pangolin.

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

"{{ control_name }}.FAIL__E03094:Зафиксированы операторы, которые не поддерживаются в новой версии Pangolin. Список операторов: {list_of_operators}__{{ control_name }}.FAIL"

Где list_of_operators - список операторов.

Проверка наличия не поддерживаемых полиморфных типов​

Производится проверка наличия не поддерживаемых полиморфных типов.

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

"{{ control_name }}.FAIL__E03096:Зафиксированы полиморфные типы, которые не поддерживаются в новой версии Pangolin. Список полиморфных типов: {list_of_polymorphic_types}__{{ control_name }}.FAIL"

Где list_of_polymorphic_types - список полиморфных типов.

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

Где list_of_tables - список проблемных таблиц.

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

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

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

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

"{{ control_name }}.FAIL__E03016:Не прошла одна из проверок pg_upgrade. С ошибками можно ознакомиться на хосте master в директории {path_to_log} или в логе задачи (имя таски: journal pg_upgrade). Устраните возникшие ошибки в работе pg_upgrade.__{{ control_name }}.FAIL"

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

"{{ control_name }}.FAIL__E03016:Не прошла одна из проверок pg_upgrade. С ошибками можно ознакомиться на хосте master в директории {path_to_log}. Устраните возникшие ошибки в работе pg_upgrade.__{{ control_name }}.FAIL"

Где path_to_log - директория до лога работы утилиты pg_upgrade.

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

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

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

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

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

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

    "{{ control_name }}.FAIL__E03074:Снять дамп с исходной СУБД не удалось. Возникли следующие ошибки: {error_stdout}.__{{ control_name }}.FAIL"

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

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

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

    "{{ control_name }}.FAIL__E03023:Найдены ошибки во время проверки загрузки схемы данных. Ссылка на схему данных в папке с логами: {inventory_hostname}: {path_to_log}/currentdb.sql. Список ошибок {error_stdout}. Если анализ выявил, что ошибка ложноположительная, добавьте ошибку в фильтр в переменную {false_error_filter_for_data_schema} кастомного конфигурационного файла.__{{ control_name }}.FAIL"

Где:

  • inventory_hostname - наименование узла стенда;
  • path_to_log - путь до директории с логами;
  • error_stdout - оригинальный текст ошибки;
  • false_error_filter_for_data_schema - наименование переменной, в которую необходимо внести изменения.

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

Происходит проверка наличия логической репликации в СУБД.

Если она будет найдена, то будет выведено сообщение:

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

Где:

  • inventory_hostname - наименование узла стенда;
  • name_of_slots - имена слотов логической репликации.

Проверка наличия нестандартных прав или нестандартных владельцев для объектов​

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

-- scout types/02 . Deprecated types
WITH RECURSIVE src AS (
SELECT
    pgc.relnamespace::regnamespace
    ,pa.attrelid::regclass
    ,pa.attname
    ,pa.atttypid::regtype
    ,pgc.relkind::TEXT
FROM pg_catalog.pg_attribute pa
JOIN pg_catalog.pg_class pgc ON pa.attrelid =pgc.oid
JOIN pg_catalog.pg_type pt ON pa.atttypid=pt."oid"
WHERE
    format('%1$I.%2$I',pt.typnamespace::regnamespace::TEXT,pt.typname) IN (
    VALUES
('information_schema.sql_languages'), -- {463}
('information_schema.sql_packages'), -- {463}
('information_schema.sql_sizing_profiles'), -- {463}
('pg_catalog.abstime'), -- {463}
('pg_catalog._abstime'), -- {463}
('pg_catalog.opaque'), -- {463}
('pg_catalog.pg_pltemplate'), -- {463}
('pg_catalog.reltime'), -- {463}
('pg_catalog._reltime'), -- {463}
('pg_catalog.smgr'), -- {463}
('pg_catalog.tinterval'), -- {463}
('pg_catalog._tinterval') -- {463}
    )
    AND pa.attnum >0
UNION ALL
SELECT
    pgc.relnamespace::regnamespace
    ,pa.attrelid::regclass
    ,pa.attname
    ,pa.atttypid::regtype
    ,pgc.relkind::TEXT
FROM pg_catalog.pg_attribute pa
JOIN pg_catalog.pg_class pgc ON pa.attrelid =pgc.oid
JOIN pg_catalog.pg_type pt ON pt.oid=pa.atttypid
JOIN src ON pt.typrelid=src.attrelid
WHERE
    pa.attnum > 0
)
SELECT format('%1$s %2$I.%3$I.%4$I::%5$s '
        ,COALESCE(relk.relkind_desc,src.relkind)
        ,src.relnamespace::regnamespace::TEXT
        ,src.attrelid::regclass::TEXT
        ,src.attname::TEXT
        ,src.atttypid::regtype::TEXT
    )
FROM src
    LEFT JOIN
(VALUES
    ('r', 'Table'),
    ('i', 'Index'),
    ('S', 'Sequence'),
    ('t', 'TOAST'),
    ('v', 'View'),
    ('m', 'MatView'),
    ('c', 'CompositeType'),
    ('f', 'ForeignTable'),
    ('p', 'PartitionedTable'),
    ('I', 'PartitionedIndex'),
    ('G', 'GlobalIndex')
) AS relk(relkind, relkind_desc) using(relkind)
WHERE relnamespace::regnamespace::text !~ '^(information_schema|pg_)';

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

"{{ control_name }}.FAIL__E03007:В кандидате на обновление обнаружены нестандартные права или нестандартный владелец для объектов: {list_of_objects}. Восстановите права доступа или владельца перечисленных объектов, так как в новой версии СУБД они отсутствуют.__{{ control_name }}.FAIL"

Где list_of_objects - список объектов в БД с нестандартными правами/владельцем.

Проверка методов аутентификации в СУБД​

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

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

"{{ control_name }}.FAIL__E03008:При аутентификации в СУБД используются {list_of_methods} методы, которые перестанут работать после обновления СУБД, так как отсутствуют в enabled_extra_auth_methods = {enabled_extra_auth_methods}. Приведите все подключения к СУБД в соответствии с перечисленными в enabled_extra_auth_methods или добавьте {list_of_methods} в enabled_extra_auth_methods.__{{ control_name }}.FAIL"

Где:

  • list_of_methods - список методов аутентификации, присутствующих в СУБД;
  • enabled_extra_auth_methods - список допустимых методов аутентификации.

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

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

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

"{{ control_name }}.FAIL__E03070:В кандидате на обновление обнаружены неподдерживаемые параметры {list_of_deprecated_parameters} в конфигурационном файле {path_to_config} на хосте {inventory_hostname}. Для корректного обновления необходимо произвести удаление этих параметров.__{{ control_name }}.FAIL"

Где:

  • list_of_deprecated_parameters - список неподдерживаемых параметров;
  • path_to_config - путь до конфигурационного файла;
  • inventory_hostname - наименование узла стенда.

Проверка значения max_worker_processes​

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

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

"{{ control_name }}.FAIL__E03009:Минимально допустимое значение для max_worker_processess должно быть >= {needed_value}. Допущена ошибка в конфигурировании max_worker_processess. Измените данный параметр в конфигурационном файле.__{{ control_name }}.FAIL"

Где inventory_hostname - наименование узла стенда.

Где needed_value - минимально допустимое значение для параметра max_worker_processess.

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

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

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

"{{ control_name }}.FAIL__E03105:Обнаружено использование ссылки для указания местоположения табличного пространства в БД. Для работы скриптов обновления в базе данных необходимо указать реальные пути для всех табличных пространств. Список некорректных путей: {list_of_paths}__{{ control_name }}.FAIL"

Где list_of_paths - список некорректных путей до табличных пространств.

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

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

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

"{{ control_name }}.FAIL__E03071:В кандидате на обновление обнаружены неподдерживаемые параметры {parameter_names} в правилах pg_hba на хосте {inventory_hostname}. Для корректного обновления необходимо произвести удаление этих параметров.__{{ control_name }}.FAIL"

Где:

  • parameter_names - список неподдерживаемых параметров;
  • inventory_hostname - наименование узла стенда.

Проверки для обновления исполняемых файлов​

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

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

Выполняется проверка с помощью утилиты pg_inplace_upgrade.

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

"{{ control_name }}.FAIL__E03097:В процессе проверки наличия изменений в системном каталоге возникли ошибки: {error_stdout}. Запуск обновления невозможен. Перед повторным запуском сценария необходимо изучить список полученных ошибок, причиной может стать некорректная версия каталога или отсутствие прав на рабочие файлы утилиты в каталоге {path_to_catalog}.__{{ control_name }}.FAIL"

Где:

  • error_stdout - оригинальный текст ошибки утилиты pg_inplace_upgrade;
  • path_to_catalog - путь до каталога с рабочими файлами утилиты pg_inplace_upgrade.

Проверка наличия физических слотов репликации​

Производится проверка наличия физических слотов репликации.

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

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

Где:

  • inventory_hostname - наименование узла стенда;
  • name_tmp_slot - наименование физического слота репликации.

Вывод информационных сообщений процесса разведки​

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

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

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

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

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

Перед завершением работы скрипта-разведчика будет выведено следующее информационное сообщение:

"{{ control_name }}.INFO__I03002:На время обновления база данных будет недоступна. Обратите внимание при планировании работ.__{{ control_name }}.INFO"

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

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

{{ local_backup_path }}/scout_temp_data

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

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

"{{ control_name }}.INFO__
Оценка времени выполнения обновления СУБД Pangolin по результатам НТ:
а) Standalone конфигурация: 
   - 54 минуты (100 Gb СУБД Pangolin) 
   - 126 минут (500 Gb СУБД Pangolin) 
   - 309 минут (800 Gb СУБД Pangolin) 
б) Cluster конфигурация: 
   - 90 минут (100 Gb СУБД Pangolin) 
   - 359 минут (500 Gb СУБД Pangolin) 
   - 599 минут (800 Gb СУБД Pangolin) 
 
Характеристики серверов: 
a) Standalone, Active, Standby: 
   - ОС Red Hat Enterprise Linux Server release 7.9 (Maipo); 
   - CPU 16 ядер (Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz); 
   - RAM 128 Gb; 
   - Disk HDD 2000 Gb; 
   - Пропускная способность сети 10Gbit/s. 
б) Arbiter: 
   - ОС Red Hat Enterprise Linux Server release 7.9 (Maipo); 
   - CPU 2 ядра (Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz); 
   - RAM 2 Gb; 
   - Disk HDD 50 Gb; 
   - Пропускная способность сети 10Gbit/s. 
 
Сценарий нагрузочного тестирования: 
1) Обновление с версии pangolin 4.3.0 до версии pangolin 5.2.0 при нагруСУБД pangolin 100 tps 
2) Конфигурация серверов: 
   - cluster (cluster-patroni-etcd-pgbouncer); \
   - standalone (standalone-postgresql-pgbouncer).
3) Размер СУБД pangolin:
   - 100 GB;
   - 500 GB;
   - 800 GB;
4) Процент объема индексов в СУБД pangolin: 30-40%
__{{ control_name }}.INFO"

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

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

"{{ control_name }}.FAIL__E01008:В процессе работы скрипта произошла неожиданная ошибка: {}. Ознакомьтесь с логами.__{{ control_name }}.FAIL"

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

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

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

Вывод информационного сообщения об успешном завершении сценария проверки​

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

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

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