Issue after restore all from DSpace 5 to Dspace 7

[dba...@gmail.com]

I have a DSpace 5.10 instance that I have exported the entire site from using AIP.

I have a freshly installed DSpace 7.6.1 instance that I have imported all content into (

[dspace]/bin/dspace packager -r -a -f -t AIP -e <eperson> -i <site-handle-prefix>/0 -o skipIfParentMissing=true /full/path/to/your/site-aip.zip). The import was successful and imported over 200 GB of data.

However, when I log into the new instance, I do not see any communities or collections. I performed a server reboot to make sure all services were restarted OK, but still no communities/collections. I also tried to run 'dspace database update-sequences', but I get the following error:

Running org/dspace/storage/rdbms/sqlmigration/postgres/update-sequences.sql
Caught exception:
org.postgresql.util.PSQLException: ERROR: setval: value 0 is out of bounds for sequence "handle_seq" (1..9223372036854775807)
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2713)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2401)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:368)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:498)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:415)
        at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:335)
        at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:321)
        at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:297)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:292)
        at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:193)
        at org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:193)
        at org.dspace.storage.rdbms.DatabaseUtils.main(DatabaseUtils.java:405)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:283)
        at org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:134)
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:99)

I'm not sure if update-sequences.sql will fix my issue anyway. Any other ideas? Thanks.

[DSpace Technical Support]

Hi,

Have you tried reindexing everything?  Assuming the import worked properly (no obvious errors in logs), then it's possible the content isn't showing because the reindex process either hasn't been triggered or somehow failed.

So, I'd recommend trying:  "[dspace]/bin/dspace index-discovery -b"   while Tomcat/Solr are running.  This may take a while for a large amount of content, but you should be able to watch its progress via the dspace.log.

If that doesn't work, then I'd recommend checking that your database *has content* in the "community", "collection" and "item" tables.  If there's nothing in there, then the problem was with the import process.    The error you received from the "update-sequences" script almost sounds like it cannot see any content in the "handle" table, which again may imply the import didn't work as expected.

Tim

[dba...@gmail.com]

Thanks, Tim.

I checked for content in community, collection, and item tables and they were all empty. I'm not sure what went wrong. The restore took about 2 weeks for 200+ GB of data from a local disk. Is there any way to speed up the restore? It makes it really hard to troubleshoot when you have to wait so long for results.

Thanks,

David

[DSpace Technical Support]

Hi David,

I'd recommend trying one of the following:

Potentially break down the task by trying to restore a *single* Community or Collection.  Once you get one restore to work, the others should all work similarly.  You could even try this on a test server to just ensure a basic restore works properly before running the larger restore. (If you wanted you also could do the entire restore in batches of this sort rather than all at once)

Alternatively, you could avoid AIPs altogether and use the Migration technique described here: https://wiki.lyrasis.org/display/DSDOC7x/Migrating+DSpace+to+a+new+server  This migration can be used to upgrade from an older version of DSpace to a newer one, and there are a number of comments at the bottom of that page of other DSpace users who've said this works very well for larger sites.

AIPs are not the fastest way to move data around because they require a lot of time to unzip/process (and the current code is likely not the most efficient).  AIPs are excellent for restoring individual objects and can be very useful to restore from backup in an emergency scenario (or accidental deletion). They just are not as efficient as the migration process described above or the normal upgrade procedure.

Hopefully that gives you a few options to look at, but let us know if you have other questions.

Tim

[dba...@gmail.com]

Thanks again, Tim.

I had previously tested with single Communities and Collections and they were working OK -- and that's why I proceeded with the whole-site AIP.

I'm going to look into the Migration technique you linked to. Hopefully I'll get that to work. Alternatively, I may end up just having to use AIPS one Collection or Community at a time.

Thanks for all the help.

David

[dba...@gmail.com]

I'm working on migrating instead of using AIPs. I've re-created the database from the old instance on the new Dspace 7 and copied the assetstore over.

I get an error when I run the migrate command: ./dspace database migrate ignored

Database URL: jdbc:postgresql://localhost:5432/dspace
Migrating database to latest version AND running previously "Ignored" migrations... (Check logs for details)
Done.
Exception in thread "Thread-2" java.lang.IllegalStateException: Session/EntityManager is closed
        at org.hibernate.internal.AbstractSharedSessionContract.checkOpen(AbstractSharedSessionContract.java:407)
        at org.hibernate.engine.spi.SharedSessionContractImplementor.checkOpen(SharedSessionContractImplementor.java:148)
        at org.hibernate.internal.SessionImpl.getCriteriaBuilder(SessionImpl.java:3801)
        at jdk.internal.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)

        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)

        at org.hibernate.context.internal.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:351)
        at jdk.proxy2/jdk.proxy2.$Proxy138.getCriteriaBuilder(Unknown Source)
        at org.dspace.core.AbstractHibernateDAO.getCriteriaBuilder(AbstractHibernateDAO.java:394)
        at org.dspace.core.AbstractHibernateDAO.findAll(AbstractHibernateDAO.java:75)
        at org.dspace.core.AbstractHibernateDAO.findAll(AbstractHibernateDAO.java:70)
        at org.dspace.xmlworkflow.storedcomponents.ClaimedTaskServiceImpl.findAll(ClaimedTaskServiceImpl.java:51)
        at org.dspace.discovery.indexobject.ClaimedTaskIndexFactoryImpl.findAll(ClaimedTaskIndexFactoryImpl.java:41)
        at org.dspace.discovery.SolrServiceImpl.updateIndex(SolrServiceImpl.java:346)
        at org.dspace.discovery.SolrServiceImpl.updateIndex(SolrServiceImpl.java:336)
        at org.dspace.discovery.SolrServiceImpl.createIndex(SolrServiceImpl.java:304)
        at org.dspace.storage.rdbms.DatabaseUtils$ReindexerThread.run(DatabaseUtils.java:1477)

I'm attaching my dspace.log file.

Thanks,

David

[DSpace Technical Support]

Hi David,

The error itself doesn't seem to appear in your DSpace log file, which is odd.  The closed issue that might relate to that error is this message:

2024-06-20 17:36:30,838 WARN unknown unknown org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor @ DB: there is already a transaction in progress (SQL State: 25001 - Error Code: 0)

That appears to be saying that PostgreSQL appears to think there's already a database transaction in progress when you tried to run the database migrate.

I'd check to see if the migration succeeded or not by running "./dspace database info" and seeing if you have any "Pending" or "Ignored" migrations (if there are pending or ignored migrations, that means some migrations did NOT run). If not, then you could try and run a full reindex to verify everything is working.

If you find that some migrations did NOT run, then I would recommend temporarily restarting your PostgreSQL (to stop any transactions) and try the process again. It's possible some earlier action in Postgres got 'stuck' and blocked any additional changes.

Those are my best guesses here. I'm hopeful one of those will work.

Tim