Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
False
-
None
-
False
Description
In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.
Bug report
For bug reports, provide this information, please:
What Debezium connector do you use and what version?
mysql connector 1.9.0
What is the connector configuration?
Transaction metadata with GTIDs enabled
What is the captured database version and mode of depoyment?
(E.g. on-premises, with a specific cloud provider, etc.)
AWS RDS, debezium running on kubernetes
Context
For mysql transactions that touch multiple tables, we are seeing some weird behavior when the connector is restarted during kafka rebalancing while its in the middle of reading all the statements for that transaction. It seems when the task restarts its unable to detect that the transaction is in progress, emits another BEGIN transaction event which resets the event count. This leads to the new DML events for that transaction having a event count of 1, 2 and so on, instead of continuing from where it left off.
What behaviour do you expect?
If the transaction that has multiple data collection events is in progress, when a rebalance occurs, it should continue the event count in the DML event from that position in the transaction.
What behaviour do you see?
The transaction is begun again and the event count starts from 1, instead of continuing from where it left off
https://github.com/debezium/debezium/blob/main/debezium-core/src/main/java/io/debezium/pipeline/txmetadata/TransactionMonitor.java#L123
https://github.com/debezium/debezium/blob/b0175ead02beeea27596067435cc9f485dc45afc/debezium-core/src/main/java/io/debezium/pipeline/txmetadata/TransactionContext.java#L42
How to reproduce the issue using our tutorial deployment?
This is a single transaction with 34 updates to the trancache table. The rebalance happened after the 32nd update is read. Next event count resets to 0 instead of continuing from 33, 34 etc.
The offset committed in the offsets topic shows the data collecton order for trancache as 32 accurately.
event: 64 file: mysql-bin-changelog.018336 gtids: 3952ca99-3be6-11e9-800f-0e3be544ab8c:1-791776958,ede3b54f-b757-11ec-9b43-16d22656786d:1-29327556,ef0ff250-b763-11ec-bf33-1624a304bfdd:1-132 pos: 13284994 row: 1 server_id: 745911666 transaction_data_collection_order_sqc4_prod { trancache: 32 } transaction_id: ede3b54f-b757-11ec-9b43-16d22656786d:29327557 ts_sec: 1652205313
Message logs
TABLE | Entry date | Data Coll Order | TRANSACTION_STATUS | TRANSACTION_EVENT_COUNT |
---|---|---|---|---|
dbtransaction | 2022-05-10T17:55:13.926480Z | BEGIN | null | |
trancache_history | 2022-05-10T17:55:13.926493Z | 1 | ||
trancache_history | 2022-05-10T17:55:13.926625Z | 2 | ||
trancache_history | 2022-05-10T17:55:13.926677Z | 3 | ||
trancache_history | 2022-05-10T17:55:13.926715Z | 4 | ||
trancache_history | 2022-05-10T17:55:13.926761Z | 5 | ||
trancache_history | 2022-05-10T17:55:13.926823Z | 6 | ||
trancache_history | 2022-05-10T17:55:13.926880Z | 7 | ||
trancache_history | 2022-05-10T17:55:13.926926Z | 8 | ||
trancache_history | 2022-05-10T17:55:13.927044Z | 9 | ||
trancache_history | 2022-05-10T17:55:13.927173Z | 10 | ||
trancache_history | 2022-05-10T17:55:13.927222Z | 11 | ||
trancache_history | 2022-05-10T17:55:13.927275Z | 12 | ||
trancache_history | 2022-05-10T17:55:13.927335Z | 13 | ||
trancache_history | 2022-05-10T17:55:13.927470Z | 14 | ||
trancache_history | 2022-05-10T17:55:13.927516Z | 15 | ||
trancache_history | 2022-05-10T17:55:13.927562Z | 16 | ||
trancache_history | 2022-05-10T17:55:13.927607Z | 17 | ||
trancache_history | 2022-05-10T17:55:13.927652Z | 18 | ||
trancache_history | 2022-05-10T17:55:13.927762Z | 19 | ||
trancache_history | 2022-05-10T17:55:13.927805Z | 20 | ||
trancache_history | 2022-05-10T17:55:13.927859Z | 21 | ||
trancache_history | 2022-05-10T17:55:13.927899Z | 22 | ||
trancache_history | 2022-05-10T17:55:13.927956Z | 23 | ||
trancache_history | 2022-05-10T17:55:13.928076Z | 24 | ||
trancache_history | 2022-05-10T17:55:13.928123Z | 25 | ||
trancache_history | 2022-05-10T17:55:13.928168Z | 26 | ||
trancache_history | 2022-05-10T17:55:13.928219Z | 27 | ||
trancache_history | 2022-05-10T17:55:13.928338Z | 28 | ||
trancache_history | 2022-05-10T17:55:13.928379Z | 29 | ||
trancache_history | 2022-05-10T17:55:13.928435Z | 30 | ||
trancache_history | 2022-05-10T17:55:13.928481Z | 31 | ||
trancache_history | 2022-05-10T17:55:13.928639Z | 32 | ||
REBALANCE | 2022-05-10T17:55:13 | |||
dbtransaction | 2022-05-10T17:55:20.235422Z | BEGIN | null | |
trancache_history | 2022-05-10T17:55:20.356249Z | 1 | ||
trancache_history | 2022-05-10T17:55:20.377572Z | 2 | ||
dbtransaction | 2022-05-10T17:55:20.377726Z | END | 2 |
Feature request or enhancement
For feature requests or enhancements, provide this information, please:
Which use case/requirement will be addressed by the proposed feature?
<Your answer>
Implementation ideas (optional)
<Your answer>