DSpace - Обновление DSpace

OS: "Linux Ubuntu 18.04.1 LTS (Bionic Beaver)".
Apps: Java, PostgreSQL.

Задача: мигрировать данные "DSpace v5" в среду исполнения web-сервиса следующей мажорной версии, считая последний установленным строго следуя инструкции по сборке и развёртыванию "DSpace v6" в этом же разделе сайта.

Для решения задачи мною использовались следующие разделы официальной документации: "Upgrading DSpace 6.x" и "Changes in DSpace 6.3".

Начиная с "DSpace v5" функционал обновления структуры "баз данных" под новое программное обеспечение полностью автоматизирован.

В документации по вышеприведённым ссылкам описываются конкретные шаги, которые необходимо или желательно предпринять при переходе от "v5" к "v6", но они подготовительные или вспомогательные, а конвертация структуры и основного объёма данных всё таки осуществляется автоматически.

Учитывая весьма скромные объёмы мета-данных (относительно размеров хранимых цифровых документов), процедура конвертации не долгая - на практике, с моими 40GB пользовательских данных и полугигабайтной "базой данных" это занимало не более пяти минут - сам "Tomcat" с web-приложениями в контейнерах столько времени стартует обычно.

Последовательность дальнейших действий такова:

1. Копируем данные с исходного на целевой сервер.
2. Останавливаем целевой "DSpace" и размещаем в его хранилищах данные.
3. Проверяем возможность применения данных.
4. Запускаем целевой "DSpace" и проверяем, прошла ли конвертация успешно.
5. Опционально поправляем индексы и запускаем обновление индексов полнотекстового поиска.

Уточняем версии ПО "DSpace".

Простейший способ узнать версию web-сервиса "DSpace" - посмотреть исходный код любой выдаваемой им HTML-страницы:

....
<meta name="Generator" content="DSpace 5.1" />
....

Предусмотренная для этого CLI-команда:

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace version

DSpace version: 5.1
....

Сбор и копирование данных.

При миграции, помимо программных компонентов "DSpace" как такового, переносится на новый сервер (и обязательно сохраняется в виде резервной копии) следующее:

1. SQL-"база данных" (в нашем случае это PostgreSQL);
2. Директория загруженных файлов (./dspace/assetstore);
3. Директория поисковых индексов (./dspace/solr/statistics/data).

Заранее нужно узнать (например, командой "du -sh ./"), насколько объёмны исходные данные и приготовить для них достаточно места на целевом сервере:

Выгружаем "логический дамп" БД с сохранением его прямо на целевом сервере, используя для этого SSH-туннель:

# sudo -u postgres pg_dump --verbose dspace | ssh user@target.example.net "(mkdir -p /var/tmp/dspace5_data; cat > /var/tmp/dspace5_data/dspace5.sql)"

Копируем основной объём пользовательских данных, в виде файлов цифровых документов:

# cd ./dspace/assetstore ; tar cfv - * | ssh user@target.example.net "(mkdir -p /var/tmp/dspace5_data/assetstore; cd /var/tmp/dspace5_data/assetstore; tar xf - )"

Копируем статистику поисковых запросов, обслуживаемую встроенным в "DSpace" компонентом "Apache Solr":

# cd ./dspace/solr/statistics/data ; tar cfv - * | ssh user@target.example.net "(mkdir -p /var/tmp/dspace5_data/solr/statistics/data; cd /var/tmp/dspace5_data/solr/statistics/data; tar xf - )"

Размещение данных на целевом сервере.

Прежде всего останавливаем целевой "DSpace", чтобы он преждевременно не начал влиять на вносимые в его хранилища данные:

# systemctl stop dspace-tomcat

Опционально создаём "базу данных" и регистрируем необходимое расширение "pgcrypto":

# su - postgres
postgres@dspace:~$ psql

postgres=# DROP DATABASE IF EXISTS dspace;
postgres=#
postgres=# CREATE DATABASE dspace WITH OWNER = 'dspace' ENCODING = 'UTF-8' LC_COLLATE = 'ru_RU.UTF-8' LC_CTYPE = 'ru_RU.UTF-8' TEMPLATE = 'template0';
postgres=# \c dspace;
dspace=#
dspace=# CREATE EXTENSION pgcrypto;
dspace=# \q

Развёртываем в подготовленную пустую БД "логический дамп" (обязательно указывая опцией "ON_ERROR_STOP" прерывать развёртывание на первой же ошибке, чтобы можно было её сразу увидеть):

# sudo -u postgres psql -v ON_ERROR_STOP=1 dspace < /var/tmp/dspace5_data/dspace5.sql > /var/tmp/dspace5_data/psql.log 2>&1

Замена дистрибутивных директорий файловых ресурсов и поисковых индексов тривиальна:

# mv /var/lib/dspace/assetstore /var/lib/dspace/assetstore_backup
# cp -r /var/tmp/dspace5_data/assetstore /var/lib/dspace/assetstore
# chown -R dspace:dspace /var/lib/dspace/assetstore
# chmod -R o-rw /var/lib/dspace/assetstore

