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
>the code
>> above was added back, truncating the log to version 0 would make all
>> fetch the complete database over and over again until a modification
>bumps the
>> version at the master.
>That would be unfortunate ;-)

it would, but truncating the log doesn't set the version to 0.


Reply via email to