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

Внимание!

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

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

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

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

Данные должны содержать те же параметры, что и при установке. Примеры заполнения файлов описаны в разделе «Автоматизированная установка при помощи Ansible-плейбука».
Заполните настраиваемый конфигурационный файл custom_file_sample.yml.
Заполните конфигурационный файл all.yml.
Чтобы удостовериться в готовности к обновлению, используйте 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=${}"
```
Далее приведены шаблоны сценариев для различных решений:
для cluster-конфигурации для решения standalone
ansible-playbook playbook_scouting.yaml \ -i inventories/cluster/hosts.ini \ -t always,cluster \ --ask-vault-pass \ -vv \ --extra-vars "local_distr_path=${} \ custom_config=${}" \
ansible-playbook playbook_scouting.yaml \ -i inventories/standalone/hosts.ini \ -t always,standalone \ --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 — расшифровка зашифрованных файлов во время выполнения.
  
  Внимание!
  
  Для шифрования паролей в примерах выше, использовался следующий ansible-vault пароль: postgreSQL_SE_654321.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pg_current_version;
PGDATA_OLD;
PGHOME_OLD;
PGPORT_OLD;
PGBOUNCERPORT_OLD;
CLNAME_OLD;
PGHOME_OLD_NAME.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

not_support_type_installed_configuration: ['standalone-postgresql-only']

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

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

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

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

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

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

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

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

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

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

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

Для типов update_complexity_level_2/update_complexity_level_3 выполняется проверка размера СУБД. Если размер СУБД больше чем задано в параметре maximum_dbms_size_to_update (параметр максимальный размер СУБД для обновления в настраиваемом конфигурационном файле), то выводится блокирующая дальнейшее выполнение сценария ошибка:
```
{{ control_name }}.FAIL__Автоматическое обновление ограничено размером кластера СУБД в maximum_dbms_size_to_update Гб. Текущая СУБД имеет размер current_dbms_size Гб.__{{ control_name }}.FAIL
```
Для типов update_complexity_level_2/update_complexity_level_3 и полного внутреннего резервного копирования данных проверяется наличие на active каталога local_backup_path (путь для локального резервного копирования), задающийся в настраиваемом конфигурационном файле или переданным на вход скрипта в виде extra vars. Если отсутствует, то выводится блокирующая дальнейшее выполнение сценария ошибка:
```
{{ control_name }}.FAIL__Не найден каталог /pgarclogs, указанный в параметре local_backup_path.__{{ control_name }}.FAIL
```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SELECT format('{{ item.datname }}.%1$s.%2$s',nspname,extname) extname FROM pg_catalog.pg_extension ex
JOIN pg_namespace ns ON ex.extnamespace =ns.oid
WHERE ex.extname not in ({{ _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, не поддерживаются скриптами автоматического обновления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример информационного сообщения:

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

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

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

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

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

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

Пример информационного сообщения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{ local_backup_path }}/scout_temp_data

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

{{ local_backup_path }}/scout_temp_data`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка состояния близости БД к порогу заморозки транзакций 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
Список таблиц:
{}.WARNING

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

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

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

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

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