Restored database dum gives unnamend repositories un identical test system

[ToniS]

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]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/96809d15-dea5-42a6-a14c-0ff1bc84dfa4n%40googlegroups.com.

[ToniS]

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!