Pavel Ivanov <pivanof@google.com> writes:
Note that the user should not update mysql.rpl_slave_state manually. Except perhaps to ALTER TABLE ... ENGINE=xxx (which can be replicated).
BTW, why did you allow to create rpl_slave_state with MyISAM? I mean I
Well, otherwise it becomes impossible to run the server without InnoDB. It should also be possible to use another transactional storage engine, like Tokutek (multi-engine transactions are quite expensive due to the need for XA to synchronise all changes, so mysql.rpl_slave_state should use the same engine as most DML). Currently I create the mysql.rpl_slave_state table with the default storage engine. Which is InnoDB, unless the user configured it otherwise. This was the best I could think of, but I agree it is important to avoid it becoming MyISAM by mistake, so any suggestions for improvements are welcome.
understand it could help for the tests to not have unnecessary warnings. But what about real setups? Won't having rpl_slave_state in MyISAM on the replicating MariaDB instance be actually dangerous and can easily break replication in case of any crashes?
Well, yes, it's the same as having any other table in MyISAM. Or old-style replication, which uses a simple file relay-log.info. With mysql.rpl_slave_state in InnoDB, replicating transactional DML becomes crash-safe, but MyISAM DML and any DDL can still break replication if we crash in the middle.
To change the GTID position, use SET GLOBAL gtid_pos='0-1-10', which will update mysql.rpl_slave_state as needed.
Hm... In what situation this could be necessary?
It's not really needed. You might use it to specify starting position for a new slave, as an alternative to master_file_name and master_file_pos.
That's great news... :) Wait... Wasn't 10.0.2 planned as beta? It's alpha now? Does that mean GA probably moved much further?
I do not think plans have changed, however personally I think it's good to do a couple more point releases to make it easier for people to test. - Kristian.