/usr/share/doc/gnumed/user-manual/Gnumed/GmManualServerUpgradeRu.html is in gnumed-doc 1.4.6+dfsg-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 | <!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=1391005513" 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="29%20Jan%202014%20-%2015:25" /> <!-- 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="ConfigurePostgreSQLRu.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>
|