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
> delta.


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 
> they
>     will be at version 0, unable to reach version 2 via log entries
>     since version 1 was removed from the log in step #5.



Reply via email to