Общая логика обновления

Процедура обновления системы Юниверс DG представляет собой последовательность взаимосвязанных этапов, направленных на сохранение данных, обновление программных компонентов и проверку корректности работы системы после обновления. Обновление — это всегда баланс между рисками и необходимостью получить новые функции/исправления. Главная цель: сохранить данные и работоспособность системы.

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

  • базу данных (PostgreSQL),

  • поисковый индекс (OpenSearch),

  • прикладной уровень (Apache Tomcat и приложение Юниверс DG).

Каждый из этих компонентов имеет собственный жизненный цикл и обновляется отдельно. Обновление системы в целом представляет собой согласованное обновление этих компонентов с обязательным обеспечением возможности восстановления исходного состояния.

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

  • понимать назначение каждого этапа;

  • осознавать, какие данные изменяются, а какие должны быть сохранены;

  • иметь возможность восстановить систему в исходное состояние;

  • учитывать зависимости между компонентами системы.

На этой странице:

Этап 1. Подготовка к обновлению

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

На этом этапе требуется:

  1. Определить текущие версии PostgreSQL, OpenSearch, Tomcat и Юниверс DG.

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

  3. Экспортировать модель данных (при наличии такой возможности).

  4. Остановить сервер приложений Apache Tomcat.

Примечание

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

Этап 2. Резервное копирование

Цель этапа — обеспечить возможность полного восстановления системы в случае неудачного обновления.

2.1 Резервное копирование базы данных

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

При выполнении резервного копирования необходимо:

  • Удостовериться, что используется правильное имя базы данных.

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

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

  • Убедиться, что файл резервной копии создан и имеет ненулевой размер.

Важно

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

2.2 Резервное копирование поискового индекса

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

На этом этапе необходимо:

  1. Указать каталог репозитория снапшотов в конфигурации OpenSearch.

  2. Обеспечить доступность указанного каталога для всех узлов кластера.

  3. Перезапустить OpenSearch после внесения изменений.

  4. Зарегистрировать репозиторий снапшотов в кластере.

  5. Создать снапшот активных индексов.

При завершении операции следует убедиться, что состояние снапшота имеет статус SUCCESS.

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

2.3 Резервное копирование конфигурации

Необходимо создать резервные копии:

  • каталогов webapps, universe-integration, conf сервера Tomcat;

  • файла setenv.sh;

  • файла backend.properties;

  • файла universe-backend.xml (если он изменялся);

  • файлов пользовательских настроек интерфейса.

Предупреждение

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

Этап 3. Определение состава обновления

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

  • только приложение Юниверс DG;

  • приложение и база данных;

  • приложение и поисковый индекс;

  • вся инфраструктура целиком.

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

Этап 4. Обновление PostgreSQL (при необходимости)

Обновление версии PostgreSQL выполняется путём:

  1. Создания резервной копии базы данных.

  2. Установки новой версии PostgreSQL.

  3. Создания новой пустой базы данных.

  4. Восстановления данных из резервной копии.

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

После восстановления базы данных необходимо:

  • Перенести пользовательские параметры из старых файлов postgresql.conf и pg_hba.conf.

  • Перезапустить службу PostgreSQL.

  • Проверить логи сервиса на наличие ошибок.

Важно

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

Этап 5. Обновление OpenSearch (при необходимости)

При обновлении OpenSearch необходимо учитывать:

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

  • сохранение файлов синонимов и словарей Hunspell;

  • переустановку плагинов под новую версию.

После обновления OpenSearch следует:

  1. Запустить сервис.

  2. Проверить состояние кластера.

  3. Убедиться, что статус кластера является green.

Только после этого допускается подключение приложения к обновлённому поисковому индексу.

Этап 6. Обновление Apache Tomcat (при необходимости)

Обновление Apache Tomcat выполняется отдельно от обновления приложения Юниверс DG и может потребоваться в случае смены поддерживаемой версии сервера приложений.

При обновлении Tomcat необходимо:

  1. Установить новую версию Tomcat в отдельный каталог, не затрагивая текущую рабочую версию.

  2. Сохранить все пользовательские конфигурационные файлы:

    • server.xml,

    • web.xml,

    • context.xml,

    • файлы SSL-сертификатов,

    • файл setenv.sh.

  3. Перенести пользовательские настройки в новую версию Tomcat с учётом изменений в стандартных конфигурационных файлах.

  4. Обновить символическую ссылку или путь, используемый системой, на новую версию Tomcat.

  5. Проверить корректность прав доступа к каталогам Tomcat.

Следует учитывать совместимость версии Apache Tomcat с версией Юниверс DG. Использование неподдерживаемой версии сервера приложений может привести к некорректной работе системы. См. Системные требования.

Этап 7. Обновление приложения Юниверс DG

Обновление приложения выполняется путём:

  1. Очистки каталогов work, temp, webapps.

  2. Замены библиотек в каталоге lib новыми версиями.

  3. Копирования новых WAR-файлов приложения.

  4. Замены стандартных конфигурационных файлов на новые версии с переносом пользовательских параметров.

Примечание

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

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

  • Обновить права доступа на каталоги Tomcat.

  • Убедиться в наличии всех интеграционных файлов.

  • При наличии пользовательских доработок интерфейса перенести их в новую версию.

Этап 8. Обновление схемы базы данных

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

При этом:

  • Выполняется проверка состояния миграций.

  • При возникновении ошибок используется механизм восстановления миграций.

  • При невозможности устранения ошибок требуется обращение в техническую поддержку.

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

Этап 9. Проверка системы после обновления

После завершения всех этапов необходимо:

  1. Запустить сервер приложений Tomcat.

  2. Проверить логи приложения на наличие ошибок.

  3. Убедиться в успешном подключении к базе данных и поисковому индексу.

  4. Проверить доступность пользовательского интерфейса и основные сценарии работы.

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