And now I found that this change is actually buggy. It turns out that
when slave executes a standalone CREATE TABLE event now it will set
OPTION_BEGIN flag in thd->variables.option_bits and won't reset it. I
don't know whether slave keeps transaction actually not committed
and/or whether it doesn't clean up some other transaction data, but
execution of the next event will always think there is a transaction
open and it needs to be auto-committed. But that also means that this
state cannot be distinguished from the case when slave received BEGIN
event, but didn't receive COMMIT event, i.e. either binlog on master
is corrupted or slave somehow skipped some events.
Would MariaDB consider this as a serious problem?
On Fri, Feb 21, 2014 at 12:30 AM, Pavel Ivanov
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