maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #05505
Re: Documentation about GTID
Arjen Lentz <arjen@xxxxxxxxxxxxx> writes:
> In the section describing existing classic replication:
>
>> A slave server keeps track of the position in the master's binlog of the last
>> event applied on the slave. This allows the slave server to re-connect and
>> resume from where it left off after replication has been temporarily stopped.
>
>> It also allows to disconnect from the master server and connect to a
>> different server to resume replication from a new master, as long as the new
>> master has the proper binlog events, and the new master connection starts
>> replicationg at the appropriate point in the binlogs.
>
> The second sentence tends to never be true in the real world. The instances where two masters run at exactly the same binlog/pos are minimal to nonexistent. I suggest the following to replace:
>
> "It also allows a slave to disconnect, be cloned and then have the new slave resume replication from the same master."
>
> You really can't guarantee any more.
Thanks, I'll update this once the text is in the knowledgebase.
> Hmm - I understand the reasoning for this logic, but I'd prefer it to explicitly choose InnoDB rather than go for the engine default.
> Otherwise, with silly old configs on systems that we find in the real world, the initial upgrade can see the system end up not-crashsafe but without that being immediately obvious.
> Historically, it's things like that tend to cause "bad publicity" (people writing negative blog articles, etc).
>
> Perhaps this is not fixable without possibly having an upgrade process break, which is even less desirable.
Yeah, it is not trivial to get something that does the right thing in all
cases. The main problem is if we end up with a table in InnoDB during
mysql_install_db, but then the running server is myisam-only and has InnoDB
disabled (--skip-innodb). Then things break badly because the table is now
inaccessible.
The "default engine" was the best compromise I came up with so far. It seems
fairly reasonable, given that InnoDB is the default since 5.5. We still have
the problem with silly old configs, but at least eg. .deb default my.cnf does
not override the default engine.
- Kristian.
References