Re: iprop: Problem forcing complete database sync

On October 6, 2017 5:56:22 AM EDT, Harald Barth <[email protected]> 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.