What I ran into
I was reviewing a replication environment where the source database had experienced an unplanned outage mid-replication.
The first instinct - from everyone involved - was panic.
Was data lost? Did the replication request die? Would it need to be restarted manually? Would a full re-sync be required?
The short answer turned out to be: none of the above.
What actually happened
When the source database went offline, CDC did not simply stop and wait for someone to intervene.
It tried to reconnect.
By default, Connect CDC has a built-in retry mechanism. It will attempt to re-establish the connection up to 3 times, with a 1-minute interval between each attempt. If the database comes back online within that window, the Kernel performs an auto error-recovery - on Windows, the omnilistener service restarts and looks for the activekernel and activerequest files to resume the ongoing replication automatically.
And while all of this was happening?
No data was lost. All pending changes simply waited in the queue. Nothing moved to the target until the connection was restored - and then replication picked up right where it left off.
The part that surprised me
The retry limit is hard-coded at 3 attempts and is not configurable.
That detail matters. If the source database takes longer than 3 minutes to recover, CDC exhausts its retries and stops attempting to reconnect automatically. At that point, depending on the nature of the error, manual intervention may be required.
It is also worth knowing that the retry mechanism applies specifically to connection errors. For other types of errors - particularly fatal ones - auto-recovery may not trigger, and a manual restart may be needed regardless.
Why this changes how I think about source outages
Before understanding this behavior, my assumption was that any source database outage during active replication would require a full manual recovery - restarting requests, validating queues, potentially re-syncing.
The reality is more nuanced.
For short, transient outages, CDC is designed to handle the interruption on its own. For longer outages or non-connection errors, manual steps are still needed - but even then, the queue holds the pending changes safely, which means the data is not lost, just delayed.
The distinction between "CDC will self-recover" and "manual intervention is needed" comes down to how long the outage lasts and what type of error occurs.
Where to get the full technical detail
For the complete breakdown of how Connect CDC handles source database unavailability - including the retry behavior, queue behavior during outage, and recovery steps - the KB article covers it in full:
Takeaway
A source database going offline does not automatically mean data is lost or replication needs to be rebuilt. Connect CDC has a built-in retry and recovery mechanism - but it has limits. Knowing those limits helps you respond faster and with more confidence when an outage occurs.
Have you ever dealt with a source database outage mid-replication? Did CDC recover on its own, or did you need to intervene - and what made the difference?
*Precisely Software Inc.