On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote:
> On 2017-10-06 10:03:37, Nico Williams wrote:
> > Trungcating the log is not the same thing as resetting it, and preserves
> > the version number.
> To summarize this tread: The --reset flag should currently not be used
> in a production systems since ipropd-master is unable to parse the
> resulting log file.
No, the master is perfectly able to to parse the new log. The issue is
that it's not enough to ensure that slaves get full props.
A fix for that and other things is in the works. For now just don't use
> In general the concensus seems to be that version numbers never
> decrement during normal operations. If you need to trigger a full dump you
> should do normal truncations on the master preserving few enough entries
> that slaves are unable to catch up and probably --reset the log on
> slaves so they do not think they can get away with just fetching the
Maybe we should add a record type (probably a variant of nop) that
indicates the desire to force a full prop at that point in time.
> Since loading a database dump using "kadmin -l load <dumpfile>" does not
> increment the iprop log version, this means that if you are migrating to
> a new master which has no log you will need to do something like this:
kadmin load *does* truncate and reset the log, but it leaves it at
version 0, which is what i think you meant.
> #1. Stop the current master.
> #2. Dump the database on the current master.
> #3. Load the database on the new master.
> #4. Do some random modification of the database on the new master via
> kadmin -l in order to set the log version to at least 2.
Just version 1 will do, but yes.
> #5. Make sure the log history does not look complete since this
> means a fresh slave (at version 0) will just try to get the delta:
> iprop-log truncate --keep-entries=1
You could stop the ipropd-slave processes, remove their log, and restart
> #6. Start processes on the new master.
> #7. Point slaves to the new master. They will now either have a log
> version greater than the master, and hence be considered out of sync, or
> will be at version 0, unable to reach version 2 via log entries
> since version 1 was removed from the log in step #5.