Это не лог, это мааленький кусочек... ставили по мануалу на wiki.duraspace? Там есть пара windows speciffic ошибок.

Для тренировки я бы рекомендовал версию 3.х (3.4 сейчас), и всётаки не на винде, либо, сразу быть готовым к тому что будут проблемы с OAI. Они решаемы, но лучше на линуксе...

[ideafix.name]

Что то я запутался, помогите пожалуйста разобраться правильно ли все делаю:
задача - нужно перенести dspace_3.2 на новый сервер: было на freebsd 32-x разрядной, теперь будет на debian 64-х разрядной.
На старом сервере: делаю Бекап БД (pg_dump); и копирую этот бекап, а также папку dspace на новый сервер.
На новом сервере: устанавливаю заново dspace_3.2, создаю новую пустую БД (createdb -U dspace -E UNICODE dspace), восстановливаю БД со старой dspace , копирую assesstore и т.п.

Вопрос, который крутиться в голове - нужно ли переносить данные с помощью dspace packager ?

Перенести можно только базу асетстор и конфиги. Самое интересное - перенос солр кэша и статистики по айтемам.

В остальном всё верно.

Кстати, попробуйте таки использовать макрос packager для переноса фонда, один фиг чистый сервер будет... у меня в принципе положительный результат был. А вот с маросами import/export скорее отрицательный - bitstream order не сохраняется :(



Редактировано 1 раз. Последний раз 01.04.2015 10:19 пользователем IdeaFix.

packager пробовал, но при импорте выдает ошибку и останавливается
/dspace/bin/dspace packager -r -a -t AIP -e e-mail /путь/aip0.zip

EPerson ______@mail.ru already exists
и всё

"Самое интересное - перенос солр кэша и статистики по айтемам." - с этим проблемы?

С импортом понятно где проблема, лучше бы фонд экспортировать по handle_prefix/0 тогда проблем не будет, а юзеров потом перетащить.

А солр кэши переносятся не понятно как... у многих не переносятся и даже при обновлении версии на той же машине портятся.

IdeaFix
Спасибо, буду пробовать 3.4, но на винде, у меня без вариантов.
Лог это полный, вывод консоли в файл, дело в том, что установка обрывается практически сразу после начала, потому, видимо, лог и маленький.

Подскажите, пожалуйста, как исправить ошибку, при открытии прикрепленных документов выпадает ошибка 504 Gateway Time-out
Спасибо

Странно, а документы какого размера? А перед томкэтом какой-то хттп сервер стоит типа iis/httpd/nginx?

та любого размера, nginx стоит
Это случилось после переноса на новый сервер. Импорт, экспорт БД прошел без ошибок. Потом обновление dspace до версии 5.1. (согласно wiki_duraspace_org)
Потом
dspace/bin/dspace database info
dspace/bin/dspace database migrate
dspace/bin/dspace index-db-browse -f -d

dspace/bin/dspace index-discovery
dspace/bin/dspace filter-media -f

Все прошло успешно
Но при проверке оказалось что ни открывается ни один документ (...jspui/bitstream...)

а если до nginx проверить?

А если dspace checker -c 1000 && dspace checker-emailer дать?

варианты с неверным битстрим префиксом я не рассматриваю, т.к. считаю что конфиг правильный :)

IdeaFix написал(а):
-------------------------------------------------------
> варианты с неверным битстрим префиксом я не
> рассматриваю, т.к. считаю что конфиг правильный :)
а можно пример правильного префикса?

Результат выполнения следующего:
dspace/bin/dspace checker -c 1000
dspace/bin/dspace checker-emailer

...
Id файлу = 53131
Дата початку обробки = Apr 6, 2015
Дата закінчення обробки = Apr 6, 2015
Очікувана контрольна сума = 5c16a6f8edebaa54d1fa4fcf8cce4eb9
Обчислена контрольна сума =
Результат = Bitstream marked deleted in bitstream table
....

Нашелся битый или удалённый фал.

Таак... тогда dspace cleanup и потом dspace checker -l

Перед первым лучше сделать бэкап базы, второе может занять много времени, но проблема я думаю сетевая. Ведь через админку открываютс\я файлы при правке айтема?

в сформированном файле около 23 тысяч строк. Получается что очень много битых или удаленных файлов. Почему? Что не так?

При миграции всё прошло плохо. Либо асетстор отпал, либо база.

dspace cleanup чистит базу и асетстор на предмет удалённых битстримов (т.е. можно удалить раздел, но физически он будет сидеть на диске пока не сделаешь cleanup), checker же в свою очередь находит битые битстримы (-c 1000 - проверяет первые 1000 битстримов, -l - проверяет ВСЕ).

пока еще есть возможность все сделать наново. Есть еще остановленный, но нетронутый старый сервер. Подскажите, пожалуйста, что мы делали не так?

1. pg_dump -U dspace -f 04_04_2015.dump dspace
2. создаем пустую БД dspace: createdb -U dspace -E UNICODE dspace и
psql -U dspace -d dspace -f 04_04_2015.dump
3. копируем assetstore
4. потом, если не забыл, то dspace index-discovery и dspace filter-media -f

а асетстор в какой момент переносился?

ой, уже читаю через строчку... спать пора.

Блин, не знаю что вы не так делали, но что-то пошло не так... просто на сколько я понял, база апдейтится до 5 версии сама при ant update, а Вы не делаете ant update, только фреш инсталл, так? Т.е. быть может у Вас структура базы от старой версии.



Редактировано 1 раз. Последний раз 06.04.2015 21:11 пользователем IdeaFix.

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

спасибо за помощь. :) пойду тоже спать, а то совсем уже плохо соображаю :)

ssa_admin написал(а):
-------------------------------------------------------
> 1. pg_dump -U dspace -f 04_04_2015.dump dspace
> 2. создаем пустую БД dspace: createdb -U dspace -E
> UNICODE dspace и
> psql -U dspace -d dspace -f 04_04_2015.dump
> 3. копируем assetstore
> 4. потом, если не забыл, то dspace index-discovery
> и dspace filter-media -f

assesstore переносился в таком порядке как описал

Не факт что при накатке дампа базы 3 версии на пустую базу 5 версии всё проходит гладко.

хотя есть стандартная процедура для 5 версии
dspace database migrate

Коллеги, кто использует dspace 3.4 + jspui? дайте ссылочку, првоерить один момент.

уже на 5.1 версии работаем

Спасибо за помощь, оказанную в сообщениях выше. Самая главная проблема оказалась в настройках сетевых экранов. Когда там все настроили и все мои ошибки ушли :)
А для общего развития: в сообщениях выше указывалось для определенной задачи выполнить команду wget http ://localhost:8080/solr/statistics/update?optimize=true . После ее успешного выполнения создается файл update?optimize=true. А что делать дальше? Или просто ждать когда статитстика обновиться?

Это оптимизация солр кэша, если он был и не был оптимизирован - он оптимизируется. Если с ним были проблемы - это их не исправит.

Скажите, а кто то может подсказать, есть ли шанс исправить в отображаемой статистике название города Le Vibal на реальное название без полного удаления текущей статистики. (просто были ошибки с файлом geoip.dat и после их исправления названия городов стали реальными, но сохранилась старая статистика, где фигурируют неправильные имена)

Вот как раз обновление и оптимизация индексов должны помочь