Руководство по системному администрированию#

Сценарии администрирования#

Администрирование базы и схемы данных#

Все действия, приведенные в разделах, посвященных администрированию базы и схемы данных, выполняются администратором целевой базы данных компонента NSIX.

Создание пользователя и табличных пространств#

Для осуществления сценария «Создание пользователя и табличных пространств», необходимо выполнить следующие предварительные действия:

• установить на сервер БД компонент PSQL;

• установить на сервер БД pgBouncer;

• создать базу данных.

Выполните следующие действия:

1. Создать пользователя-владельца и схему mdmp (название можно выбрать иное), придумать и запомнить пароль.

     CREATE USER имя_пользователя WITH
     PASSWORD 'пароль_пользователя'
     LOGIN
     NOSUPERUSER
     INHERIT
     NOREPLICATION;
      
     CREATE SCHEMA имя_схемы AUTHORIZATION имя_пользователя;

2. Через sudo mkdir создать под пользователем операционной системы на любом свободном разделе NSIX папки табличных пространств:

   • mdmp_model_data;

   • mdmp_big_model_data;

   • mdmp_big_model_idx.

3. Задать владельца папки и группу владельца папки как Pangolin (PSQL) (название может отличаться).

     sudo mkdir путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске
     sudo mkdir путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске
     sudo mkdir путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске
     sudo mkdir путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске
     sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске
     sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске
     sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске
     sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске

4. Создать табличные пространства в базе данных:

     CREATE TABLESPACE mdmp_model_data OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске';
     CREATE TABLESPACE mdmp_big_model_data OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске';
     CREATE TABLESPACE mdmp_model_idx OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске';
     CREATE TABLESPACE mdmp_big_model_idx OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске';

5. Выдать пользователю права:

     GRANT CONNECT ON DATABASE имя_БД TO имя_пользователя;
     GRANT CREATE ON TABLESPACE mdmp_model_data TO имя_пользователя;
     GRANT CREATE ON TABLESPACE mdmp_big_model_data TO имя_пользователя;
     GRANT CREATE ON TABLESPACE mdmp_big_model_idx TO имя_пользователя;
     GRANT CREATE ON SCHEMA имя_схемы TO имя_пользователя;
      
     GRANT ALL PRIVILEGES ON SCHEMA имя_схемы TO имя_пользователя;
     GRANT USAGE ON SCHEMA имя_схемы TO имя_пользователя;
     GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA имя_схемы TO имя_пользователя;
     GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA имя_схемы TO имя_пользователя;

6. Создать роль MDMP_APPL_ROLE и пользователя MDMP_APPL для доступа к приложению без права удаления схемы. Выдать указанным пользователям права на БД и схему, созданные в предыдущем пункте.

     CREATE ROLE IF NOT EXISTS mdmp_appl_role WITH PASSWORD 'пароль_пользователя';
     GRANT CONNECT ON DATABASE имя_БД TO mdmp_appl_role;
     GRANT USAGE ON SCHEMA имя_схемы TO mdmp_appl_role;
     GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA имя_схемы TO mdmp_appl_role;
     GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA имя_схемы TO mdmp_appl_role;
       
     CREATE USER mdmp_appl
     WITH PASSWORD 'пароль_пользователя'
     LOGIN
     NOCREATEDB
     NOCREATEROLE
     NOSUPERUSER
     INHERIT
     IN ROLE MDMP_APPL_ROLE
     NOREPLICATION
     NOBYPASSRLS;
       
     GRANT CONNECT ON DATABASE имя_БД TO mdmp_appl;
     GRANT mdmp_appl_role TO mdmp_appl;
     ALTER ROLE mdmp_appl_role SET search_path TO имя_схемы;
     ALTER user mdmp_appl SET search_path TO имя_схемы;

Переименование схемы БД и смена владельца#

Переименование схемы БД осуществляется командой:

ALTER SCHEMA имя_схемы RENAME TO новое_имя_схемы;

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

ALTER SCHEMA имя_схемы OWNER TO имя_нового_пользователя;

Затем нужно сменить владельца всех таблиц и последовательностей схемы следующей процедурой:

DO $$
DECLARE
                query_line varchar(1000);
                rec RECORD;
                m_schemaName VARCHAR(100);