# mv /var/lib/dspace/solr/statistics/data /var/lib/dspace/solr/statistics/data_backup
# cp /var/tmp/dspace5_data/solr/statistics/data /var/lib/dspace/solr/statistics/data
# chown -R dspace:dspace /var/lib/dspace/solr/statistics/data
# chmod -R o-rw /var/lib/dspace/solr/statistics/data

Возможная проблема при конвертации структуры "базы данных".

В предваряющей эту инструкции по сборке и развёртыванию "DSpace v6" я упоминал о том, что автоматическое обновление структуры "базы данных" в СУБД "PostgreSQL" не отработает из-за некорректного SQL-скрипта, пытающегося создать "индекс", когда это сделать невозможно. Я сделал для исправления конфликтов и недочётов простейший "патч", меняющий порядок создания "индексов" и дополняющий логику удаления некоторых колонок таблиц каскадированием. Если "DSpace v6" собран с применением прилагаемого к указанной инструкции "патча", то проблем не ожидается - в противном случае после запуска в журнале событий мы увидим примерно такие сообщения о сбое процедуры миграции;

# cat /var/lib/dspace/log/dspace.log

....
Migration exception:
java.sql.SQLException: Flyway migration error occurred
at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:673)
....
Caused by: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException:
Migration V6.0_2015.03.07__DS-2701_Hibernate_migration.sql failed
....

Применение данных на целевом сервере.

Очень рекомендую перед запуском новой версии "DSpace" проверить вручную, какие обновления к "базе данных" уже применены - для этого есть специальная процедура:

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace database info

Вывод хорошо читается, и главное, что от него нам требуется - понимание, какие обновления прошли успешно (статус "Success"), а какие ожидаются (статус "Pending").

Ради расширения кругозора можно ознакомится с содержимым SQL-скриптов, посредством которых и производится обновление структуры БД - все они расположены в директории "./dspace/dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/" дистрибутива с исходными кодами "DSpace v6".

Уже сейчас можно запустить обновление структуры и содержимого БД вручную, предупреждая автоматическую процедуру, инициируемую при первом запуске новой версии "DSpace" (это необязательно, но в рамках тестирования функционала может быть интересным):

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace database migrate

Database URL: jdbc:postgresql://localhost:5432/dspace
Migrating database to latest version...
Done.

Я предпочитаю на тестовом стенде прогонять конвертацию "базы данных" вручную, вышеприведённой командой, а на целевом рабочем сервере отдаваться во власть автоматизации - запуская "DSpace" и просматривая журнал событий в поиске уведомлений о возможных сбоях:

# systemctl start dspace-tomcat
# journalctl -xe
# tail -100 /var/lib/dspace/log/console.log
# tail -100 /var/lib/dspace/log/dspace.log

Минут через пять после запуска "DSpace" желательно проверить, все ли этапы конвертации структуры и содержимого БД прошли успешно:

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace database info

В редких случаях индексы БД, переносимой от версии к версии "DSpace", могут быть некорректными и есть смысл по завершению конвертации запустить предлагаемый разработчиками скрипт по их проверке и возможному исправлению (если ошибок не найдено, то действий никаких не производится):

# sudo -u postgres psql -v ON_ERROR_STOP=1 dspace < /var/lib/dspace/etc/postgres/update-sequences.sql

Обновление индексов "Solr".

Казалось бы вспомогательный компонент "Apache Solr" на самом деле используется "DSpace" для отработки всех запросов на отображение данных. Для нас это означает, что сразу после переноса БД и пользовательских данных таковые в web-интерфейсе не отобразятся, пока не будут проиндексированы "Solr".

В рамках процедуры автоматической конвертации "DSpace" должен запустить переиндексацию - если этого не произошло, то сделаем это вручную:

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace index-discovery

Также возможно понадобится запустить вручную процедуру конвертации "базы данных" статистики поисковых запросов, а потом и её индексирование:

# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace solr-upgrade-statistics-6x
# sudo -u dspace CLASSPATH=/opt/dspace/tomcat/lib/* /var/lib/dspace/bin/dspace solr-reindex-statistics

Наблюдать за статусом БД "Solr" можно через специализированный web-интерфейс "https://dspace.example.net/solr/#/search" - хотя я предпочитаю доступ к нему блокировать и при необходимости искать сообщения о проблемах в журналах событий.

Заключение.

Дочитавшим до конца напоминаю, что почти всё изложенное в этой публикации необязательно к применению - после наложения исправляющего порядок работы с индексами "патча" автоматическое обновление проходит без единого сбоя, так что достаточно скопировать данные с сервера на сервер и запустить "DSpace", который сам сделает всё необходимое.

Обновление DSpace ( Миграция данных и обновление структуры мета-данных при переходе к "DSpace v6" от предыдущей мажорной версии, с PostgreSQL в качестве СУБД. )

Заметки и комментарии к публикации: