Restored database dum gives unnamend repositories un identical test system

24 views
Skip to first unread message

ToniS

unread,
Jan 18, 2022, 1:25:38 PMJan 18
to AtoM Users
Hi atomers,

I'm facing a strange problem. A database Dump from a 2.6 Docker live System is restored in a Test environment. Both setups are identical with german default culture.

The strange thing is after the restore the test system shows 14 repositories with 4 unnamed repositories (/index.php/repository/browse). While the live system only shows 10 without the unnamed (which is correct).

My first idea of course was to recreate the search index:
php /atom/src/symfony search:populate php /atom/src/symfony cc => Nothing changed.

What else could I do to check where this comes from.
Is there for example some management command to see if elasticsearch is in sync with the database entries? (maybe the live system has those entries as well but es does not know about them yet?!)

Best regards and thanks for your help
Toni



ToniS

unread,
Jan 18, 2022, 1:36:06 PMJan 18
to AtoM Users
A small update: 
ES Status on the live system:

Elasticsearch server information:

 - Version: 5.6.16
 - Host: elasticsearc
 - Port: 9200
 - Index name: atom

Document indexing status:

 - Accession: 18/18
 - Actor: 3242/3242
 - Aip: 0/0
 - Function object: 0/0
 - Information object: 37319/37513
 - Repository: 10/14
 - Term: 3040/3040

Does this mean elasticsearch is out of sync at the live system and will propably show the 4 unnamed repositories after the next recreation of the search index as well?
I'm asking as I'm no ES expert at all and don't want to mess up the live System.



Dan Gillean

unread,
Jan 18, 2022, 3:57:09 PMJan 18
to ICA-AtoM Users
Hi Toni, 

I'm glad you found the search:status task

You're correct about the task output. For whatever reason, your live system has 4 repository records in the database that are not indexed. This likely means that the database load went well, but these blank records already existed from some earlier step, and for whatever reason haven't yet been indexed on your production instance. If you run the search populate task, they will likely show up, same as the test system. 

I'd suggest just re-indexing and manually deleting them, then making a fresh backup. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him


--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/8b9d624f-25a2-44f1-b8f0-340866aac876n%40googlegroups.com.

ToniS

unread,
Jan 18, 2022, 4:00:58 PMJan 18
to AtoM Users
Dear Dan,

thank you so much for your reply. Good to hear that your assumptions match with mine.
I will do as you write: reindex on production, delete, dump, and restore in dev.

May I add one more question?
The mismatch between numbers here:
 - Information object: 37319/37513
Is this something to worry about? (Same on life and dev)

Cheers,

Toni

Dan Gillean

unread,
Jan 19, 2022, 8:28:29 AMJan 19
to ICA-AtoM Users
Hi Toni, 

I didn't notice that the first time around, but yes, it appears that there are a number of descriptions in the database that are not currently indexed in Elasticsearch, meaning they will not show up in search or browse pages until indexed. Possibly the result of a CSV import from the command-line that was not indexed afterwards?

I'd suggest starting by running the re-index task and then taking a look. 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him

ToniS

unread,
Jan 19, 2022, 8:30:50 AMJan 19
to AtoM Users
Once again, thanks a lot, Dan. I will do so.
VM Screenshot was taken :}
Strange as those unindexed also show up on dev after reindexing which is actually the same database.
I will dig and dive deeper!

Reply all
Reply to author
Forward
0 new messages