sink/mysql: split DML and control DB pools - #5397
Conversation
|
Skipping CI for Draft Pull Request. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe MySQL sink is refactored from owning a single long-lived connection to managing a slice of owned DB pools. A new ChangesSeparate DML and control-plane DB pools for MySQL sink
Sequence Diagram(s)sequenceDiagram
participant Dispatcher
participant Sink
participant dmlDB as dmlDB<br/>(DML pool)
participant controlDB as controlDB<br/>(Control pool)
Dispatcher->>Sink: WriteEvents (DML rows)
Sink->>dmlDB: batched INSERT statements
dmlDB-->>Sink: row count
Dispatcher->>Sink: WriteBlockEvent (DDL)
Sink->>controlDB: upsert ddl_ts table
Sink->>controlDB: execute DDL statement
Sink->>controlDB: update syncpoint/progress
controlDB-->>Sink: completion
Dispatcher->>Sink: Close()
Sink->>dmlDB: close pool
Sink->>controlDB: close pool
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request introduces separate database connection pools for DML and control-plane operations in the MySQL sink to prevent control-plane tasks from being blocked by long-lived DML sessions. A critical issue was identified in newMysqlConfigAndDB where returning nil for the named return parameter db on error causes a nil pointer dereference panic in the deferred cleanup function, leading to a database connection leak. A code suggestion was provided to capture the connection in a local variable before deferring the cleanup.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/test all |
|
/test pull-cdc-mysql-integration-light |
|
/test pull-cdc-mysql-integration-light |
|
/test pull-cdc-mysql-integration-light |
|
/test pull-cdc-mysql-integration-light |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lidezhu, wk989898 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/cherry-pick release-8.5 |
|
@hongyunyan: new pull request created to branch DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
What problem does this PR solve?
Issue Number: close #5360
The MySQL sink used one shared
*sql.DBpool for DML writers and control-plane work such as DDL execution, DDL-ts metadata, syncpoint metadata, and active-active progress updates. When a DML writer held the only available connection, control-plane operations could block while waiting for a connection. In the reported failure, the DDL was received and dispatched but did not reach downstream because the DDL path could not acquire a connection from the shared pool.What is changed and how it works?
This PR splits the MySQL sink connection usage into two independent bounded pools created from the same effective DSN:
NewMysqlConfigAndDBsingle-pool API is preserved for existing callers.NewMysqlConfigAndDBshelper creates the sink-specific DML/control pools and closes the DML pool if control pool creation fails.MySQLSinkForceSingleConnectionnow only constrains the DML pool, so the stress path can still simulate DML session starvation without starving DDL/control operations.Sink.Closecloses both pools and avoids double-closing when tests pass the same DB for both.The control pool is bounded to 4 open and idle connections.
Check List
Tests
Commands:
make fmtgo test --tags=intest ./pkg/sink/mysql ./downstreamadapter/sink/mysqlNot run:
make integration_test_mysql CASE=ddl_default_current_timestamp, becausemake check_third_party_binaryfails in this worktree: the required third-party binaries underbin/are not present.Questions
Will it cause performance regression or break compatibility?
No compatibility break is expected. Existing single-pool factory callers keep the same API. The MySQL sink now opens a small additional control pool, which should reduce DDL/control starvation risk. The DML pool keeps one extra connection for prepared-statement cache misses instead of reserving the historical broader control-plane margin.
Do you need to update user documentation, design documentation or monitoring documentation?
No.
Release note
Summary by CodeRabbit
Improvements
Tests