Some objects not accessible on the CN via REST API
While doing other work, I noticed that a good number (not sure how many) of objects listed on the CN's Solr index are not accessible via the REST API get() and resolve() methods. Instead of returning the object, they return a NotFound error.
- Visit https://cn.dataone.org/cn/v1/query/solr/?fl=identifier,title,authoritativeMN,datasource&q=formatType:METADATA+AND+-obsoletedBy:*&rows=100&start=0
- Pick a PID from the query result, e.g.
- Attempt to resolve() or get() the object via the REST API like: https://cn.dataone.org/cn/v1/object/CLOEBDMETADATA.10242013.1
- Receive a NotFound error instead of the object.
In IRC, Skye noticed that the objects can be retrieved via their respective MN so it appears this issue may be a Metacat replication issue.
#1 Updated by Skye Roseboom about 6 years ago
Looks like a partial metacat replication between the CN:
does not work: https://cn-ucsb-1.dataone.org/cn/v1/object/knb-lter-cap.148.9
same with CLOEBDMETADATA.10242013.1
does not work: https://cn-ucsb-1.dataone.org/cn/v1/object/CLOEBDMETADATA.10242013.1
Can we trigger metacat replication audit between the CN so these objects and others are added to cn where missing?
#4 Updated by Chris Jones about 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
I've forced Metacat replication manually by:
- Choose 'Replication Configuration' > 'Reconfigure Now'
- Unde 'Replicate Now', choose 'Get All'
Repeat this for cn-orc-1 and cn-unm-1
I've also reset the timed replication from 172800000 (48 hrs) to 7200000 (2 hrs). We've discussed this in the past, and decided that the CNs should force replication on a much shorter time frame than the default in order to compensate for any network glitches that cause replication events to be missed. I'll be sure this is in the CN install/upgrade documentation.
Once replication has finished pulling from the other CNs, I'll check back to see if these NotFound errors are resolved.