Bug #5536


Restore replicated data files that are 0 bytes

Added by ben leinfelder over 12 years ago. Updated about 12 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Due to a replication bug, some data files were not replicated fully. These should be tracked down and restored.

Related issues

Blocks Metacat - Bug #5519: Replicated data files are 0 bytesResolvedben leinfelder10/26/2011

Actions #1

Updated by ben leinfelder over 12 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".

Actions #2

Updated by ben leinfelder about 12 years ago

Current proposal for upgrade script solution:
find all data files in the configured data directory for Metacat
-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 -
this should force those data files to be re-replicated to the targets that had 0 byte data files.

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.

Actions #3

Updated by ben leinfelder about 12 years ago

I created another "upgrader" that will remove the empty replicated data files so that they can be re-replicated using timed replication.

Actions #4

Updated by ben leinfelder about 12 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.

Actions #5

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 5536


Also available in: Atom PDF