Re: [Maria-developers] GTID and replication of mysql database
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? Note that the user should not update mysql.rpl_slave_state manually. Except perhaps to ALTER TABLE ... ENGINE=xxx (which can be replicated). To change the GTID position, use SET GLOBAL gtid_pos='0-1-10', which will update mysql.rpl_slave_state as needed. 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. - Kristian.
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
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.
On Thu, Apr 18, 2013 at 1:02 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
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.
I still don't quite understand when this can be necessary except maybe for tests. New slave should be restored from backup and thus it will already have this information in rpl_slave_state. Completely new just bootstrapped slave makes sense only if master was started completely new recently. But then slave will start to replay master's binlogs from the very beginning, right? What am I missing? Pavel
Pavel Ivanov <pivanof@google.com> writes:
I still don't quite understand when this can be necessary except maybe for tests. New slave should be restored from backup and thus it will
I agree that it should not be needed in normal production use. - Kristian.
participants (2)
-
Kristian Nielsen -
Pavel Ivanov