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.
===
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".
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
===
>
> It's also not necessary and in fact potentially harmful to check the
> master's version for 0. A real database can never be at version 0, so
> if you see that, something is wrong, and copying that database
> wholesale to another server is probably a bad idea.
>
Some assumption seems to have been broken if that is the case given the
above displayed behaviour.
> 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.
> >
> >That would be unfortunate ;-)
>
> it would, but truncating the log doesn't set the version to 0.
>
See above.
Regards,
Patrik Lundin
