Краткая инструкция по автоматизированной установке «PG-патчей»

Общая идея.
Для тестирования системы ЦАБС «Банк 21 Век» на импортозамещенной БД Postgres Pro (далее PG) предполагается предварительно установить дамп серверной части системы в банке, а далее регулярно устанавливать патчи – обновление системы, чтобы поддерживать базу в актуальном состоянии. PG-патчи регулярно выпускаются разработчиками и включают только обновление серверной части. Клиентская часть системы на PG считается идентичной клиентской части системы на Oracle (например, джарики), и как следствие - новые файлы клиентской части в PG-патчи не входят. Например, если банк получил дамп включающий все обновления на 01-06-2025, то и клиентскую часть банк должен использовать соответствующую 01-06-2025 (должна быть поставлена в банк вместе с дампом). Альтернатива – после установки дампа «снятого» на 01-06-2025 провести установку всех PG-патчей с 01.06.2025, например, до 14.07.2025 (последнего PG-патча) и получить от Исполнителя соответствующую 14.07.2025 клиентскую часть или обновление клиентской части с 01.06.2025 до 14.07.2025. Текущая технология установки обновлений на инсталляционную базу предполагает фиксацию состояния клиентской части на последнее успешно установленное обновление.
Технология обновления серверной части системы на PG по аналогии с обновлением серверной части системы на Oracle предполагает последовательный запуск скриптов runme_pg.sql (аналог runme.sql) в папках Convert, Stored и.т.д., но есть нюансы, см. ниже.
Введение.
Технология обновления PG-базы отличается от технологии обновления базы-oracle:

  1. Повторный запуск pg-скриптов считается нештатным вариантом;
  2. При возникновении ошибки при первом прогоне конкретного скрипта необходимо запустить его повторно, если ошибка осталась, то скрипт необходимо запустить третий раз;
  3. Если ошибка прогона конкретного скрипта не ушла после третьего прогона, то установку последующих скриптов не выполнять до устранения ошибки;
  4. Если необходимо повторно запустить pg-скрипты (не путать с ситуацией, когда скрипт запускается повторно, когда при первом его запуске были ошибки), то возможно придётся править исходный код скрипта;
  5. Под «pg-патчам» (на текущий момент) будут считаться скрипты обновления серверной части, разложенные разработчиками по датам создания;



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

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


В этом случае считается, что до 25-04-14 включительно все скрипты обновления успешно установлены или дамп pg-базы включает обновление серверной части до 25-04-14.
«25-04-15», «25-04-16», «25-04-17» - будем считать pg-патчами. Тогда, например, если при установке скриптов pg-патча «25-04-15» возникли ошибки в «convert», то если после третьего прогона ошибка в «convert» не ушла, то «stored» устанавливать нельзя и нужно ит-сотрудникам банка устранять причину ошибки в «convert».


Автоматизация запуска. «Робот» установки.
Для запуска скриптов используются cmd-файлы, которые для простоты обновления могут запускаться «роботом», т.е. автоматически. Необходимо поверить на одном pg-патче обновление тестовой версии. Если все логи обновления (runme_pg.err, «inv-импорт».log) будут без ошибок («already exists» игнорируется, как ошибка), то можно устанавливать серию pg-патчей. Для этого копируем папки (pg-патчи) в указанную по путям директорию (в примерах ниже используется путь к D:\UPDATE_PG):


…

Важно, что в _pusk.bat описаны все set-ы, пути, логины, пароли, которые должны быть установлены. Будьте внимательны!

В папке FILE_DI_LAVORO лежат служебные файлы их править не нужно (исключение stop_path.txt см. ниже).
Важное исключение – это файл pgpass.conf, который должен быть строго тут: %APPDATA%\postgresql\pgpass.conf

Например:
pgpro.corp.inversion.ru:5432:pgdev:XXI:qqq
pgnew.corp.inversion.ru:5432:pgmax:XXI:qqq
pgnew.corp.inversion.ru:5432:pgnew:XXI:qqq
pgpro.corp.inversion.ru:5432:pgdev:mail_sys:mail_sys
pgnew.corp.inversion.ru:5432:pgmax:MAIL_SYS:mail_sys
pgnew.corp.inversion.ru:5432:pgnew:mail_sys:mail_sys
где, например, настроено соединение для трёх баз и двум схемам – XXI, mail_sys и соответственно пароль будет прочитан из данного конфигурационного файла.

Запуск установки скриптов из папки «UPD_PGNEW» (SET UPD_PATH=D:\UPD_PGNEW) _pusk.bat:

Все логи ошибок по указанным датам пустые (нулевой размер файла – ошибок нет):


Установленные pg-патчи перенесены в папку:


В файл stop_path.txt добавлены скопированные pg-патчи и из папки UPDATE_PG уже копироваться для установки не будут. Соответственно, если бы были ошибки и нужно было бы после устранения ошибок повторно запустить установку, то в stop_path.txt нужно было бы удалить соответствующие строки.
Проверка готовности.
В папке UPD_PGNEW\LA_PROVA\PG_PASSO_123_pusk.cmd – это тестовый батник, который рекомендуется настроить (см. содержимое) и запустить. Если все указанные проверки будут успешно пройдены, то можно переходить непосредственно к установке pg-патчей.
В папке RUNME_LOG создается директория «дата_время» запуска _pusk.bat. Создаются логи:

  • copy_bjju.log
  • copy_path.log
  • file_ddmmyy.log

copy_bjju.log – это лог обновления клиентской части, т.е. протокол копирования новых файлов из папок BIN, JAPP, JLIB, UFS. Пути к «источнику новых файлов» и к обновляемой клиентской части см. тут в _pusk.bat (по умолчанию отключено):

  • SET PG_CLIENT_NEW=W:\ODB\BANK_8I
  • SET PG_CLIENT_OLD=D:\UPDATE_PG_CLIENT

copy_path.log – это лог скопированных для обновления pg-патчей
file_ddmmyy.log – это лог проверки не взятых в работу скриптов, например, если обновление запущено 10 апреля, то не должно остаться старых логов за даты меньше 10-го апреля. Этот факт будет означать, что какие-то скрипты пропущены и не пересозданы. Как следствие из написанного – старые файлы runme_pg.err не нужно удалять из pg-патчей.
UPD_PGNEW\LA_PROVA\PG_PASSO_4\ pg_run.bat – тест № 4. Запустить pg_run.bat, должны увидеть нулевой runme_pg.err, runme_pg.log с успешным сообщением создания проверочной таблицы. Поменяйте пути в psql_pgnew.cmd, базу, host.

  • Нет меток