<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en_US" lang="en_US"> <head> <title> GmManualServerUpgradeRu < Gnumed < Foswiki</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta name="robots" content="noindex" /> <link rel="alternate" type="application/rss+xml" title="RSS Feed" href="WebRss.html" /> <link rel="icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" /> <link rel="shortcut icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" /> <link rel="alternate" href="http://wiki.gnumed.de/bin/edit/Gnumed/GmManualServerUpgradeRu?t=1362919418" type="application/x-wiki" title="edit GmManualServerUpgradeRu" /> <meta name="description" content="GmManualServerUpgradeRu" /> <!--[if IE]></base><![endif]--> <style type="text/css" media="all"> @import url('../rsrc/System/SkinTemplates/base.css'); </style> <style type="text/css" media="all"> @import url('../rsrc/System/SkinTemplates/default.css'); </style> <!--[if IE]><style type="text/css" media="screen"> pre { overflow-x:auto; padding-bottom:expression(this.scrollWidth > this.offsetWidth ? 16 : 0); } </style> <![endif]--> <meta name="foswiki.PUBURL" content="http://wiki.gnumed.de/pub" /> <!-- PUBURL --> <meta name="foswiki.PUBURLPATH" content="/pub" /> <!-- PUBURLPATH --> <meta name="foswiki.SCRIPTSUFFIX" content="" /> <!-- SCRIPTSUFFIX --> <meta name="foswiki.SCRIPTURL" content="http://wiki.gnumed.de/bin" /> <!-- SCRIPTURL --> <meta name="foswiki.SCRIPTURLPATH" content="/bin" /> <!-- SCRIPTURLPATH --> <meta name="foswiki.SERVERTIME" content="10%20Mar%202013%20-%2013:43" /> <!-- SERVERTIME --> <meta name="foswiki.SKIN" content="twikinet%2c%20pattern" /> <!-- SKIN --> <meta name="foswiki.SYSTEMWEB" content="System" /> <!-- SYSTEMWEB --> <meta name="foswiki.TOPIC" content="GmManualServerUpgradeRu" /> <!-- TOPIC --> <meta name="foswiki.USERNAME" content="KarstenHilbert" /> <!-- USERNAME --> <meta name="foswiki.USERSWEB" content="Main" /> <!-- USERSWEB --> <meta name="foswiki.WEB" content="Gnumed" /> <!-- WEB --> <meta name="foswiki.WIKINAME" content="KarstenHilbert" /> <!-- WIKINAME --> <meta name="foswiki.WIKIUSERNAME" content="Main.KarstenHilbert" /> <!-- WIKIUSERNAME --> <meta name="foswiki.NAMEFILTER" content="%5b%5cs%5c*%3f~%5e%5c%24%40%25%60%22'%26%3b%7c%3c%3e%5c%5b%5c%5d%23%5cx00-%5cx1f%5d" /> <!-- NAMEFILTER --><!--JQUERYPLUGIN::FOSWIKI::META--> <script type='text/javascript' src='../rsrc/System/JQueryPlugin/jquery-1.4.3.js'></script><!--JQUERYPLUGIN--> <script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/livequery/jquery.livequery.js'></script><!--JQUERYPLUGIN::LIVEQUERY--> <script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js'></script><!--JQUERYPLUGIN::FOSWIKI--> <script type='text/javascript' src='../rsrc/System/JSTreeContrib/jquery.jstree.js'></script><!--JQUERYPLUGIN::JSTREE--> </head> <body class=""><div class="foswikiPage"> <a name="PageTop"></a> <p></p> <p></p> <h1><a name="GNUmed"></a> Обновление сервера GNUmed </h1> <p></p> <a name="foswikiTOC"></a><div class="foswikiToc"> <ul> <li> <a href="#A_"> Перед применением обновления </a> </li> <li> <a href="#A_40_44_Linux_44_MacOSX_41"> Общее локальное обновление (мультиплатформенное, Linux, MacOSX) </a> </li> <li> <a href="#Debian_47Ubuntu:_44_debian"> Debian/Ubuntu: стандартное обновление, использующее пакеты debian </a> </li> <li> <a href="#Debian_44_40_42_41buntu_44_SuSE_44_Mandriva:"> Debian, (*)buntu, SuSE, Mandriva: сетевое обновление </a> </li> <li> <a href="#Windows"> Windows </a> </li> <li> <a href="#A_44"> Завершающее, но важное примечание к выпуску </a> </li> <li> <a href="#A_AN1"> Применение исправления ошибок в работающих базах данных </a> </li></ul> </div> <p></p> Для тех, кто желает или нуждается в нем, доступна некоторая комплексная загрузка для процесса установки / обновления GNUmed в <a href="http://lists.gnu.org/archive/html/gnumed-devel/2010-01/msg00002.html" target="_top">архиве</a> <em>devel</em>. <p></p> <h2><a name="GNUmed_AN1"></a> Обновление базы данных GNUmed </h2> <p></p> Примените этот метод, если имеется база с данными пациентов, которую нужно сохранить. <strong>Не</strong> обновляйте рабочие базы данных на основе релизных кандидатов, поскольку изменения в структуре базы данных не будут завершены до официального выпуска, из-за чего любые дополнения или изменения, сделанные для пациентов (если база данных в версии "релиз-кандидат"), будут затем потеряны при официальном обновлении на последней <em>официальной версии</em> рабочей базы данных. <p></p> GNUmed обновит любую более раннюю базу данных только за один шаг, скажем, от v10 к v11, с несколькими одинарными шагами может быть сделано в сериях. Невозможно пропустить какие-либо шаги. В процессе обновления существующая база данных будет клонирована, а новая база данных создана из клона. Исходная база данных останется совершенно невредимой. Кроме того, при обновлении GNUmed попытается создать временную резервную копию (которая может быть довольно затратной по времени и дисковому пространству) для сохранности ваших важных данных. Только в этом случае, тем не менее, хорошей идеей будет сохранить вторую, самостоятельно созданную свежую полную резервную копию, как указано в <a href="GmManualDatabaseBackupRestore.html">Процедуры резервного копирования и восстановления данных</a>. <p></p> Для того, чтобы загрузчик создал резервные копии при обновлениях, убедитесь, что следующая строка уже настроена в соответствующем месте в <code>pg_hba.conf</code> в соответствии с разделом <a href="ConfigurePostgreSQL.html">ConfigurePostgreSQL</a>: <p></p> <ul> <li> <code>local samegroup +gm-logins md5</code> </li></ul> <p></p> <h3><a name="A_"></a> Перед применением обновления </h3> <p></p> Можно узнать, какие версии базы данных GNUmed существуют в кластере сервера, через вход в psql (к примеру, с <code>psql -d gnumed_v16 -U gm-dbo</code>), и из сессии, введя <code>\l</code> в <em>списке</em> существующих баз, включая основную версию(и) базы данных GNUmed. <p></p> Далее, необходимо иметь в виду две группы требований: <p></p> <ol> <li> Для того, чтобы любое обновление было успешно: <ul> <li> оно должно применяться под <em>root</em> (или через <em>sudo</em>) И </li> <li> пока идет обновление, пользователи не могут быть подключены к базе данных </li> <li> для этой версии существующие имена таблиц/столбцов базы данных и типы должны совпадать с известными отпечатками "хеша" официального релиза <ul> <li> последний можно найти в [...]/client/pycommon/gmPG2.py </li> <li> полный отпечаток ссылки можно найти в [...]/server/sql/vXX-vYY/gm_db-gnumed_vXX-fingerprint.txt </li> <li> отпечаток базы данных для обновления может быть сгенерирован из скрипта python в [...]/server/ с помощью <code>./gm-fingerprint_db.py <gm-dbo-password></code>, т.е. <code>./gm-fingerprint_db.py gnumed_v16 gm-dbo</code> </li></ul> </li></ul> </li> <li> Для "работы" (реального использования) базы данных <ul> <li> настоящим вы <strong>предупреждены</strong>, что извещены о мерах предосторожности, которые подробно излагаются ниже (см. "Final… ") </li></ul> </li></ol> <p></p> <h3><a name="A_40_44_Linux_44_MacOSX_41"></a> Общее локальное обновление (мультиплатформенное, Linux, MacOSX) </h3> <p></p> Используйте сценарий <code>upgrade-db.sh</code> с сервера архива или дерева VCS следующим образом: <p></p> <code>upgrade-db.sh N N+1</code>, где <p></p> <ul> <li> <code>N</code>: существующая версия базы данных, нуждающаяся в обновлении </li> <li> <code>N+1</code>: версия базы данных, до которой необходимо обновить </li></ul> <p></p> Прежде, чем сделать его из копии VCS, проверьте (<code>ls -al</code>) для гарантии, что символическая ссылка <code>Gnumed</code> из <code>.../gnumed/gnumed/</code> (того же уровня, что и каталог <code>client</code>) указывает на <code>client/</code> (которым является: <code>.../gnumed/gnumed/Gnumed -> .../gnumed/gnumed/client/</code>). <p></p> Пример пошагового обновления, например, gnumed_v10 до gnumed_v11: <pre> sh upgrade-db.sh 10 11 </pre> <p></p> Версии <strong>должны</strong> быть подряд. Повторите от соответствующей начальной (самая последняя работающая версия) до требуемой версии, например <pre> ... upgrade-db.sh 8 9 upgrade-db.sh 9 10 upgrade-db.sh 10 11 ... </pre> <p></p> <h3><a name="Debian_47Ubuntu:_44_debian"></a> Debian/Ubuntu: стандартное обновление, использующее пакеты debian </h3> <p></p> Убедитесь, что вы получили установочный пакет <code>gnumed-server</code>, до которого нужно обновить. Для проверки используйте <code>apt-cache policy gnumed-server</code>. Учтите, что простая установка соответствующего пакета еще не означает, что база данных уже обновлена к новой версии. Это потому, что можно <strong>принять решение</strong>, когда действительно обновить базу данных. <p></p> Когда придет время для обновления, под <code>root</code> запустите следующую команду <em>(которая уже установлена через пакет <code>gnumed-server</code>)</em>: <p></p> <code>gm-upgrade_server N N+1</code> <p></p> где <p></p> <ul> <li> <code>N</code>: существующая версия базы данных, нуждающаяся в обновлении </li> <li> <code>N+1</code>: версия базы данных, до которой необходимо обновить </li></ul> <p></p> просто, как и в общей процедуре обновления (фактически, вышеуказанная команда, но удобная надстройка общего способа). <p></p> <h3><a name="Debian_44_40_42_41buntu_44_SuSE_44_Mandriva:"></a> Debian, (*)buntu, SuSE, Mandriva: сетевое обновление </h3> <p></p> <ul> <li> скачайте <a href="http://gitorious.org/gnumed/gnumed/blobs/master/gnumed/gnumed/server/gm-net_upgrade_server.sh" target="_top">скрипт сетевой установки</a> </li> <li> убедитесь, что файл является исполняемым </li> <li> под <em>root</em> или с <em>sudo</em> запустите файл <code>net_upgrade-gnumed_server.sh</code> <ul> <li> да, установка общесистемного пакета, обычно, выполняется под root </li> <li> можно проверить файл bogosities перед его запуском </li></ul> </li></ul> <p></p> Этот сценарий обновит только с предыдущего до текущего официального релиза (и, опять же, это просто удобная оболочка общего обновления). <p></p> <h3><a name="Windows"></a> Windows </h3> <p></p> Предоставляется с программным обеспечением сервера (начиная с базы данных v7), является сценариями обновления базы данных, можно выбрать в меню Пуск Windows. Естественно, это просто ссылки на ту же процедуру, описанную выше. <p></p> <h3><a name="A_44"></a> Завершающее, но важное примечание к выпуску </h3> <p></p> Поскольку старые версии клиента продолжат предоставлять доступ к старой базе данных, <strong>определенно, не потребуются новые клинические записи или клинические изменения для разделения между двумя базами данных</strong>, и то же самое можно сказать о любом импортере под угрозой продолжения импорта данных в старую базу данных. Соответственно, при подготовке к миграции <strong>рабочей</strong> базы данных <p></p> <ul> <li> обеспечьте надлежаще настроенную копию клиента для новой рабочей базы данных </li> <li> создайте резервную копию и затем вставьте подходящий баннер входа, об обновленной базе данных </li> <li> остановите любые и все импортеры и укажите их к новой базе данных </li> <li> обновите старую базу данных, что приведет к клонированной "новой" базе данных </li> <li> измените заголовок входа новой базы данных </li> <li> перезапустить любые все импортеры </li> <li> в зависимости от желания сохранить старую базу данных доступной, перенастройте не разрешать любые дальнейшие соединения и/или удалять или управлять копиями клиента, которые будут указывать на него </li></ul> <p></p> <h3><a name="A_AN1"></a> Применение исправления ошибок в работающих базах данных </h3> <p></p> Несмотря на возможное, будет необходимо применять исправление ошибки сценария SQL к запущенной базе данных время от времени. Такие сценарии представлены в каталоге <code>server/sql/vN_vN+1/fixups/</code> пакета GNUmed-server.vN+1.x (скажем, <em>GNUmed-server.v9.2</em>). Для применения их используйте сценарий <code>server/bootstrap/fixup-db.sh</code>. Для вашего удобства сопровождающий пакет также может установить ярлык <code>gm-fixup_server</code>. <p></p> Для применения исправлений вручную выполните эти шаги на хосте базы данных (включая v9.2): <p></p> <ul> <li> только для безопасности возьмите резервную копию базы данных </li> <li> войдите в компьютер базы данных </li> <li> убедитесь, что можно подключиться к gnumed_v9 as gm-dbo <ul> <li> проверьте: psql -d gnumed_v9 -U gm-dbo </li></ul> </li> <li> перейдите в каталог server/sql/v8_v9/fixups/ (на Debian, /var/lib/gnumed/...) </li> <li> в каждом файле измените строку <ul> <li> <code>--set default_transaction_read_only to off;</code> на <code>set default_transaction_read_only to off;</code> (IOW, удалите <code>--</code>) </li></ul> </li> <li> для каждого скрипта предоставьте запуск: <ul> <li> <code>psql -d gnumed_v9 -U gm-dbo -f script_name</code> </li> <li> иногда, некоторые файлы необходимо запускать в определенном порядке, подробности приведены в примечаниях к версии </li></ul> </li></ul> <p></p> Это применит все исправления ошибок, и также зажурналирует (в таблице gm.schema_revision) имена файлов сценариев, которые были выполнены. В случае возникновения проблем, можно задать вопрос в список рассылки. Обратите внимание, что исправленные скрипты будут подготовлены только к исправлениям, которые разрешают официальные релизы (не во время процесса выпуска кандидатов). Это одна из причин для предупреждения <strong>не</strong> обновлять рабочие базы данных с помощью релиз кандидатов, как указано выше. <p></p> <a name="TopicEnd"></a> <p></p> <p></p> <p></p> <p></p> </div> </body></html>