Daniel Shahaf wrote on Wed, Oct 22, 2014 at 11:17:46 +0000:
> Stefan Sperling wrote on Mon, Oct 20, 2014 at 20:58:57 +0200:
> > On Mon, Oct 20, 2014 at 08:46:03PM +0200, Stefan Sperling wrote:
> > > On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA512
> > > >
> > > > On 20.10.2014 19:07, Stefan Sperling wrote:
> > > >
> > > > > I would recommend you reset the mirrored repository to the last
> > > > > known-good revision (269997?) by moving out of the way all files
> > > > > belonging to newer revisions (in db/revs) and revprops (in
> > > > > db/revprops), running 'svnadmin recover' (this should set
> > > > > db/current to the number of the last known-good revision)
> > > > I've done this three times, each time removing 100 revisions. Result
> > > > the same: before 2 revisions to end "svnadmmin verify" complains about
> > > > "Serialized hash missing terminator".
> > > >
> > > > Now 269999 is clear for sure, as it is very old revision. Iad. yes,
> > > > I've checked "revprops/269/269999", it is properly-formatted prop file.
> > > >
> > > > So, it is NOT problem of revprops, but it is about some other
> > > > (which?) file in repo.
> > >
> > > It's probably a corrupt entry in db/rep-cache.db which every sync
> > > keeps picking up again and again.
> > >
> > > Try the whole procedure again either with rep-sharing disabled
> > > in db/fsfs.conf (enable-rep-sharing = false), or with a copy
> > > of db/rep-cache.db from the master server which you should put
> > > in place before the 'svnadmin recover' step (because entries newer
> > > than the recovered HEAD revision are automatically removed from
> > > the rep-cache during 'svnadmin recover').
> >
> > Thinking about this some more, it's definitely safer to just
> > disable rep-sharing on the slave. Unless you have a bit-perfect
> > copy of the master repository on the slave it is probably unsafe
> > to copy rep-cache.db between repositories because revision files
> > on the slave might contain data in a different order, in which
> > case rep-cache entries copied from the master would be invalid.
> >
>
> Right, data from the master could be invalid for the slave because of
> different txn names, different zlib versions, or any number of other
> reasons.
>
> > If you really want to keep the rep-cache on the svnsync slave
> > you'd have to dump/load or sync again from r0 :-/
> > Or fiddle with the rep-cache sqlite table directly and remove
> > the bad entry (but you'd have to find that yourself).
> >
> > Disabling rep-caching is a perfectly safe thing to do.
> > It might cause the slave to use a little more diskspace than the
> > master does for future revisions, but there are no other downsides.
>
> Or you could delete rep-cache.db, that will keep rep-cache working,
> except that revisions younger than current HEAD will not participate
> in it.
>
s/younger/older/. (That is: new revisions will do rep-sharing only
amongst themselves, and will never references anything that is
in the rev files that already exist right now.)
Daniel
> Daniel
> (for the record: when backdating HEAD as recommended upthread, one
> should _always_ truncate or delete rep-cache.db too, to prevent
> corruption down the road from references into the "undone" revisions.)
Received on 2014-10-22 13:27:21 CEST