maria-developers team mailing list archive

[Arjen Lentz <arjen@xxxxxxxxxxxxx>]

Hi Kristian, Daniel

> here (attached) is my first stab at documentation for MariaDB GTID.

good stuff!


A few comments:

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.



Then, later on:

> In order to be crash-safe, this table must use a transactional storage
> engine such as InnoDB. When MariaDB is first installed (or upgraded to 10.0),
> the table is created using the default storage engine - which itself defaults
> to InnoDB.

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.
But if there is another viable route, please consider.
thanks


Regards,
Arjen.
-- 
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Australian peace of mind for your MySQL/MariaDB infrastructure.

Follow us at http://openquery.com/blog/ & http://twitter.com/openquery