BinlogServer centralizes MySQL binlog backup behind one service. Run local-first durable capture, inspect state through API and embedded UI, scale into cluster roles, export metrics, and archive sealed files with optional S3-compatible upload.
Control plane Create → Start → Observe → Retry upload
Data path Pull binlog → Write local files → Seal → Archive
Deployment Standalone / Control-plane / Worker / All-in-one
Signals Checkpoint / Lag / Events / Workers / Metrics
One product, four surfaces
BinlogServer exposes one operator model across API, embedded UI, cluster deployment, and observability. You are not stitching backup state together from unrelated tools.
Task lifecycle, checkpoint, replication status, files, dashboard data, cluster overview, and events.
A built-in operator console for daily backup management instead of a separate frontend deployment burden.
Control-plane, worker, and all-in-one roles support HA-friendly coordination and execution separation.
Prometheus metrics, worker heartbeats, health checks, and task events make backup state continuously visible.
Capabilities
The point is not merely pulling binlog. The point is making backup durable, inspectable, restartable, and operable by a team.
Checkpoint advances only after local `fsync` succeeds, so progress reflects durable state instead of optimistic buffering.
S3-compatible upload is optional and best-effort. Archive failure does not stop replication, and retry stays operator-controlled.
Inspect lag, files, checkpoints, worker ownership, heartbeats, and event history through stable interfaces.
Create, start, stop, inspect, and recover multiple backup tasks through one service instead of per-host ad hoc flows.
Support `LATEST`, `FILE_POS`, and `GTID` while preserving a single operator mental model for backup runs.
Lease-backed ownership and worker heartbeat semantics support failover and cleaner role separation in production.
Under the hood
From operator intent to archive retry, the execution path is deterministic and easy to explain.
API validates task input, stores task metadata, and turns backup intent into a schedulable object.
Runner pulls binlog events, writes local files, rotates sealed segments, and updates checkpoint only after durable persistence.
Operators inspect file state, lag, retries, cluster health, and progress through metrics and APIs instead of shell output.
Positioning
This page should make one thing unmistakable: BinlogServer is a centralized MySQL binlog backup control plane. It is not a generic CDC platform or a broad event streaming layer.
| Claim | What supports it | How to say it |
|---|---|---|
| Durable progress | Checkpoint only moves after local durability is confirmed. | Checkpoint advances only after local fsync succeeds. |
| Archive support | Uploader is optional, best-effort, and retryable without stopping capture. | Optional S3-compatible upload. |
| Product category | Capabilities and docs center on backup operations, not general CDC downstream fan-out. | Centralized MySQL binlog backup control plane. |
Good fit / Not fit
Sharp products are easier to trust when they draw boundaries. BinlogServer fits backup operations that need reliability and visibility, not every database workflow under the sun.
If you need safer, more visible, centrally operated MySQL binlog backup, BinlogServer is the right story. If you need full CDC plumbing for downstream systems, it is the wrong headline.
Trust signals
BinlogServer already has the right shape for a believable infrastructure product: API endpoints, UI iteration, E2E coverage, security policy, changelog cadence, and scenario-driven reliability work.
Deployment modes, observability, and architecture docs make the operator story explicit.
Quick and full E2E flows cover retry upload, cluster behavior, observability, and worker failure recovery.
Public security policy and hardening work signal that this is being shaped toward production use.
Recent releases show continued investment in operator console quality, auth guidance, and runtime reliability.
Releases
The recent story is not random feature sprawl. It is clearer operator workflows, stronger frontend validation, and more production-minded behavior.
Workspace-oriented ops console updates and deeper task navigation improved the operator experience.
Frontend E2E acceptance coverage, auth guidance, and retry-upload affordances strengthened real operating paths.
The first public release landed with security policy, hardening, metrics, validation, and tracing work.
Stress centralized operations, not “yet another script that happens to pull binlog.”
UI + reliability + opsCheckpoint semantics and explicit retry-upload flows are better proof than vague infra slogans.
fsync-backed checkpointKeep the story grounded in backup operations, cluster execution, observability, and optional S3-compatible archive.
backup control planeReview the deployment guide, inspect the release line, and evaluate BinlogServer as what it already is: a centralized MySQL binlog backup control plane.