Project

General

Profile

Bug #5536

Restore replicated data files that are 0 bytes

Added by ben leinfelder almost 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Category:
metacat
Target version:
Start date:
11/09/2011
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5536

Description

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 bytesResolved10/26/2011

History

#1 Updated by ben leinfelder almost 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 almost 9 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.

#3 Updated by ben leinfelder almost 9 years ago

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

#4 Updated by ben leinfelder almost 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.

#5 Updated by Redmine Admin over 7 years ago

Original Bugzilla ID was 5536

Also available in: Atom PDF