Cupcake DRCP

Database Replication Control Plane

One self-hosted console for MySQL, MariaDB & Percona replication.

Cupcake DRCP turns the whole replication path into one operator-facing surface: versioned ETL Plans, one-shot Snapshots, binlog + PK-sweep CDC engines, live Run monitoring, point-in-time Compare for drift detection, dry-run Reconcile for safe repair, and Scheduled auto-apply that runs while the team sleeps.

View the Story Explore Capabilities
PlanVersioned ETL with column-level mapping
RunSnapshots, CDC, and live job monitoring
ReconcileDrift detection with dry-run repair

Adaptive Deployment Patterns

Run Cupcake where the replication path needs control.

Cupcake DRCP can sit close to the source, close to the recovery target, or in a central operations hub. The control plane stays consistent while the footprint adapts to network boundaries, customer security rules, and recovery architecture.

Pattern 01

Source-side control

Place the worker near production MySQL, MariaDB, or Percona when source access is tightly controlled and outbound movement is preferred.

Pattern 02

Target-side recovery

Put Cupcake next to the DR or migration target so recovery teams can validate lag, compare data, and execute repair from the destination environment.

Pattern 03

Operations hub

Use one Cupcake hub to coordinate multiple projects, recurring compare schedules, CDC stream monitoring, and recovery evidence across environments.

Pipeline Visualization

See the whole MySQL-compatible path before anyone calls cutover.

MySQL-compatible sources, mapping policy, snapshot, CDC catch-up, compare, repair, and a target that can be trusted.

DRCP / project: storefront-recovery / live MySQL + MariaDB + Percona
Cupcake DRCP data movement pipeline A source database flows through Cupcake mapping, snapshot, CDC, comparison, repair, and target validation. SOURCE CUPCAKE DRCP TARGET MySQL primary binlog enabled MariaDB source schema discovered Percona Server MySQL compatible Plan tables + columns Snapshot DDL + bulk load Cupcake DRCP CDC Stream binlog or PK sweep Compare + Reconcile drift + dry-run repair MySQL target ready to promote MariaDB DR validated copy Percona replica ready standby

The Pain

Database movement is usually scattered across scripts, terminals, and hope.

Leadership wants confidence.

Show the state of every migration, mirror, comparison, and recovery action from one page.

Operators need control.

Turn repeatable workflows into managed jobs with clear policies, checkpoints, and status.

Auditors need evidence.

Keep comparison results, repair actions, schedule history, and operational decisions traceable.

The Story

From first MySQL connection to a scheduled, audited replication loop.

  1. 01

    Connect

    Save MySQL, MariaDB, and Percona endpoints once. Encrypted at rest, validated on save, reused by every job kind.

  2. 02

    Plan

    Pair source and target tables, line up columns, set type casts, write modes, and conflict handling. One versioned Plan drives every downstream job.

  3. 03

    Snapshot

    Run a one-shot DDL + bulk-row copy to seed the target. The destructive step is gated behind a typed safety phrase.

  4. 04

    Stream

    Turn on CDC. Pick binlog statement replay for near-real-time lag, or row-window PK sweep for sources without binlog. Watch live in Runs with 3-second refresh.

  5. 05

    Compare

    Point-in-time verification between source and target. Counts the rows that disagree by primary key and stores a copy-able receipt for every run.

  6. 06

    Reconcile

    Close drift with a dry-run preview, typed confirmation, and full audit trail. Schedule the loop so the next morning's standup is a glance, not a question.

Live Run Monitor

Click a Run and drop into a 3-second refresh of the live MySQL job.

The Runs page is the cross-kind ledger for every job the project has fired — CDC streams, snapshots, repair jobs. Click any row and the live detail view opens with rows replicated, throughput, cycle number, last heartbeat, the exact binlog source position, cumulative inserts/updates/deletes, per-table activity, a tailable INFO/WARN/ERROR event log, and Pause/Stop one click from where the operator was already looking.

Cupcakeops-warehouse
CDC · ANALYTICS Prod → Dev
analytics_prod → analytics_dev RUNNING
de850a

CDC

ROWS REPLICATED
6,390,437
THROUGHPUT
1.3K rows/s

last poll: +160,544 applied · 4-cycle avg

CYCLE #
232
LAST ACTIVITY
7s ago
Processing audit_logs · phase upsert 64,500 scanned · 64,500 applied (this window)
7s ago

Engine

ENGINE TYPE

binlog

SOURCE POSITION

binlog:mysql-bin.000051:306339862;cdc:1781883162

ROWS SCANNED (LATEST CYCLE)

160,544

STATUS

streaming

INSERTS / UPDATES / DELETES (CUMULATIVE)

+465·~6,389,972·-57

Per-table activity

No per-table breakdown reported by the worker yet. Cumulative totals above reflect activity across all replicated tables.

↓ inserts↑ updates"rows replicated" and "inserts/updates/deletes" are cumulative since stream started · throughput is averaged over the recent 4 cycles · "last poll" shows only the most recent cycle

