You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon connection, the script informs the master node that the latest processed transaction is: b1988e6b-e20e-11ee-916d-0242ac350008:300. However, for some reason, MySQL continues to send past transactions (1,2,3,4 ... ), leading to event data duplication.
What could be causing this issue?
The text was updated successfully, but these errors were encountered:
I’m storing GTID b1988e6b-e20e-11ee-916d-0242ac350008:300. I start a connection and pass this GTID to the server. MySQL sends transaction b1988e6b-e20e-11ee-916d-0242ac350008:300 to the script. Since this is the latest transaction it processed, the script ignores it.
However, for some reason, MySQL then sends a very old GTID: b1988e6b-e20e-11ee-916d-0242ac350008:1. My script now stores this GTID and resumes using it on the next restart.
Seems like MySQL interprets GTID as a single transaction instead of a range
I'm storing only b1988e6b-e20e-11ee-916d-0242ac350008:300, but MySQL expects the full GTID set (1-300).
When I reconnect, MySQL does not see 1-299 as executed, so it resends them.
Maybe instead of passing only the last GTID, the lib should create the range of executed GTID set and pass it upon connection?
Stored GTID: b1988e6b-e20e-11ee-916d-0242ac350008:300
Final GTID passed to MYSQL: b1988e6b-e20e-11ee-916d-0242ac350008:1-300
Hi! I’ve noticed unexpected behavior when relying on GTID as a replication pointer.
Assume MySQL has executed the following transactions:
Upon connection, the script informs the master node that the latest processed transaction is:
b1988e6b-e20e-11ee-916d-0242ac350008:300
. However, for some reason, MySQL continues to send past transactions (1,2,3,4 ... ), leading to event data duplication.What could be causing this issue?
The text was updated successfully, but these errors were encountered: