maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

[Cc: maria-developers@, in case others are interested or have comments]

Elena Stepanova <elenst@xxxxxxxxxxxxxxxx> writes:

>> So if you agree, I will put on my ToDo to remove that omitted domain_id
>> defaults to 0.
>
> It's fine with me.

Pushed to lp:~maria-captains/maria/10.0-mdev26/

>> Clearly I need to give a better error message, this is highly
>> confusing. Thanks for bringing this to attention! What do you think of:
>>
>>      ERROR XXXX: Duplicate domain_id 0 for GTID 0-2-1

I made it like this:

    MariaDB [test]> change master to master_gtid_pos="0-1-2,1-1000-1000,2-3-1,0-2-100,4-4-4";
    ERROR 1941 (HY000): GTID 0-2-100 and 0-1-2 conflict (duplicate domain id 0)

> Sounds good. Only, if I understand correctly, it's nowadays not
> domain_id, but gtid_domain_id ? Then it's better be named as such in
> the error message (/me tried in vain to set domain_id, first on the
> server command line, and then in a session).

Well, these are different but related concepts.

@@gtid_domain_id is a system variable. A "domain id" is a conceptual thing
when taking about global transaction ID. It is like the InnoDB buffer
pool. The system variable is "innodb_buffer_pool_size". The concept is "buffer
pool size".

But I agree the concept should be "domain ID", not domain_id (with an
underscore).

The reason I spell this out is not to nitpick, but rather that I would welcome
suggestions for naming, I am terrible with naming. Do you think I should
rename @@gtid_domain_id and @@gtid_seq_no to just @@domain_id and @@seq_no? I
thought that was perhaps a bit too generic names, though I did keep plain
@@server_id for backwards compatibility.

Another option is @@binlog_domain_id and @@binlog_seq_no, this is perhaps
better than the random "gtid" prefix? The variables are for controlling what
goes into the binlog, after all.

> But on the other hand, why should it be several rows? If
> binlog_gtid_pos() returns a *single* comma-separated list of GTIDs for
> the given position, as it does now, we can just as well add this list
> to SHOW MASTER STATUS as a *column*, no?

Sorry, it was me who was confused. I meant adding extra columns, not rows.

I am still not sure if it is safe to add extra columns. It would seem useful,
unless it breaks too many existing applications.

>> Start after. GTID is the last event executed.

> Hm... I must admit I don't quite understand the reasoning. I'll ask

Let me give an example. Suppose server 1 is master. It binlogs an event with
GTID 0-1-10. This event is currently the last in the binlog.

Server 2 is a slave of server 1. When it catches up, GTID 0-1-10 is the last
event applied on the slave.

So now, what should be the replication state of slave server 2? If we want to
use "start from" we could try GTID 0-1-11? But then suppose we now switch
master to a new server 3. Then the event following 0-1-10 is 0-2-11, not
0-1-11. So if server 2 would try to connect as a slave to server 3 and start
from 0-1-11, it will not work, this event does not exist anywhere.

That is why it has to be "start after", as when we save the state on the
slave, we know only the GTID of the last event applied, not the one to apply
next.

> There might be more in there for me to look into..

Indeed. This is a critical part of the design, I spent a _lot_ of thought to
get this working, and I think I got it right, but I will feel a lot better
knowing you spent your best efforts to break it :-). But please wait with this
for a later stage, I have some planned development around this that is not
ready yet.

>> Gtid_Pos_Auto=1 means the new method, whether AUTO or explicit 'xxx' gtid,
>> So what should we call it? How about just "Using_Gtid" ?
>
> Yep, Using_Gtid sounds fine.

This is fixed in the tree now.

> This brings a more conceptual question for me... Does Using_Gtid
> indicate how the slave *replicates*, or just how it determines the
> starting position while connecting to master? In other words, is there

There is a difference. There are two ways a slave can connect. The old way
using binlog file and position. And the new way using GTID. I think we need to
have both. The Using_Gtid records which of the two is used. I made it this way
so that users do not need to set some specific option in my.cnf, and so that
with multi-source, one slave connection can use the old style (eg. master not
supporting GTID?), while another can use new style.

The main difference is finding the starting position. But this also implies
difference for how the slave replicates. Because with GTID there can be
*multiple* starting positions (one for each domain id). So after connecting,
some events can be skipped during replication if one domain_id is ahead of
another in the master binlog.

