← Back to team overview

maria-developers team mailing list archive

Re: GTID and replication of mysql database

 

On Wed, Apr 17, 2013 at 11:14 PM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Pavel Ivanov <pivanof@xxxxxxxxxx> 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


Follow ups

References