maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Massimiliano Pinto <massimiliano.pinto@xxxxxxxxxxx> writes:

First, Massimiliano, please use the maria-developers@ list for all discussions
about development on mariadb and related projects. It is very important to
keep all communication in the open and work against mariadb becoming a
proprietary SkySQL project rather than an open community project.

> we started working with MariaDB 10 master & slaves setup with MaxScale
> binlog router (which was developed for MySQL 5.6 without GTID support)

> Trying first MariaDB 10 setup we found this statement sent from Slave
> to Master (maxsacle here)
>
>
> (1) SET @mariadb_slave_capability=4

Check the MARIA_SLAVE_CAPABILITY_* #defines in sql/log_event.h.

When connecting, a slave announces its capabilities (which is basically its
version). This tells the master about which events are understood by that
version of the slave. The master will check each event if it can be handled by
the slave. If not, the event will be converted on-the-fly to something the
older slave can understand.

For example, a MariaDB 5.5 (or MySQL) slave does not understand GTID
events. So a MariaDB 10.0 master will convert the GTID event into a BEGIN
query event for slaves that have capability < MARIA_SLAVE_CAPABILITY_GTID (4).

If you are accepting connections from a slave, you can do the same
conversion. If you do not, then older version slaves might break if they
receive events generated by newer version master. You can decide which
approach makes sense for your project.

If you are connecting to a master, then you need to announce your
capability. If you do not, you will be interpreted by the master as having an
old version, and newer events (like GTID) will be filtered out and not seen.

> We soon got another one statement not handled:
>
> (2) SELECT binlog_gtid_pos('mst-bin.000001',310)

This is used by the slave to obtain the correct GTID position corresponding to
the position at which it is starting, when it is connecting in non-GTID mode.

When the slave has this information, it becomes easy for the DBA to switch to
a new master using GTID:

  STOP SLAVE;
  CHANGE MASTER TO master_host='new_master', master_use_gtid=slave_pos;
  START MASTER;

This works even if the slave was not using GTID mode prior to the CHANGE
MASTER, thanks to that SELECT binlog_gtid_pos().

> we are not handling it (just return the MaxScale default error message
> to the connected client)

Then the connected client/slave will assume this is an old master that does
not support GTID. So the slave will not know the correct GTID position, and
the easy CHANGE MASTER above may not be sufficient. Again, maybe that is fine
for you, if you do not plan to support GTID.

> We would like to hear your point of view, for (1)
> @mariadb_slave_capability, how to handle it? What does it mean? Any
> possible issues with different values?
> Will this prevent us the use of Binlog router with MariADB 10?
>
> And for (2), is that ok just to ignore it? Would we get issues?

I hope the above answers it (else ask again).
Basically, you can ignore (1) and return error in (2), and things should work
similar to MariaDB 5.5. But there will be reduced functionality compared to
MariaDB 10.0/10.1.

 - Kristian.