# HG changeset patch # User Sebastien Jodogne # Date 1481708202 -3600 # Node ID c2f2202f54f2df64dbf1deb21d7463e8ee740f69 # Parent 16d516fdc642afa413ac9498b7f12e8fa205f8fa more information about upgrade diff -r 16d516fdc642 -r c2f2202f54f2 Sphinx/source/users/replication.rst --- a/Sphinx/source/users/replication.rst Wed Dec 14 10:09:44 2016 +0100 +++ b/Sphinx/source/users/replication.rst Wed Dec 14 10:36:42 2016 +0100 @@ -17,9 +17,15 @@ successive versions of Orthanc might use a different version of the database schema. If this happens, Orthanc will refuse to start (with an explicit message in its :ref:`logs `), to let the user decides -whether she actually wants to upgrade the database. At this point, the -user might indeed decide to modify its :ref:`configuration file -` to create a new database elsewhere on the filesystem. +whether she actually wants to upgrade the database. + +At this point, the user could indeed choose to modify its +:ref:`configuration file ` in order to create a new +database elsewhere on the filesystem (if using the default SQLite +backend), or on the database management system (e.g. if using +:ref:`PostgreSQL `). This is important to let the user +experiment a new version of Orthanc, while keeping the older version +up and running. If you decide to upgrade the database schema, you have to apply the following 3 steps: @@ -31,32 +37,47 @@ * Under Debian, use ``sudo /etc/init.d/orthanc stop``. 2. Manually call Orthanc with the ``--upgrade`` command-line option, - and point to your default configuration file: + and point to your configuration file: - * Under Microsoft Windows, ``Orthanc.exe c:/Orthanc/``. + * Under Microsoft Windows, ``Orthanc.exe c:/Orthanc/ --upgrade``. * Under Debian, use ``sudo /usr/sbin/Orthanc /etc/orthanc/ --upgrade``. -3. Start the Orthanc service again: +3. Once the upgrade process is over, restart the Orthanc service: * Under Microsoft Windows, use the `services control panel `__. - * Under Debian, use ``sudo /etc/init.d/orthanc stop``. + * Under Debian, use ``sudo /etc/init.d/orthanc start``. + +**Important remarks:** -Note that, depending on the size of the Orthanc database, upgrading -the database schema might take time. +* Orthanc is now considered as **stable**, which means that no upgrade + in the database schema should occur in the near future. +* Depending on the size of the Orthanc database, upgrading the + database schema might take time, as this operation implies + re-reading all the DICOM instances from the disk. +* In the case of the official Debian and Fedora packages, the default + location of the database changes with the version of its schema. + For instance, DB schema version 6 will be stored in + ``/var/lib/orthanc/db-v6/``. If upgrading the package (and if the + configuration files are purged), a new database will automatically + be created on the disk. Old data can be recovered either by changing + the configuration in ``/etc/orthanc/`` to point to the previous + location of the database then using ``--upgrade`` as written above, + or by using the instructions for replication below. Direct access to the filesystem ------------------------------- -The most direct way to replicate consists in using the -`ImportDicomFiles +The most direct way to replicate an instance of Orthanc consists in +using the `ImportDicomFiles `_ script of the Orthanc distribution. For instance, the following -command would recursively explore the content of the ``OrthancStorage`` -folder (where Orthanc stores its DICOM files by default), and send -each DICOM file inside this folder to the instance of Orthanc whose -REST API is listening on ``http://192.168.0.2:8042``:: +command would recursively explore the content of the +``OrthancStorage`` folder (where Orthanc stores its DICOM files by +default), and send each DICOM file inside this folder to the instance +of Orthanc whose REST API is listening on +``http://192.168.0.2:8042``:: $ python ImportDicomFiles.py 192.168.0.2 8042 OrthancStorage