redo: make row flush batch size configurable - #5935
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe change adds ChangesRedo flush batching
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant APIModel
participant ConsistentConfig
participant WriterConfig
participant MemoryWorker
participant RedoFile
APIModel->>ConsistentConfig: provide FlushBatchSize
ConsistentConfig->>WriterConfig: pass validated value
WriterConfig->>MemoryWorker: configure row-count threshold
MemoryWorker->>RedoFile: write events
RedoFile-->>MemoryWorker: report file rotation
MemoryWorker-->>MemoryWorker: release callbacks after durable files
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
Let file size and the flush interval control persistence by default. Add consistent.flush-batch-size and wire it through both writer backends. close pingcap#5936
6fc0494 to
e740a10
Compare
Release post-flush callbacks as soon as size-rotated redo files are durable. Clear invoked callback slots to avoid retaining receivers through slice capacity, while preserving callback order across concurrent memory-backend uploads.
|
/test all |
What problem does this PR solve?
Issue Number: close #5936
The redo DML writers use a hard-coded 1024-row flush threshold. For
workloads with small row events and object storage, this can force frequent
small-file uploads before
max-log-sizeorflush-intervalis reached,amplifying object-store latency and checkpoint lag.
What is changed and how it works?
consistent.flush-batch-sizeto the changefeed configuration and v2 API.0. Zero disables count-based flushing, while a positive valueflushes after exactly that many row events.
policy.
Check List
Tests
go test -race --tags=intest ./pkg/config ./api/v2 ./pkg/redo/writer ./pkg/redo/writer/file ./pkg/redo/writer/memory ./downstreamadapter/sink/redoQuestions
Will it cause performance regression or break compatibility?
The default batching behavior changes intentionally: count-based flushing is
disabled instead of flushing every 1024 row events. Redo logs are still flushed
by
max-log-sizeandflush-interval.This reduces object-storage request amplification for workloads with many small
row events. It can retain more callbacks between periodic or size-based flushes.
Setting
flush-batch-size = 1024restores the previous count-based behavior.The redo log data format is unchanged.
Do you need to update user documentation, design documentation or monitoring documentation?
Yes. The TiCDC configuration documentation should describe
consistent.flush-batch-size, its default value, and the meaning of zero.Release note
Summary by CodeRabbit
New Features
flush-batch-size.Bug Fixes