Replication / Cupcake field notes
How to set up MySQL CDC on macOS
A practical workflow for bringing MySQL change capture into Cupcake-DRCP for macOS, with verification at each handoff.
1. Define the source, target, and scope.
Create your connection entries and validate them. Choose the source and target databases, then build a plan that pairs the tables and maps their columns. Review primary keys, filters, and conversions before data starts moving. For a cross-database target, see the MySQL-to-PostgreSQL replication workflow.
Your Mac needs network access to both endpoints. The engine runs locally, but the databases can be elsewhere on networks you can reach. Test the workflow against an appropriate non-production target before using the same approach for a production change.
2. Establish a known baseline.
Change capture needs a target whose starting point you understand. Use the snapshot workflow to seed it, checking the destination and the actions the app proposes before confirming. A baseline copy can replace target data depending on the selected operation.
Wait for the actual run outcome. A job appearing in the queue is not the same as a completed copy. Review errors and the table scope, then compare the result before treating the target as ready.
3. Check what the source can provide.
Cupcake offers binlog-based capture for supported MySQL sources and primary-key sweep where the workflow requires it. These methods have different source requirements and workload characteristics. The app’s readiness result should guide the decision.
For MySQL binlog capture, review row-based logging and the source account’s required privileges with the database owner. Binary logging configuration is documented in the MySQL binary logging reference. Do not assume a successful ordinary connection proves the account can read a change stream.
A primary-key sweep reads row ranges rather than replaying a database log. Its cost depends on the data being scanned. Treat the observed work and progress as the evidence, rather than promising a fixed lag or throughput for every database.
4. Follow activity, then verify the data.
Start capture with the plan and review its live status, checkpoints, and failures. Decide explicitly whether source deletes should propagate. A stream that is active is doing work; a separate comparison answers whether the source and target agree within the selected scope.
Use recurring comparisons to catch differences that deserve investigation. If you find drift, review the affected rows and the proposed repair before applying changes. Stop and investigate source or mapping problems that would cause the same drift to return.
5. Plan for a laptop’s lifecycle.
The Mac engine runs while the machine is awake and the operator is logged in. Start-at-login operation and schedule catch-up help the workflow recover after return; they do not mean the app processes data while logged out or asleep.
CDC and schedules require a paid Mac license. The 14-day trial covers manual snapshots, comparisons, and reconciliation with two connections and one plan. For a server-based operating model, review Cupcake-DRCP for Enterprise.
