On Wed, Apr 17, 2013 at 11:14 PM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Pavel Ivanov <pivanof@google.com> writes:
Could you please tell me, in your implementation of GTIDs did you make something special for the case when mysql database is replicated? I guess mysql.rpl_slave_state cannot be replicated in any circumstances, so did you put any safeguards to not replicate it or it's totally up to MariaDB users?
In rpl_slave_state::record_gtid(), there is this to prevent replicating updates of the mysql.rpl_slave_state table:
table->no_replicate= 1;
Other than that, I do not know of any special handling needed for the mysql database. Did you have something special in mind?
That's exactly what I had in mind -- that either there should be a mandatory use of --replicate-ignore-table for rpl_slave_state or something in the code with the similar effect.
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 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?
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?
BTW, yesterday I merged GTID into lp:maria/10.0, so now the code is in the main tree and will be included in the next 10.0.2 alpha release.
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? Pavel