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 --reset. > 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. Yes. 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 them. > #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. Yes. Nico --
