Restore replicated data files that are 0 bytes
Due to a replication bug, some data files were not replicated fully. These should be tracked down and restored.
#1 Updated by ben leinfelder over 9 years ago
Matt suggests an alternative approach: delete the files and the DB records for those files so that the next timed replication will pick them up.
This should certainly be tested before trying.
It may not work because I believe timed replication relies on the update date for the document when constructing a diff list and as far as I know there's not a "tell me every docid you have and I'll see if you're missing some that I have".
#2 Updated by ben leinfelder over 9 years ago
Current proposal for upgrade script solution:
find all data files in the configured data directory for Metacat this should force those data files to be re-replicated to the targets that had 0 byte data files.
-delete those docids from the xml_documents and/or xml_revisions tables
-delete those files from the filesystem
-set xml_replication entry for that table (in remote Metacat) to have never run timed replication -
Note that is requires extensive re-replication. Fine for small installations like PPBio or PELD, but not for PISCO or LTER.
Alternative, manual process:
-on replication source server: create tar file of all non-0 byte length files
-untar the archive on the target server, overwriting any existing (0 byte) files.
*repeat the process in the other direction if this was 2-way replication.
#4 Updated by ben leinfelder over 9 years ago
By removing replicated data files in my test environment (DEMO3 <-> fred) and removing the entries from the xml_documents and xml_revisions tables, timed replication successfully re-replicated the newly-missing data files.
I'm pretty happy with this solution as it does not require manual transfer of the zero-length replicated data files from source to target.