Connect CDC

What caught me off guard during an incident

I was investigating an environment after a restart event when I noticed something that made me pause.

The replication request had been active before the interruption. Nobody manually started it after recovery. Yet there it was, running again as if nothing had happened.

My first assumption was that someone must have restarted it manually. The logs and configuration eventually told a different story.

It was not a mystery. It was by design.

Connect CDC maintains information about active kernels and requests. When the Listener comes back online, it can restart kernels that were active before the interruption. Those kernels can then restart their previously active requests without manual intervention.

What initially looked like an unexpected startup turned out to be a normal recovery sequence.

Why this matters during incident investigations

The real cost of not knowing this behavior is time.

Before understanding the recovery mechanism, my instinct was to look for a manual action that explained the running request. That investigation would go nowhere if there were no manual action to find.

Once I understood that CDC could restore its previous active state, my first question changed. Instead of asking, "Who started this?", I now ask, "Was CDC recovering a request that was active before the interruption?"

That small shift can make an incident investigation much more focused.

Where to get the full technical detail

The following article explains how the activekernels and activerequests files support this recovery behaviour:

How does replication stop and restart automatically when the listener/kernel process is started in Connect CDC - Article 000037302

Takeaway

Not every startup after a recovery event was initiated manually. If a request was active before the interruption and returns afterward, Connect CDC's recovery behavior is worth checking before looking for another explanation.

Have you ever spent time looking for who restarted a request, only to find that CDC was restoring its previous active state?

Yes, I've seen this happen during investigations. Initially it looked like someone had manually restarted the request, but the root cause was simply CDC's automatic recovery mechanism restoring previously active kernels and requests after the Listener restart. Understanding this behaviour can save a lot of troubleshooting time. Great reminder to check recovery activity first before assuming manual intervention.