· LIVE TAIL
7s agocdc_heartbe…CDC table apply heartbeataudit_logs▸ payload
17s agocdc_heartbe…CDC table apply heartbeataudit_logs▸ payload
28s agocdc_heartbe…CDC table apply heartbeataudit_logs▸ payload
38s agocdc_heartbe…CDC table apply heartbeataudit_logs▸ payload
48s agocdc_table_s…CDC table cycle startedaudit_logs▸ payload
LICENSEvalid WORKERhealthy JOBS3 active

Capabilities

Six built-in workflows that cover the MySQL replication lifecycle.

Versioned Plans

Pair source and target tables, line up columns, set type casts, write modes, and conflict handling. One saved Plan drives every downstream MySQL job — Snapshot, CDC, Compare, Reconcile, and Schedule all read from the same source of truth.

One-Shot Snapshots

The destructive-but-honest baseline. Cupcake drops and recreates target tables from source DDL, then bulk-copies every row. A typed safety phrase gates the drop. The result is a known-good MySQL target ready for CDC to tail.

CDC with Two Engines

Binlog statement replay for near-real-time MySQL lag, or row-window PK sweep for sources that can't expose binlog. Binlog falls back to PK sweep automatically. Tunable checkpoint policy, retention, and FK-checks-during-apply round it out.

Live Run Monitor

Every Snapshot, CDC stream, and Repair job lands in one ledger with kind, status, progress, and elapsed time. Click any row to drop into the live view — rows replicated, throughput, cycle number, source position, and a tailable event log refreshing every 3 seconds.

Point-in-Time Compare

Pick a Plan, click Run, get a drift count. Compare reads rows on both sides, matches by primary key, and stores a copy-able receipt for every run. The amber numbers in the run history are the days a plan was diverging.

Reconcile + Scheduled Auto-Apply

Close drift with a dry-run preview, typed safety phrase, and full audit trail. Schedule a nightly Compare and let it auto-apply repairs within a row-count ceiling — small drift fixes itself, large drift halts and waits for a human.

Platform Roadmap

Expanding the database horizon without diluting the control plane.

The roadmap should say the quiet part clearly: Cupcake is already strong for MySQL-compatible replication and recovery, and the next platform moves broaden database support while keeping the same workflow for mapping, CDC, compare, repair, automation, and audit evidence.

Now

MySQL, MariaDB & Percona — fully shipped

Projects, encrypted Connections, versioned Plans with column-level mapping, one-shot Snapshots, CDC with binlog and PK-sweep engines, live Runs monitor, point-in-time Compare, dry-run Reconcile, and Scheduled compares with optional auto-apply.

Soon

PostgreSQL support

PostgreSQL endpoints enter the same control plane model: connection discovery, table mapping, movement orchestration, and health visibility.

Next wave

More source and target engines

Additional database connectors will expand recovery and migration coverage while preserving Cupcake’s operator-first workflow.

Platform

Policy, alerting, and evidence

Deeper schema-change policy, alert routing, richer audit exports, recovery runbooks, and historical health reporting for compliance-ready operations.

The Close

Less war room. More control room.

Cupcake DRCP gives database, platform, and recovery teams a shared source of truth for data movement operations that are too important to manage by memory.

Faster readinessKnow what can move and what needs attention.
Lower recovery riskCompare, repair, and repeat with visibility.
Cleaner handoffsGive teams a workflow they can inspect together.

FAQs

Common questions before teams try Cupcake.

Which databases are supported today?

MySQL, MariaDB, and Percona Server are all first-class. The same Plans, Snapshots, CDC, Compare, and Reconcile workflows run unchanged across the three because Cupcake uses engine-aware drivers and schema introspection.

What's the difference between Compare and Reconcile?

Compare detects drift — it counts the rows that disagree between source and target by primary key and stores a receipt for every run. Reconcile closes that drift by applying the deltas to the target. Reconcile defaults to dry-run mode and requires a typed safety phrase before any real write.

Which CDC engines does Cupcake support?

Two: binlog statement replay for near-real-time lag (requires ROW-format binlog and a replication-grade source user), or row-window PK sweep for sources without binlog. If binlog is picked and the source can't deliver, the worker falls back to PK sweep automatically so the stream doesn't stall.

Can the work be scheduled and auto-applied?

Yes. The Schedule page automates Compare hourly, daily, weekly, or monthly and can optionally auto-apply drift repairs within a Max planned rows ceiling. Small drift gets fixed quietly; crossing the ceiling halts the run and waits for a human. Every run lands in the audit trail.

Is this only for migrations?

No. Cupcake supports ongoing replication monitoring, CDC, periodic drift verification, scheduled compare/reconcile automation, one-shot snapshots, and recovery evidence — alongside one-off migration cutovers.

What is coming next?

PostgreSQL endpoints are next on the roadmap, followed by more source and target engines plus deeper platform features (alerting, schema-change policy, richer audit exports, recovery runbooks).

Contact

Talk through your replication or recovery path.

Bring the source, target, timing pressure, and the workflows you need to prove. Cupcake can be positioned around a migration, recovery drill, CDC monitoring rollout, or repeatable compare and repair process.

Contact Cupcake