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.
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:17:54 CEST