BEGIN
                m_schemaName := 'новое_имя_схемы';
                FOR rec IN (select PT.schemaname || '.' || PT.tablename TAB from pg_tables PT
                                                               where PT.schemaname = m_schemaName and PT.tableowner <> m_schemaName)
                LOOP
                               EXECUTE 'alter table if exists ' || rec.TAB || ' owner to '|| m_schemaName;
                END LOOP;
 
                FOR rec IN (select PS.schemaname || '.' || PS.sequencename SEQ from pg_sequences PS
                                                               where PS.schemaname = m_schemaName and PS.sequenceowner <> m_schemaName)
                LOOP
                               EXECUTE 'alter sequence if exists ' || rec.SEQ || ' owner to '|| m_schemaName;
                END LOOP;
END;
$$

Архивация dumps, копирование и восстановление#

В NSIX предусмотрена возможность:

• архивации dumps;

• копирования схемы с данными на другие серверы БД;

• создания копии текущей схемы БД;

• сохранения архива в целях резервирования.

Для осуществления операций из вышеприведенного списка следует использовать утилиты pg_dump и pg_restore. Утилиты необходимо запустить от имени администратора БД (PSQL).

Для создания dump в операционной системе от имени администратора БД следует использовать команду:

pg_dump --verbose --host=<имя_хоста> --port=<номер_порта> -d <имя_БД> --schema=<имя_схемы> --username=<имя_пользователя> --format=custom --file=/путь_к_файлу_dump

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

Рекомендуется использовать разделы /pgbackup или /pgarclogs.
Не рекомендуется использовать раздел /pgdata, где место требуется непосредственно для БД.

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

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

2. Создать пользователя-владельца для новой схемы.

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

4. Создать новую пустую схему БД.

5. Выдать права на вновь созданную схему исходному пользователю.

6. Произвести восстановление из dump на пустую схему с помощью команды:

  pg_restore --verbose --host=<имя_хоста> --port=5432 -d <имя_БД> --schema=<имя_схемы> --username=<имя_пользователя> /путь_к_файлу_дампа

Конфигурация сервера приложений среды контейнеризации для компонента NSIX#

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

Создание и настройка ролевых прав пользователей#

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

1. Войти в меню User Management — Role Bindings в среде контейнеризации.

2. Нажать кнопку Create Binding и связать роль с правами.

   • Имя роли (role) выбирается из списка доступных ролей. Если роли с нужными правами нет, она может быть создана в меню User Management — Roles.

   • Имя ролевой связки (binding) может быть любым. Для лучшей навигации рекомендуется указывать имя пользователя и роли.

   • Имя пользователя (username) указывается так же, как в необходимом домене.

Настройка параметров приложений#

Параметры приложений задаются в меню конфигураций среды контейнеризации: Workloads — Config Maps.

Для изменения настроек следует открыть файл YAML и отредактировать нужные конфигурации:

• nsix-cm-mdc — общие параметры приложений для внешних сервисов;

• nsix-cm-mdc-db — параметры схемы БД (кроме пароля);

• nsix-cm-mdc-ivs, nsix-cm-mdc-kmd, nsix-cm-mdc-jobs, nsix-cm-mdc-api — параметры конкретных модулей;

• nsix-cm-mdc-fluent-bit — параметры системы FluentBit в виде конфигурационного файла .conf, встроенного в YAML.

Настройки параметров secrets редактируются в разделе среды контейнеризации Workloads — Secrets. Используются secrets с переменными:

• JDBC.MDC_POSTGRES.PASSWORD — содержит пароль к БД;

• DBC.MDC_POSTGRES.USER — содержит имя пользователя.

В меню Config Maps среды контейнеризации модуля cm-mdc присутствуют параметры:

• OTHER_SERVER_TYPE — содержит имя стенда, на котором развертывается дистрибутив;

• OTHER_KMD_ENABLED— принимает значения:

  • true — если модуль mdc-kmd включен;

  • false — если модуль mdc-kmd отключен.

Получение токенов удаленного доступа#

Для удаленного доступа к пространству среды контейнеризации из внешних заданий Jenkins следует использовать токен сервис-аккаунта.

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

1. Войти в меню User management — Service Account.

2. Выбрать необходимый сервис-аккаунт (как правило, Jenkins).

3. Выбрать secret вида имя аккаунта — token в нижней части страницы сервис-аккаунта.

4. В разделе Data нажать кнопку Revel values и скопировать значение последнего поля token.

Запуск/Перезапуск#

После установки приложений их pods по умолчанию стартуют автоматически.

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

1. Войти в меню среды контейнеризации Workloads — Deployment Configs.

2. Открыть конфигурацию развертывания нужного модуля и выбрать один из вариантов:

   • отредактировать конфигурацию развертывания (это действие инициирует автоматический перезапуск);

   • во вкладке Replication Controllers удалить текущий контроллер реплик (это действие инициирует автоматическое создание нового контроллера с запуском нового pod);

   • в свернутом меню Actions выбрать Start rollout (это действие создаст новый контроллер без удаления старого).

