On Fri, Oct 06, 2017 at 09:29:33AM -0400, Jeffrey Hutzelman wrote:
> On October 6, 2017 5:56:22 AM EDT, Harald Barth <h...@kth.se> wrote:
> 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.
We do think there may be version rollover issues (it's only 32 bits...),
but that's not very realistic for Kerberos. We feel that
lib/kadm5/log.c is solid now, but the ipropd-master.c and ipropd-slave.c
code still has dark corners and need a thorough code review.
> 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.
> >I think the log can be at version 0 (which means "invalid, please
> >recover") but the database should not be able to be at version 0.
> only an empty, never-initialized log can be at version 0.
> databases don't have versions; they're entirely an artifact of the log
Correct as well.
Having the HDB and the iprop layers be so disjoint has pros and cons.
The biggest pro is that iprop can work for any HDB backend that doesn't
have its own replication system. The biggest con is that the
disjointedness can mean that if the two get out of sync, you have a
problem (e.g., save the iprop log, turn off ipropd-master, do a bunch
of transactions, restore the iprop log, restart ipropd-master: the
slaves will miss those transactions).