[MXS-1075] Support MariaDB GTID in binlog replication handshake with MariaDB 10 Slaves Created: 2017-01-12  Updated: 2017-08-24  Resolved: 2017-03-29

Status: Closed
Project: MariaDB MaxScale
Component/s: binlogrouter
Affects Version/s: None
Fix Version/s: 2.2.0

Type: Task Priority: Major
Reporter: Dipti Joshi (Inactive) Assignee: Massimiliano Pinto (Inactive)
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
PartOf
is part of MXS-1155 Define a set of features for better i... Closed
Sprint: 2017-27, 2017-28, 2017-29, 2017-30, 2017-31

 Description   

(1) Use GTID in handshake with MariaDB Master server
When
CHANGE MASTER TO master_host='<host-ip>', master_user='<usr>', master_password='<password>', master_use_gtid=slave_pos
is executed on MaxScale, request the master to send binlog starting from GTID corresponding to slave_pos; where slave_gtid_pos is the last

(2) Accept GTID in handshake from a MariaDB Slave. When Slave requests MaxScale to send binlog starting from slave_pos - start sending binlog record to the particular slave from the GTID corresponding to requested slave_pos



 Comments   
Comment by Massimiliano Pinto (Inactive) [ 2017-01-13 ]

MaxScale to Master registration with GTID implies registration process modification and possibly some checks at startup and configuration options

The slave registration phase to maxscale requires GTID handling:

the GTID must be extracted from current binlog file and possibly from old ones.

Kind of a database software is required, even i memory only, to store data whitout scanning binlog file all the time.

Tests from mariadb 10.0 and 10.1 should be done soon in order to check that everithing is ok before starting the implementation.

The provided estimation includes those preliminary tests.

Comment by Massimiliano Pinto (Inactive) [ 2017-02-15 ]

With the "develop" branch the binlog server reports now:

MySQL [(none)]> select @@gtid_current_pos;
--------------------

@@gtid_current_pos

--------------------

0-10116-36

--------------------
1 row in set (0.00 sec)

MySQL [(none)]> select @@global.gtid_current_pos;
---------------------------

@@global.gtid_current_pos

---------------------------

0-10116-36

---------------------------
1 row in set (0.00 sec)

and via maxadmin show services

Last event from master: 0x10, Transaction ID Event (2 Phase Commit)
Last seen MariaDB GTID: 0-10116-36
Last binlog event timestamp: 1487006091 (Mon Feb 13 18:14:51 2017)

Next steps are:

  • Slave connecting to maxscale via GTID: gtids must be saved in oder to send related binlog events
  • MaxScale connecting to master: as binlog server is a replication proxy and not an intermediate master with its own binlog files, some issues have to be managed.
    More comments will follow on this.
Comment by Massimiliano Pinto (Inactive) [ 2017-02-21 ]

Just managed a basic hastable store for GTID being received.

First tests show that a MariaDB 10 Slave can register to maxscale this way:

set @@global.gtid_slave_pos='0-10116-78' // this is a GTID maxscale is aware of
change master to master_use_gtid=slave_pos;

start slave;

And after a few inserts into the master, replication follows

MariaDB [(none)]> select @@gtid_slave_pos;
------------------

@@gtid_slave_pos

------------------

0-10116-84

------------------

This is the very first step.

More work needs to be done for transaction safety compatibility and later for a proper storage.

Comment by Massimiliano Pinto (Inactive) [ 2017-02-28 ]

Current work is in MXS-1075 branch

https://github.com/mariadb-corporation/MaxScale/tree/MXS-1075

Generated at Thu Feb 08 04:04:03 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.