3. Убедиться, что в разделе Workloads — Pods все pods egress/ingress (если он используется), а также pods модулей mdc-api, mdc-jobs, mdc-ivs, mdc-kmd, mdc-ui запущены (находятся в статусе Running) и не содержат ошибок, а pods с таким же именем и постфиксом deploy — завершены.

Конфигурация ролевой модели#

Все действия, описанные в текущем разделе, выполняются администратором целевой БД NSIX.

Файл с ролевой моделью NSIX включается в поставку NSIX и при развертывании прикладного проекта загружается в сервис авторизации AUTZ. Загрузка может быть осуществлена с помощью Pipeline, либо сотрудниками в web-интерфейсе сервиса AUTZ (в случае, если инструменты DevOps Pipeline не функционируют).

Загруженные привилегии могут быть включены в уже существующие в сервисе AUTZ наборы привилегий. Также для загруженных привилегий могут быть созданы новые наборы. Управление наборами привилегий осуществляется в web-интерфейсе сервиса AUTZ.

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

Настройка правил безопасности на граничных прокси (Ingress, Egress)#

Все входящие и исходящие соединения Компонента проходят через ingress/egress proxy. Для входящих/исходящих взаимодействий используется протокол mTLS 1.2.

Настройка защищенного сетевого взаимодействия осуществляется продуктом Platform V Synapse Service Mesh (SSM), основанным на Istio.

