Skip to content
This repository has been archived by the owner on Nov 24, 2023. It is now read-only.

relay's behaviour should align with MySQL when using GTID #1383

Closed
lance6716 opened this issue Jan 16, 2021 · 5 comments · Fixed by #1390
Closed

relay's behaviour should align with MySQL when using GTID #1383

lance6716 opened this issue Jan 16, 2021 · 5 comments · Fixed by #1390
Labels
severity/major type/bug This issue is a bug report

Comments

@lance6716
Copy link
Collaborator

lance6716 commented Jan 16, 2021

Bug Report

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html

The source responds by sending all transactions recorded in its binary log whose GTID is not included in the GTID set sent by the replica. To do this, the source first identifies the appropriate binary log file to begin working with, by checking the Previous_gtids_log_event in the header of each of its binary log files, starting with the most recent. When the source finds the first Previous_gtids_log_event which contains no transactions that the replica is missing, it begins with that binary log file. This method is efficient and only takes a significant amount of time if the replica is behind the source by a large number of binary log files. The source then reads the transactions in that binary log file and subsequent files up to the current one, sending the transactions with GTIDs that the replica is missing, and skipping the transactions that were in the GTID set sent by the replica. The elapsed time until the replica receives the first missing transaction depends on its offset in the binary log file. This exchange ensures that the source only sends the transactions with a GTID that the replica has not already received or committed. If the replica receives transactions from more than one source, as in the case of a diamond topology, the auto-skip function ensures that the transactions are not applied twice.

  1. getPosByGTID may choose start position by

    choose a relay log file that its "Previous_gtids_log_event" don't overlap with "complementary set of given GTID set", which could reduce to "Previous_gtids_log_event" is subset or equal to "given GTID set"

  2. scan the relay log and skip the transactions in "given GTID set", to handle cases when given GTID set is not continuous like uuid:1-10:20-30

@lance6716 lance6716 added severity/major type/bug This issue is a bug report labels Jan 16, 2021
@lance6716
Copy link
Collaborator Author

lance6716 commented Jan 18, 2021

when MySQL use GTID replication and slave didn't enable binlog, user can't use slave as upstream of DM because DM is based on binlog replication. Assuming at that time the GTID set is

xxx:1-10

User enables binlog on slave then, the first binlog of slave will have an empty Previous_gtids, and next binlog files will have Previous_gtids starting from 11. Meanwhile select * from mysql.gtid_executed or select @@global.gtid_executed will output GTID set starting from 1, select @@global.gtid_purged will output xxx:1-10

@GMHDBJD
Copy link
Collaborator

GMHDBJD commented Jan 18, 2021

Did you use MASTER_AUTO_POSITION = 1 ?

@lance6716
Copy link
Collaborator Author

Did you use MASTER_AUTO_POSITION = 1 ?

didn't use it when CHANGE MASTER

@GMHDBJD
Copy link
Collaborator

GMHDBJD commented Jan 18, 2021

What's the output of show master status ? Does the output start from 1?

@lance6716
Copy link
Collaborator Author

What's the output of show master status ?

starting from 1. accroding to MySQL doc, show master status will output gtid_executed

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity/major type/bug This issue is a bug report
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants