On October 6, 2017 5:56:22 AM EDT, Harald Barth <h...@kth.se> wrote:
>Removing that without putting something else in place (and I would say
>not only s->version == 0 but even current_version == 0 should trigger
>a send_complete) was probably a bad idea.
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.
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.
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
>> Unless I am missing something this would mean that if something like
>> above was added back, truncating the log to version 0 would make all
>> fetch the complete database over and over again until a modification
>> version at the master.
>That would be unfortunate ;-)
it would, but truncating the log doesn't set the version to 0.