maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Hi,

I've discovered a change in MariaDB 10.0.8 that I don't quite
understand motivation for and which looks really surprising to me. So
I would appreciate if you could tell me what's the motivation and why
you think it's appropriate to do that.

The change in question is
http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3961.1.7.
I see several issues with it:

1. It introduces a pretty significant variable slave_ddl_exec_mode
which wasn't announced in the Release Notes.

2. The default variable value was set to IDEMPOTENT which changes
MariaDB slave behavior in an incompatible way. Not everyone will want
to have this variable set to IDEMPOTENT (I'd actually argue that no
one should set it to IDEMPOTENT), but without any mentioning of this
variable in the Release Notes people basically have the only chance to
get knowledge about this change (let me stress out: _incompatible_
change) from production incidents or from accidental code inspection.

3. When slave_ddl_exec_mode is set to IDEMPOTENT every "DROP TABLE"
event in master's binlog is converted into "DROP TABLE IF EXISTS" in
slave's binlog, which I believe is a major no-no for replication.
Binlogs on master and slave should be identical, otherwise after
failover even if one would set slave_ddl_exec_mode = STRICT it will
still execute "DROP TABLE IF EXISTS" because new master has that in
binlogs.

4. Why this change introduces OPTION_GTID_BEGIN in the code? Why
OPTION_BEGIN wasn't enough? From reading the code the only thing I
understand is that with broken binlogs and sequence of events "GTID
BEGIN; CREATE TABLE; CREATE TABLE" MariaDB will try to execute both
CREATE TABLE statements in the same transaction without
auto-committing at the end. This sounds pretty crazy to me. And given
the fact that in normal situation such sequence of events on the
master is not possible it seems that existence of both OPTION_BEGIN
and OPTION_GTID_BEGIN only introduces confusion (MariaDB have GTID
always on, right? So it should always execute GTID_BEGIN and never
BEGIN without GTID, right?).


So what is your word on this? Can you at least set default value for
slave_ddl_exec_mode to STRICT so that slave behavior didn't change
with the version upgrade?


Thank you,
Pavel