Обновление сервера GNUmed

Для тех, кто желает или нуждается в нем, доступна некоторая комплексная загрузка для процесса установки / обновления GNUmed в архиве devel.

Обновление базы данных GNUmed

Примените этот метод, если имеется база с данными пациентов, которую нужно сохранить. Не обновляйте рабочие базы данных на основе релизных кандидатов, поскольку изменения в структуре базы данных не будут завершены до официального выпуска, из-за чего любые дополнения или изменения, сделанные для пациентов (если база данных в версии "релиз-кандидат"), будут затем потеряны при официальном обновлении на последней официальной версии рабочей базы данных.

GNUmed обновит любую более раннюю базу данных только за один шаг, скажем, от v10 к v11, с несколькими одинарными шагами может быть сделано в сериях. Невозможно пропустить какие-либо шаги. В процессе обновления существующая база данных будет клонирована, а новая база данных создана из клона. Исходная база данных останется совершенно невредимой. Кроме того, при обновлении GNUmed попытается создать временную резервную копию (которая может быть довольно затратной по времени и дисковому пространству) для сохранности ваших важных данных. Только в этом случае, тем не менее, хорошей идеей будет сохранить вторую, самостоятельно созданную свежую полную резервную копию, как указано в Процедуры резервного копирования и восстановления данных.

Для того, чтобы загрузчик создал резервные копии при обновлениях, убедитесь, что следующая строка уже настроена в соответствующем месте в pg_hba.conf в соответствии с разделом ConfigurePostgreSQL:

Перед применением обновления

Можно узнать, какие версии базы данных GNUmed существуют в кластере сервера, через вход в psql (к примеру, с psql -d gnumed_v16 -U gm-dbo), и из сессии, введя \l в списке существующих баз, включая основную версию(и) базы данных GNUmed.

Далее, необходимо иметь в виду две группы требований:

  1. Для того, чтобы любое обновление было успешно:
    • оно должно применяться под root (или через sudo) И
    • пока идет обновление, пользователи не могут быть подключены к базе данных
    • для этой версии существующие имена таблиц/столбцов базы данных и типы должны совпадать с известными отпечатками "хеша" официального релиза
      • последний можно найти в [...]/client/pycommon/gmPG2.py
      • полный отпечаток ссылки можно найти в [...]/server/sql/vXX-vYY/gm_db-gnumed_vXX-fingerprint.txt
      • отпечаток базы данных для обновления может быть сгенерирован из скрипта python в [...]/server/ с помощью ./gm-fingerprint_db.py <gm-dbo-password>, т.е. ./gm-fingerprint_db.py gnumed_v16 gm-dbo
  2. Для "работы" (реального использования) базы данных
    • настоящим вы предупреждены, что извещены о мерах предосторожности, которые подробно излагаются ниже (см. "Final… ")

Общее локальное обновление (мультиплатформенное, Linux, MacOSX)

Используйте сценарий upgrade-db.sh с сервера архива или дерева VCS следующим образом:

upgrade-db.sh N N+1, где

Прежде, чем сделать его из копии VCS, проверьте (ls -al) для гарантии, что символическая ссылка Gnumed из .../gnumed/gnumed/ (того же уровня, что и каталог client) указывает на client/ (которым является: .../gnumed/gnumed/Gnumed -> .../gnumed/gnumed/client/).

Пример пошагового обновления, например, gnumed_v10 до gnumed_v11: 
sh upgrade-db.sh 10 11

Версии должны быть подряд. Повторите от соответствующей начальной (самая последняя работающая версия) до требуемой версии, например 
...
upgrade-db.sh 8 9
upgrade-db.sh 9 10
upgrade-db.sh 10 11
...

Debian/Ubuntu: стандартное обновление, использующее пакеты debian

Убедитесь, что вы получили установочный пакет gnumed-server, до которого нужно обновить. Для проверки используйте apt-cache policy gnumed-server. Учтите, что простая установка соответствующего пакета еще не означает, что база данных уже обновлена к новой версии. Это потому, что можно принять решение, когда действительно обновить базу данных.

Когда придет время для обновления, под root запустите следующую команду (которая уже установлена через пакет gnumed-server):

gm-upgrade_server N N+1

где

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

Debian, (*)buntu, SuSE, Mandriva: сетевое обновление

Этот сценарий обновит только с предыдущего до текущего официального релиза (и, опять же, это просто удобная оболочка общего обновления).

Windows

Предоставляется с программным обеспечением сервера (начиная с базы данных v7), является сценариями обновления базы данных, можно выбрать в меню Пуск Windows. Естественно, это просто ссылки на ту же процедуру, описанную выше.

Завершающее, но важное примечание к выпуску

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

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

Несмотря на возможное, будет необходимо применять исправление ошибки сценария SQL к запущенной базе данных время от времени. Такие сценарии представлены в каталоге server/sql/vN_vN+1/fixups/ пакета GNUmed-server.vN+1.x (скажем, GNUmed-server.v9.2). Для применения их используйте сценарий server/bootstrap/fixup-db.sh. Для вашего удобства сопровождающий пакет также может установить ярлык gm-fixup_server.

Для применения исправлений вручную выполните эти шаги на хосте базы данных (включая v9.2):

Это применит все исправления ошибок, и также зажурналирует (в таблице gm.schema_revision) имена файлов сценариев, которые были выполнены. В случае возникновения проблем, можно задать вопрос в список рассылки. Обратите внимание, что исправленные скрипты будут подготовлены только к исправлениям, которые разрешают официальные релизы (не во время процесса выпуска кандидатов). Это одна из причин для предупреждения не обновлять рабочие базы данных с помощью релиз кандидатов, как указано выше.