BeziSync

Operate

The pipeline page opens on Overview: a flow strip (source → connector → destination) with the log kept on the source for this pipeline (for MongoDB, how far back the shared oplog reaches), the connector's state, lag, throughput, Debezium version and runtime, and what is written at the destination; then a full-width throughput and latency chart (the latest values, or the values at the point you hover, and the peak over the range), counters since the connector started, and source protection in the source's own terms beside the deployed transforms and end-to-end delivery:

  • Source protection — PostgreSQL: the replication slot, its WAL status and the room left before max_slot_wal_keep_size invalidates it ("No cap" when that is -1); MySQL: the binlog file the pipeline reads and whether the next purge would remove it; MongoDB: the oplog window and how full the oplog is; SQL Server: how long CDC keeps changes (the cleanup job's retention), whether the pipeline's position is still inside that window, and the transaction log's fill; Oracle: how far back the archived logs reach; CockroachDB: the tables' GC TTL; Spanner: the change stream's retention — each against how far the stored position is behind, with a bar of the window used; Vitess: Unknown (binlog retention is not visible through VTGate). For PostgreSQL and MySQL a bar shows the log kept for this pipeline against the pipeline's source retained limit policy (10 GB by default). Anything the probe could not measure says Unknown or Not measured yet, never fine.
  • Transforms — what consumers receive (the row after the change or the full envelope, how deletes arrive, the extra fields with their names, value formats and custom message keys), then the steps that change events on the way (filters, renames, added fields, …). Side by side, the card is as tall as the cards beside it and scrolls when the steps need more room.

The other tabs are Tables & schema, Events (read back from the destination, masked), Logs, Snapshots (re-copy rows and the stored position) and History (versions, the generated configuration, Export YAML, Promote, Save as template, and the activity). The header's one primary button follows the state (Continue setup, Review and deploy, Resume, Restart); Operate, Change and More actions hold the rest.

  • Pause / Resume / Restart (Operate) — pausing keeps the source retaining changes; watch source protection.
  • Change — edit one part (tables, destination, transforms, settings); it becomes one new version (every save while you edit updates that version, until it is deployed or sent for approval) and Review shows the diff and what deploying will do (added tables are back-filled with an incremental snapshot; some changes restart the connector).
  • Rollback — deploy any earlier version from History; the confirmation lists the restart, the changes and whether approval is needed.
  • Snapshots — re-copy selected tables without stopping streaming (sources that can't, Vitess and Spanner, say so instead): search and page through the captured tables, see their rows and size and a rough duration; large copies (over 10 tables or 5 million rows) warn and ask to confirm. With a maintenance window (e.g. 22:00-06:00 UTC, set on the review step), backfills and re-syncs wait for it to spare the source; "Run now" overrides it. The first copy on deploy is not delayed.
  • Delivery canary (opt-in on the review step) — every few minutes BeziSync writes a tiny row to bezisync.canary_<id> on the source and looks for it at the destination, showing "verified N minutes ago, X s end to end" and firing "Delivery not verified" when a canary does not arrive in time (BEZISYNC_CANARY_INTERVAL_SECONDS, BEZISYNC_CANARY_TIMEOUT_SECONDS). Needs a PostgreSQL, MySQL, Oracle (BZ_CANARY_<id> in the connector user's schema) or CockroachDB source and a destination BeziSync can read back (every one but HTTP and SQS); it adds one small canary topic, stream or table named like the others.
  • Schema — BeziSync compares the columns of captured tables every few minutes (BEZISYNC_SCHEMA_CHECK_SECONDS) and lists each change. Dropped columns, type changes and missing tables are breaking and fire the "Breaking schema change" alert until someone marks them reviewed; added columns and nullability changes are compatible. (MongoDB has no fixed schema.)
  • Stored position (Snapshots tab) — see the exact position; reset it (re-snapshot or skip to now) while paused, with typed confirmation.
  • Alerts — rules (down, lagging, source at risk, offset regression, breaking schema change, delivery not verified…) notify Slack, webhooks, PagerDuty, email and the in-app inbox. Each person chooses which events reach their inbox (account menu → Notification settings).
  • Find anything — press ⌘K / Ctrl+K to jump to a pipeline, connection, page or setting.
  • Delete (More actions) — removes the connector and everything created on the source (slot, publication, BeziSync tables, offsets) with a per-item report. Keeping the destination topics or streams is the default; deleting them is an explicit choice.

Edit this page on GitHub