NLCR / CZIDLO

CZech IDentification and LOcalization Tool
4 stars 0 forks source link

Nedohledání přidělených URN:NBN #249

Open Drahotussky opened 1 year ago

Drahotussky commented 1 year ago

Dobrý den, nedaří se mi dohledat v CZIDLO naše URN:NBN počínaje urn:nbn:cz:ope301-0002qz - jde o monografii Odrau, einst Winanow... urn:nbn:cz:ope301-0002r0 - urn:nbn:cz:ope301-0002s3 - jde o periodikum Slezske slovo.

Mám soubory se žádostmi o přidělení identifikátoru. V metadatech projektů i v MODS monografie, vytisku identifikatory jsou, Když zkusím vyhledat dané dokumenty, tak dlouho probíhá hledání a nakonec se objeví chybové hlášení: Resolver_1 Resolver_2

Dekuji za pomoc

ZdenkaSera commented 1 year ago

Dobrý den, máme stejný problém, ověření přidělených urn:nbn přes uživatelské rozhraní končí buď bez výsledku nebo výše uvedenou chybou. Příklad dnes ověřený: 4fc6e185-c16f-47b2-bef3-92182654e73e / urn:nbn:cz:aba007-000k1f

Narazili jsme ale na další problém, kdy urn:nbn nebylo do objektu zapsáno, ale systém je znovu nepřidělí, protože uuid již v databázi existuje. U titulu jsme změnili model – původní NDK monografie byla zařazena pod vícedílnou monografii. Proto jsme deaktivovali původní urn:nbn a vymazali uuid, abychom témuž uuiid mohli přidělit urn:nbn nové. Postup jsme konzultovali v NK a máme jej ověřený, u několika titulů proběhl bez problémů.

Titul s uuid:661bcc57-349e-47d8-a708-32fb8a93e793 a původním urn:nbn:cz:aba007-0002ks jsme deaktivovali, ale při novém přidělení CZIDLO vrací tuto hlášku: _„INVALID_REGISTRAR_SCOPEIDENTIFIER: for registrar 'aba007' there already exists registrar-scope identifier with either type 'uuid' for digital document 3247981, or type 'uuid' and value '661bcc57-349e-47d8-a708-32fb8a93e793' for some other digital document“

Prosím, můžete zasáhnout do databáze a pomoci nám s „opravou“ tohoto objektu, abychom mohli dokončit celý proces až po archivaci? Děkuji.

ZdenkaSera commented 1 year ago

@rzeh4n Prosím, mohu požádat o reakci? Děkuji.

rzeh4n commented 1 year ago

Dobrý den, problém je v tom, že tam byl delší dobu výpadek vyhledávacího indexu (solr). Primární data v databází jsou v pořádku, ale data k vyhledávání jsou narušena pro urn:nbn registrované od 15.8. 2022 do teď. Nekonzistence pak vypadá takto:

Snímek obrazovky 2022-11-29 v 19 27 46 Snímek obrazovky 2022-11-29 v 19 28 02

To, žde o tento problém poznáte tak, že při dotazu na API vám to vrátí informace o urn:nbn. Např. https://resolver.nkp.cz/api/v5/urnnbn/urn:nbn:cz:mzk-0077iz

Náprava (reindexace) právě probíhá a bude dokončena v řádu maximálně jednotek dnů, poté bude opět dohledatelné vše.

@Drahotussky @ZdenkaSera

rzeh4n commented 1 year ago

@ZdenkaSera Pokud jde o uuid:661bcc57-349e-47d8-a708-32fb8a93e793, tak to má přiřazen jiný dokument, proto ta hláška o kolizi. Konkrétně je to urn:nbn:cz:aba007-000gso, není tohle ta nová verze? Pokud ne, tak je potřeba u toho dokumentu odebrat identifikátor uuid. Případně to můžu udělat já.

ZdenkaSera commented 1 year ago

@rzeh4n Dobrý den, děkuji za zprávu ohledně solru - dotazy přes api vracely zpátky přidělená urn:nbn, takže se databáze zdála v pořádku - jsem ráda, že jste to potvrdil. V případě konkrétního urn:nbn:cz:aba007-000gso nám tuto hodnotu db nevracela - díky Vaší odpovědi jsem mohla ověřit, že oprava urn:nbn proběhla správně a po ručním zápisu do metadat objektu už i dotaz na api potvrzuje správnou kombinaci uuid/urn:nbn v db. Takže za mne vyřešeno, velice děkuji.

rzeh4n commented 1 year ago

@ZdenkaSera super, díky. Jinak ty indexace doběhly minulou středu. Takže už by neměla být žádná nekonzistence mezi databází a indexerm.

FilipPavcik commented 9 months ago

Dobrý den,

znovu sa objavil problém s vyhľadávacím indexom. Novo vytvorené URN:NBN systém zaregistruje, avšak vo webovom rozhraní sa vyhľadávané urn:nbn nezobrazia.

rzeh4n commented 9 months ago

Problém je v malé paměti RAM na produkčním serveru. Konkrétně je jsou tam 4GB na všechno, přičemž tolik je minimum jen na Solr (verze 7), co slouží k vyhledávání.

Minimum RAM Requirement (All Versions): Solr 7, 8, 9:

  • At least 4GB of RAM for basic operations.

Recommended RAM for Production Environments:

  • Solr 7: 8GB or more, depending on dataset size and query load.
  • Solr 8: 8GB to 16GB, higher for large indexes or high query volumes.
  • Solr 9: 16GB or more is advisable for extensive data or high throughput environments.

Kromě SOLR je tam víc komponent (postgres, tomcat, apache, samotný systém).

Solr má mechanizmus, který Solr server vypíná v případě nedostatku operační paměti (oom killer). A to se opakovaně děje, případně se dostane Solr do jiného podivného stavu, kdy nefungují importy, ale čtení ano.

Po importu každého dokumentu se děje jeho následná indexace. Ta ale není blokující, takže import projde i při výpadku Solr. Jen je potřeba dodatečně data doindexovat. Na to má CZIDLO procesy dostupné přes admin rozhraní. Takže nefungční Solr NEbloku digitalizační linky, ale samozřejmě je to potřeba řešit.

@FilipPavcik Chtělo by to navýšení té paměti na alespoň 8 GB, raději více. Nicméně to bude vyžadovat restart serveru, což může potenciálně odhalit jiné problémy, přecejen úplný restart proběhl naposledy před více než 2 lety.

rzeh4n commented 9 months ago

@FilipPavcik Už by to mělo být vše v pořádku. Po navýšení RAM už SOLR nepadá. Doindexoval jsem záznamy importované během výpadku (28.11.-3.12.)