> If not (and I couldn't yet figure the difference, since, as you said,
> the slave reads the GTID state anyway when it connects with file
> name/offset), then I start having doubts that we need the Using_Gtid
> flag at all. I mean, if it only indicates what I provided last time in
> CHANGE MASTER, how is this information useful?

It is used when the slave connects (which happens at every START SLAVE, and
every server restart, including mysqld_safe autostart).

If Using_Gtid is false, then slave connects at the last file/offset found in
relay-log.info. It also obtains the corresponding GTID position from the
master, so that it is ready in case the user wants to switch to CHANGE MASTER
TO ... MASTER_GTID_POS=AUTO.

If Using_Gtid is true, slave connects at the GTID position read from the
mysql.rpl_slave_state table, which is crash safe. And multiple start positions
are used if there is more than one domain id in the GTID position.

So you see, the information is needed, otherwise the slave and the master
would not know how to handle slave connect.

>> But frankly, I am not sure if the right place is in SHOW ALL SLAVES STATUS or
>> in plain SHOW SLAVE STATUS. Can you help me understand what the difference is
>> between putting the column in one or the other of these?
>
> I guess the only real reason was that Monty didn't want to change the
> output format of existing SHOW SLAVE STATUS, not to break anything.

Yes, this is an important issue. I will discuss it with Monty when I visit him
next week.

> Ideally, I'd expect the global values be shown both in SHOW SLAVE
> STATUS, e.g. at the end of it, and once for all slaves in SHOW ALL
> SLAVES STATUS, again at the end. But I don't know if it's doable, and
> if it is, we need to think what it might break.

Yes. The code actually seems to have been written for something like SHOW FULL
SLAVE STATUS, which would include the extra data. I will need to ask Monty to
know more.


> Then I assumed you decided not to print current GTIDs in SHOW SLAVE
> STATUS on purpose, to avoid the mess like MySQL has -- which was also
> surprising since we wouldn't have that insanity anyway.
> I didn't ask how I could obtain them on slave, as I figured it was
> supposed to be done via mysql.rpl_slave_state. But it didn't occur to
> me that it was printed in SHOW ALL SLAVES STATUS...

Yes. In any case, the user interface is very much not finalised yet. Sorry for
the rough experience, but hopefully we can use your experience to come up with
a good interface for the final release.

>> Maybe the problem is that if I add a column in SHOW SLAVE STATUS, and MySQL
>> adds another column in the same position, then scripts will break because the
>> column count for one or the other will change?
>
> eh.. MySQL's show slave status currently has like +13 columns
> comparing to ours, I really don't think that scripts relying on such
> level of detail stand any chance to survive.

My main worry is not if one has more than the other. The worry is if some
column is in position 25 (say) in MySQL but 28 (say) in MariaDB. Is there even
any easy way to pick out a column by name, rather than numerical position?

> Good thing you mentioned it, I actually totally forgot to tell the
> tale of my *very* first experience. Well, I started when I mentioned

> Then I followed the instruction again, and... it didn't work. It
> didn't crash, replication didn't fail, but when I switched master and
> slave, the new slave (old master) just wouldn't replicate the last
> line, (6,3).
>
> I couldn't understand it until I compared the flow and configuration
> with the MTR test that you have (it does basically the same, and it
> works), and only then I figured that I have to have
> log-slave-updates=on. It wasn't clear to me why, I mean, I had the
> transaction in quesiton in the binlog, and GTID was there too,
> so?.. That's when I switched from AUTO to explicit values and started
> experimenting with them.

Well, in my example, first server 1 is the master, then I switch around so
that server 2 is the master. For a slave to also be able to serve as master,
it needs --log-slave-updates=1, right?

On the other hand, the design specifically allows for --log-slave-updates=0.
I did fix one or two possibly related bugs lately, so please try again and if
you can reproduce the problem I will look into it.

(I was a bit confused how you could have the transaction in question in the
binlog on the server that was changed from slave to master, if it did not have
--log-slave-updates=1 ...)

> > But nothing happens... No errors in the slave, but it isn't moving, either:

> This looks like a bug, your commands look correct. I could reproduce, I will
> investigate and fix ASAP and let you know.

This should be fixed now and pushed to the tree.

> > Getting the wrong mutex usage warnings. I saw a discussion on IRC the other day, but don't know the current status -- whether it's supposed to be fixed, or not fixed yet, or is considered innocent...

This also should be fixed in the tree now.

 - Kristian.

(who now has to run from the computer and hopes the above makes sense...)