[Maria-developers] Contributing in Support for GTID in mysqlbinlog for GSoC'15
HI Kristian, I am Rohit Kashyap, I am currently working on MDEV-7569 and recently came over to your post on Support for GTID in mysqlbinlog [MDEV-4989] I would like to ask you for guidance and leads on this so that I can take it up as my GSoC'15 Project under MariaDB. -- Kind Regards, Rohit
Rohit Kashyap <rkgudboy@gmail.com> writes:
I am Rohit Kashyap, I am currently working on MDEV-7569 and recently came over to your post on Support for GTID in mysqlbinlog [MDEV-4989] I would like to ask you for guidance and leads on this so that I can take it up as my GSoC'15 Project under MariaDB.
So I took a quick look at what mysqlbinlog currently supports, and how it could be extended to GTID. Looks like it's actually pretty clear: - The --start-position and --stop-position options should be able to take GTID positions; or maybe there should be new --start-gtid and --stop-gtid options. Like "--start-gtid=0-1-100,1-2-200,2-1-1000". - A GTID position means the point just _after_ that GTID. So starting from GTID 0-1-100 and stopping at GTID 0-1-200, the first GTID output will probably be 0-1-101 and the last one 0-1-200. Note that if some domain is not specified in the position, it means to start from the begining, respectively stop immediately in that domain. - Starting and stopping GTID should work both with local files, and with --read-from-remote-server. For the latter, there are a couple of extra things that need doing in the master-slave protocol, see get_master_version_and_clock() in sql/slave.cc. - At the end of the dump, put these statements as discussed in the bug: SET session.server_id = @@global.server_id, session.gtid_domain_id=@@global.gtid_domain_id; Probably some more things will come up during the work, but this looks like a reasonable start. I would recommend to start by reading the GTID documentation, and experimenting with all the relevant features described there, to familiarise yourself with it. The main thing is to understand the concept of GTID position and binlog order, and the relation to replication domains: https://mariadb.com/kb/en/mariadb/global-transaction-id/ And similarly, familiarise yourself with mysqlbinlog and how it would make sense for it to be extended to support GTID. Then make a detailed proposal for how the user-visible interface of mysqlbinlog should be extended, and send it to the list for comments. The next step will be to understand the concept of binlog state (@@gtid_binlog_state), and how it is used to deal correctly with out-of-order GTID sequence numbers in binlogs. This is mostly an internal implementation detail, but necessary to be able to correctly identify starting and stopping GTID positions in all cases. Hope this helps, - Kristian.
Hi Kristian, I am having a doubt, GTID assignss unique identifier to every transaction. And gtid_mode variable is not dynamic.Should the constraint of matching the master and replica be dropped to implement this. On 2/23/15, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Rohit Kashyap <rkgudboy@gmail.com> writes:
I am Rohit Kashyap, I am currently working on MDEV-7569 and recently came over to your post on Support for GTID in mysqlbinlog [MDEV-4989] I would like to ask you for guidance and leads on this so that I can take it up as my GSoC'15 Project under MariaDB.
So I took a quick look at what mysqlbinlog currently supports, and how it could be extended to GTID. Looks like it's actually pretty clear:
- The --start-position and --stop-position options should be able to take GTID positions; or maybe there should be new --start-gtid and --stop-gtid options. Like "--start-gtid=0-1-100,1-2-200,2-1-1000".
- A GTID position means the point just _after_ that GTID. So starting from GTID 0-1-100 and stopping at GTID 0-1-200, the first GTID output will probably be 0-1-101 and the last one 0-1-200. Note that if some domain is not specified in the position, it means to start from the begining, respectively stop immediately in that domain.
- Starting and stopping GTID should work both with local files, and with --read-from-remote-server. For the latter, there are a couple of extra things that need doing in the master-slave protocol, see get_master_version_and_clock() in sql/slave.cc.
- At the end of the dump, put these statements as discussed in the bug: SET session.server_id = @@global.server_id, session.gtid_domain_id=@@global.gtid_domain_id;
Probably some more things will come up during the work, but this looks like a reasonable start.
I would recommend to start by reading the GTID documentation, and experimenting with all the relevant features described there, to familiarise yourself with it. The main thing is to understand the concept of GTID position and binlog order, and the relation to replication domains:
https://mariadb.com/kb/en/mariadb/global-transaction-id/
And similarly, familiarise yourself with mysqlbinlog and how it would make sense for it to be extended to support GTID.
Then make a detailed proposal for how the user-visible interface of mysqlbinlog should be extended, and send it to the list for comments.
The next step will be to understand the concept of binlog state (@@gtid_binlog_state), and how it is used to deal correctly with out-of-order GTID sequence numbers in binlogs. This is mostly an internal implementation detail, but necessary to be able to correctly identify starting and stopping GTID positions in all cases.
Hope this helps,
- Kristian.
-- Kind Regards, Rohit
Rohit Kashyap <rkgudboy@gmail.com> writes:
I am having a doubt, GTID assignss unique identifier to every transaction. And gtid_mode variable is not dynamic.Should the constraint of matching the master and replica be dropped to implement this.
I am sorry, I do not understand what you are asking? Agree, GTIDs are unique for every transaction. But I do not understand about gtid_mode. There is no ariable "gtid_mode" in MariaDB. Do you mean gtid_strict_mode? But gtid_strict_mode is dynamic. And what do you mean with "contraint of matching the master and replica"? I do not see why any constraints on replicas would be needed with respect to MDEV-4989. - Kristian.
participants (2)
-
Kristian Nielsen
-
Rohit Kashyap