Debezium Support

Debezium CDC Support and Implementation, 24/7

Debezium is the open-source change data capture (CDC) platform that streams every insert, update and delete from your databases into Kafka or another message broker. AceMQ designs, implements and supports Debezium CDC pipelines in production: Oracle, SQL Server, PostgreSQL, MySQL, Db2 and MongoDB sources, Kafka Connect or Debezium Server, with a 15-minute emergency response when change events stop flowing.

Senior Debezium engineers on call right now — 24/7/365
15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Trusted for Mission-Critical Debezium by Teams in Finance, Healthcare, Defense, Telecom, and More

Incident Triage

Debezium problems we fix every week

These are real symptoms from real Debezium production environments — and the first thing our engineers check when one comes in.

PostgreSQL disk filling up while the Debezium connector is stopped or lagging
What we check firstThe replication slot. A logical replication slot keeps every WAL segment the connector has not confirmed, so a stopped connector, an idle table filter or a slow consumer makes WAL grow until the disk is full. Check pg_replication_slots for the retained size, then fix the connector or heartbeat configuration before dropping anything.
Typical resolutionUnder 1 hour
MySQL connector fails on restart because the binlog position no longer exists
What we check firstBinlog retention against connector downtime. If the server purged the binlog files the connector last read, it cannot resume and needs a new snapshot. Confirm binlog_format is ROW and binlog_row_image is FULL, then set retention longer than the longest outage you plan to survive.
Typical resolution1 to 3 hours
SQL Server changes stop appearing after a weekend or a maintenance window
What we check firstThe SQL Server CDC capture and cleanup jobs. CDC has to be enabled per table, the capture job has to be running under SQL Server Agent, and the cleanup job deletes change data after its retention period, three days by default. A connector that was down longer than that has lost changes and needs a snapshot.
Typical resolution1 to 2 hours
Oracle connector lagging hours behind with LogMiner sessions running constantly
What we check firstSupplemental logging, archive log availability and the LogMiner mining window. The database must be in ARCHIVELOG mode with supplemental logging on the captured tables. Long-running transactions and large batch jobs inflate the mining window, and newer Debezium releases add an unbuffered LogMiner adapter that changes the tuning.
Typical resolution2 to 4 hours
Connector will not start after a restart, reporting a missing or corrupt schema history
What we check firstThe schema history topic. Connectors for MySQL, SQL Server, Oracle and Db2 keep table definitions in a Kafka topic that must have one partition and unlimited retention. If retention deleted part of it, or someone recreated it, the connector cannot rebuild the schema and needs a recovery snapshot.
Typical resolution2 to 4 hours
Downstream consumers see duplicate change events after a failure
What we check firstDelivery semantics. Debezium delivers at least once, so a connector restart replays events from the last committed offset. Consumers and sink connectors need idempotent writes keyed on the primary key, and that is cheaper to design in than to retrofit.
Typical resolutionUnder 2 hours

Resolution times reflect typical Debezium engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

What's Included

Everything in your Debezium support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency CDC Incident Response

Change events stopped, a connector stuck in a failed state, or database disk filling from retained logs. A senior engineer joins a live bridge within 15 minutes, 24/7, and works the database side and the Kafka side together.

CDC Pipeline Design and Implementation

Source database preparation, connector configuration, initial and incremental snapshots, topic and key design, schema registry and serialisation, and sink connectors into warehouses, search and microservices.

Oracle, SQL Server, Db2 and Core Systems

CDC from the systems of record that banks, insurers and manufacturers actually run: Oracle LogMiner, SQL Server CDC, Db2 and Db2 for IBM i, alongside PostgreSQL, MySQL, MariaDB and MongoDB.

Kafka Connect and Kafka Operations

The Kafka Connect cluster Debezium runs on: worker sizing, task rebalancing, offset and config topics, message size limits, and the Kafka cluster underneath, covered by the same team.

Debezium Server Without Kafka

Where Kafka is more than the use case needs, Debezium Server streams changes straight to RabbitMQ, Amazon Kinesis, Google Cloud Pub/Sub, Azure Event Hubs, Apache Pulsar or Redis streams.

Upgrades and Root Cause Analysis

Planned upgrades across Debezium release series with offsets and schema history preserved, and a written RCA for every P1 covering what failed and the configuration that stops it recurring.

Escalation Path

Your first hour of a Debezium outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior Debezium engineer. There is no tier-1 triage layer to get through.

P1 — Emergency
15 min

Production down: change events stopped, a connector failed and will not restart, database disk filling from retained logs, or downstream systems receiving corrupt or missing changes

P2 — Critical
1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High
4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard
Next day

Questions, guidance, best practices, non-urgent improvements

49+ Platforms Supported

We Support Your Entire Tech Stack

Debezium rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.

Anywhere You Run It

We support Debezium wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

Kafka Connect, self-managedDebezium ServerKubernetes (Strimzi, OpenShift)Amazon MSK and MSK ConnectConfluent PlatformOracle 19c, 21c, 23ai and 26aiSQL Server 2017, 2019 and 2022PostgreSQL 14 to 18MySQL 8.0, 8.4 and 9.x, MariaDBDb2 11.5 and Db2 for IBM iMongoDB 6.0, 7.0 and 8.0On-premises and air-gapped
Why AceMQ

What you get that you don't get elsewhere

Database and Kafka in One Team

Most CDC incidents sit between the two: a replication slot, a purged binlog, a capture job, an offset topic. Our engineers work both sides, so nobody hands the incident back and forth between a DBA and a Kafka team.

Named Senior Engineers

The same engineers stay on your account and know your connectors, table filters and snapshot history. A P1 starts with diagnosis, not with explaining the pipeline.

The Right Transport, Not Just Kafka

We have replaced Kafka-based CDC with Debezium and RabbitMQ where Kafka was more than the workload needed, and built Kafka CDC where it was the right fit. You get the architecture that suits the volume.

Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone, so a capture job that stops at 3am reaches someone already at work.

FAQ

Debezium support questions

Keep Every Change Flowing

Whether a connector stopped tonight, a CDC pipeline needs to be built from Oracle or SQL Server, or you want to know if Kafka is the right transport at all, AceMQ staffs it with a named senior engineer. Quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607
info@acemq.com
66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.

We respond within 1 business day.

Pick a time that works — no pressure, no pitch. Just 30 minutes with an expert.

We respond within 1 business day.