На egress proxy реализованы механизмы аутентификации и авторизации (для исходящих запросов) с использованием компонента OTTS продукта Platform V Backend (#BD).

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

1. Администратор прикладного модуля выполняет генерацию ключевой пары в p12-контейнере:

keytool -genkey -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -keysize 256 -dname
"CN=${module_id}" -alias ${module_id}

2. Администратор прикладного модуля формирует запрос на сертификат:

keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -alias ${module_id} > ${module_id}_cert_req.pem

3. В результате выполнения данной команды создается файл CSR — ${module_id}_cert_req.pem, который необходимо передать администратору компонента OTTS в заявке на генерацию сертификата для модуля.

События системного журнала#

За логирование отвечает компонент Журналирование (LOGA) продукта Platform V Monitor (OPM). Расположение системного журнала событий настраивается в LOGA. Подробности настройки приведены в документации к LOGA.

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

• FATAL — критические ошибки, при которых невозможна работа приложения.

• ERROR — информация об ошибках в работе приложения. Ошибки данного уровня можно разделить на следующие типы:

  • ошибки вызова компонентов платформы;

  • ошибки интеграционных вызовов.

• WARNING — предупреждения.

• INFO — информация о работе приложения и текущем состоянии процессов.

• DEBUG — подробности о работе приложения, позволяющие восстановить последовательность выполнения операций при обслуживании вызовов и вызовах внешних систем.

• TRACE — подробные записи о действиях приложения. Нужны в исключительных случаях для отладки.

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

Интеграция с LOGA позволяет выполнять в централизованной системе хранения лог-файлов LOGA следующие операции:

• сбор лог-файлов прикладных модулей NSIX;

• предварительную обработку лог-файлов прикладных модулей NSIX;

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

• хранение лог-файлов прикладных модулей NSIX;

• поиск лог-файлов прикладных модулей NSIX;

• просмотр лог-файлов прикладных модулей NSIX.

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

События ротации secrets приведены в таблице ниже:

Чтобы изменить уровень логирования, администратору необходимо:

1. Войти в консоль администрирования облачной среды.

2. Выбрать проект, в котором развернут NSIX.

3. Выбрать Deployment-модуль, уровень логирования которого необходимо изменить.

4. Перейти в терминал pod и выполнить команду:

curl localhost:8081/actuator/loggers

5. В консоли будут выведены группы пакетов, уровень логирования которых можно изменить. Пример запроса для изменения уровня логирования SQL-запросов:

curl -i -X POST -H 'Content-Type: application/json' -d '{"configuredLevel": "DEBUG"}' http://localhost:8081/actuator/loggers/sql

События мониторинга#

Все прикладные модули NSIX публикуют метрики по стандарту мониторинга Prometheus. Метрики доступны для сбора системой мониторинга через HTTP-endpoint/actuator/prometheus. Сбор и отправка метрик выполняется с использованием подключаемого клиентского модуля компонента MONA продукта Platform V Monitor (OPM).

Основные метрики мониторинга приведены в таблице ниже:

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

Мониторинг ротации secrets приведен в таблице ниже:

Часто встречающиеся проблемы и пути их устранения#

Действия при ошибках запуска приложений Компонента#

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

Действия при ошибках запуска pods#

Если pods нет, необходимо убедиться, что создана конфигурация развертывания в среде контейнеризации (в разделе Workloads — Deployment Configs). В настройках необходимо нажать кнопку Start Rollout. Если конфигурация не создана, нужно повторить процедуру ее установки и при наличии ошибок при автоустановке проверить журнал и попытаться установить нужный YAML-файл вручную.

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

• Некорректная ссылка на Docker-образ;

• Ошибка JDBC-соединения на стадии запуска;

• Некорректная модель БД;

• Отсутствие параметра конфигурации и т.д.

Необходимо убедиться, что:

• в настройках конфигурации развертывания указана ссылка на существующий Docker-образ с существующего сайта;

• в параметрах корректно указано имя secret, содержащего данные хоста хранилища Docker-образов;

• secret с данными Docker-образов создан и содержит корректные логин и пароль.

Затем перейти в раздел Pods и проследить за появлением pods имя-модуля-deploy и имя-модуля. При возникновении ошибки необходимо перейти в журнал в течение 1 минуты (далее pods автоматически удаляется) и, скопировав сообщение из лог-файла, проанализировать ошибку и действовать исходя из ее типа.

JDBC Error#

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

• Некорректные параметры в конфигураторе (например, неправильный логин и пароль);

• Просроченный пароль учетной записи;

• Незапущенная БД.

В первую очередь следует проверить параметры конфигураций БД (nsix-cm-mdc-db) в разделе среды контейнеризации Config Maps и убедиться, что в параметрах указаны верные диалект и драйвер СУБД, схема, адрес БД, логин и init-запросы. Также необходимо проверить пароль в secret nsix-secret-mdc-db (secret-mdc-unver, где -unver — номер версии по умолчанию).

Если параметры заданы неверно, их следует исправить в консоли среды контейнеризации и связанных заданиях Jenkins, после чего перезапустить pods (например, изменив файл DeploymentConfig или удалив текущий Replication Controller — новый стартует автоматически).

Если же параметры заданы верно, а соединиться с БД из внешней программы не удается из-за проблем с паролем, следует перезапустить БД/сбросить блокировку/сменить пароль при наличии доступа, а при его отсутствии — запросить у администратора БД.

Pods запущены, но приложения не отображаются#

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

1. Перейти в Networking-Routes.

2. Проверить работоспособность интерфейса.

3. Проверить отсутствие ошибок с помощью маршрута no-ingress.

Если компонент AUTH продукта Platform V IAM SE (IAM) не настроен или не подключен, можно временно создать маршрут No-ingress вручную на основе следующего YAML-файла:

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: route-mdc-no-ingress
  labels:
    shard: default
spec:
  host: no-ingress.mdc.apps.название_кластера.название_домена
  to:
    kind: Service
    name: svc-mdc-ui
    weight: 100
  port:
    targetPort: http-8080
  wildcardPolicy: None

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

Действия при ошибках отправки событий в AUDT#

При появлении сообщения об ошибке отправки данных в компонент AUDT продукта Platform V Audit SE (AUD) необходимо проверить настройки, отвечающие за интеграцию с AUDT.

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

1. Открыть консоль среды контейнеризации в режиме Администратора.

2. Открыть сущность ConfigMap nsix-cm-mdc.

3. Проверить, задано ли значение для системной переменной AUDIT_HOST. Если системная переменная отсутствует или содержит некорректное значение (например, недопустимый хост для приема события компонентом AUDT, то необходимо запросить актуальный хост у сотрудников поддержки AUDT и актуализировать значение системной переменной AUDIT_HOST.

Действия при ошибках интерфейса#

Прикладной интерфейс не отображается#

Обычно причиной такой ошибки служит неверно указанный порт или контекст в AUTH или в прокси-сервере.

Следует выполнить следующие действия:

1. Проверить, что модуль mdc-ui запущен.

2. Проверить, что в адресной строке правильно указан порт и корневой контекст.

3. Проверить значения параметров ссылок на приложения mdc.

4. Проверить работоспособность компонента AUTH (проверить корректность параметров подключения к сервису).

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

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

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

При наличии проблем с БД — на главном экране выводится сообщение только при проблемах в модуле mdc-ivs. Во всех остальных случаях ошибка выводится при переходе в меню модуля.

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

• mdc-ivs, если ошибка выводится на главном экране, либо в меню Справочники и Версии справочников;

• mdc-kmd, если ошибка выводится в меню Конструктор модели данных;

• mdc-jobs, если ошибка выводится в меню Регламентные задания.

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

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

При наличии ошибки в БД следует проверить соединение и установить через liquibase последние patches. Если соединение не работает, администратору следует проверить состояние запуска БД и pgbouncer и при необходимости перезапустить (при отсутствии прав — запросить администратора).

В некоторых случаях крах БД может быть вызван переполнением раздела с табличным пространством (по умолчанию — /pgdata), который в этом случае следует очистить или расширить за счет других свободных разделов.

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

Действия при отказах технических средств#

В случае отказа какого-либо технического средства на активном плече кластера БД или сервера приложений — кластерное ПО автоматически переключит работу на неактивное плечо кластера.

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

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

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

Действия в случаях обнаружения несанкционированного вмешательства в данные#

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

С целью предотвращения несанкционированного вмешательства в данные до устранения проблемы рекомендуется остановить сервер приложений и сервер БД NSIX.

Регламентные работы и работы по восстановлению#

Откат компонента NSIX#

Для отката компонента NSIX к ранним версиям ПО после установки обновлений в самом простом случае достаточно изменить хеш-код sha256 текущего Docker-образа в строке image в конфигурационных файлах:

• nsix-mdc-iv;

• nsix-mdc-jobs;

• nsix-mdc-kmd;

• nsix-mdc-ui;

• nsix-mdc-api.

В более сложных случаях, если требуется изменить настройки Deployment Config и Config Maps на более ранние (например, если ранняя версия содержала ныне удаленную переменную), следует удалить текущую версию.

В самом сложном общем случае, если были глобальные изменения (такие, как переименование сущностей YAML), требуется удалить все объекты YAML в среде контейнеризации, относящиеся к NSIX, а затем установить их из старого дистрибутива.

Откат БД#

Для отката системы к БД более ранней версии NSIX необходимо восстановить БД из созданной ранее резервной копии. Создание резервной копий данных и восстановление данных из резервной копии выполняется штатными утилитами (средствами) администрирования БД, такими как pg_dump и pg_restore соответственно. Информация об их использовании приведена в разделе «Архивация dumps, копирование и восстановление» настоящего документа.

Действия при ошибках работы API#

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

Ошибка выполнения POST запроса org.springframework.web.client.ResourceAccessException: I/O error on POST request for
"localhost:8080/mdc-api/rn/DEFAULT_TENANT/dictionary-version/content": Broken pipe (Write failed); 

Для решения проблемы необходимо увеличить значение параметра MULTIPART_MAX_UPLOAD_SIZE в конфигурации проекта. По умолчанию данный параметр принимает значение в 16 Мб.

Прерывание Регламентного задания при поступлении данных из DDIS#

При поступлении данных из DDIS регламентное задание Импорт данных в формате TR может прерываться с ошибкой сохранения записей:

Caused by: java.sql.BatchUpdateException: Batch entry 0 delete from mdmp_cloud.a_dict_version_ref where id=432361817315 was aborted: ERROR: could not access status of transaction 0
Detail: Could not write to file "pg_subtrans/0A44" at offset 122880: No space left on device.  
Call getNextException to see other errors in the batch.
at org.postgresql.jdbc.BatchResultHandler.handleError(BatchResultHandler.java:165)

Причина ошибки в переполнении таблицы БД mdmp_cloud.apikeyvalue_ai.

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

1. Выполнить очистку ФС от backs.

2. Выполнить vacuum full.

Ошибка при загрузке файлов в модуле Регламентных заданий#

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

ошибка: org.springframework.batch.item.NonTransientResourceException: Error while reading from event reader
trace: org.springframework.batch.item.NonTransientResourceException: Error while reading from event reader
Caused by: com.ctc.wstx.exc.WstxIOException: Invalid ascii byte; value above 7-bit ascii range (65496; at pos #128)
	at com.ctc.wstx.sr.StreamScanner.constructFromIOE(StreamScanner.java:633)
Caused by: java.io.CharConversionException: Invalid ascii byte; value above 7-bit ascii range (65496; at pos #128)
	at com.ctc.wstx.io.AsciiReader.reportInvalidAscii(AsciiReader.java:133)

Для решения проблемы необходимо в параметре JAVA_OPTS добавить настройку -Dfile.encoding=UTF-8.

Ошибка отображения записей при выполнении атрибутного поиска в справочнике «Перечень ПДЛ Interfax»#

При открытии атрибутного поиска в справочнике Перечень ПДЛ Interfax по версиям в статусе «Действует» возникает ошибка отображения code: SERVER_400_ERROR.

Ошибка может возникать из-за указания неверного типа гео-балансировки (при условии использования гео-балансировки). Необходимо изменить тип гео-балансировки на стенде с roundrobin на phash.

Рекомендуется обратиться к документации гео-балансировщика.