Repository navigation
[Proposal]: Modernising MySQL CDC: Readable Changes and Native Parallel Replay #169
Description
Pre-flight Checklist
- I have searched existing GitHub issues and did not find a duplicate proposal.
- I have removed or redacted sensitive information.
Primary Contact Name
Karolina Szczepankiewicz
Primary Contact Email
karolina.szczepankiewicz@oracle.com
Company / Organization
Oracle
Role
Replication team
Additional Authors / Contributors
No response
Component
Server
Target Release (Optional)
No response
Roadmap Section
Developer/DBA Experience
Related Issues / Pull Requests / References (Optional)
Bug #121530 https://bugs.mysql.com/bug.php?id=121530
Executive Summary
MySQL's binary log records changes for replication and recovery, but using those changes in applications requires substantial interpretation outside MySQL, either in application code or through an external tool. This includes decoding row values, associating them with columns and interpreting DDL to follow schema evolution.
mysqlbinlog already supports inspection and replay. Its verbose row output helps users inspect changes, but does not provide a structured, application-readable change stream that can also be replayed through MySQL's parallel replication applier.
Users who need both application consumption and replay into MySQL need to preserve more than row values. Schema changes must remain aligned with the data they affect, and replay must preserve transaction contents, boundaries and original GTID identity. Reconstructing SQL writes from decoded changes can also introduce behavior different from native row application, such as firing destination triggers again.
The requested enhancement is a readable, lossless representation of recorded changes that exposes row values and structured schema-change information while retaining compatible DDL for replay. The same stream should be consumable by applications and replayable through MySQL's parallel replication applier, preserving transaction contents, boundaries, original GTID identity and native row-application semantics.
It should retain stream continuation and allow replay to resume based on transactions already committed on the destination.
User / Developer Stories
No response
Proposed Scope
No response
Out of Scope / Future Work
No response
References
No response
Functional Requirements
No response
Non-functional Requirements
No response
Impact Areas
- SQL syntax or statements
- Configuration options or system variables
- Command-line options or utilities
- User-visible behavior
- Observability
- Security or privilege model
- Protocol or replication behavior
- Upgrade / downgrade compatibility
- Performance or resource usage
- Files, persistence, or metadata formats
- APIs or internal interfaces
- Testing or QA coverage needs
Summary of the Approach
No response
User Interface
No response
Configuration / Knobs
No response
Observability
No response
User Procedure
No response
Security Considerations
No response
Compatibility and Behavior Changes
No response
Block Diagram
No response
Interface Specification
No response
Proposed Implementation Plan
No response
QA Notes
No response
Activity
github-actions commentedon Oct 21, 2026
💬 A discussion has been created in Developer / DBA Experience:
#170
Please continue community discussion there while this issue remains the authoritative tracking item.