On Fri, Oct 06, 2017 at 04:48:20PM +0200, Patrik Lundin wrote:
> On 2017-10-06 09:29:33, Jeffrey Hutzelman wrote:
> > It shouldn't be needed. First, a full dump is automatically triggered
> > if the master doesn't have enough log entries to bring the slave from
> > its current version to the master version. so if a slave us at version
> > 0, you either get a complete log replay out a full dump, either of
> > which is sufficient. In practice, it should always be a full dump,
> > because the log should never contain an entry for version 1.
> 
> This is not in line with the current state of the iprop-log manual (and
> behaviour) on 7.4.0:
> ===
> truncate
> [...]
>     If --reset is given, then the given, configured, or default log file will 
> be truncated and will start at version 1.  This forces full
>     propagations to all slave KDCs.
> 
>     Otherwise the log will be truncated but some entries will be preserved, 
> as specified by the --keep-entries and/or --max-bytes options.
>     The largest number of --keep-entries entries that are available and fit 
> in the given --max-bytes option will be used.  The --keep-entries
>     -option -defaults -to -100, -and -the --max-bytes option defaults to the 
> log-max-size parameter in the configuration.
> ===

So, the log now always has an uber entry, and that entry has the same
header/footer as all the others, so it needs a version number, and it
will get version 0.  But it's a no-op entry, so it has no HDB contents.
What the uber entry has is metadata about what entries in the log have
been written to the HDB.

So, yes, the log will start at version 0, but it won't have any real
content at version 0, and the first real entry will be version 1.

> Based on that information it seems like expected behaviour to be able to
> reset the log in order to "start over". I am not clear on if "start at
> version 1" means "the log should be at version 1 directly after a
> --reset truncation", or if it means "the first entry added after reset
> will use version 1".

Yes.

> As it stands in 7.4.0, using "--reset" will make the log start at
> version 0:
> ===
> # iprop-log last-version --no-lock
> version: 22
> # iprop-log truncate --reset
> # iprop-log last-version --no-lock
> version: 0
> # iprop-log dump --no-lock
> nop: ver = 0, timestamp = 2017-10-06 16:17:42, len = 16
> uberblock offset 40 timestamp 2017-10-06 16:17:42 version 0
> ===

Looks right.  Though I see that tests/kdc/check-iprop.in does not test
that iprop-log truncate --reset forces full props.  We should improve
that.

> > Remember that truncation does not zero the version. It throws away the
> > existing log entries and writes a new log containing a single
> > transaction with a newer version than the existing log. This forces a
> > full update for any slave that was not already up to date.
> 
> This is no longer true, a truncate without --reset will keep a
> configured amount of entries, so in the case with the newly init'ed
> database it will only update the timestamps on the initial uber record
> and not touch any of the entries.

Correct.

Nico
-- 

Reply via email to