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 >slaves >> 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. >Harald.