https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> I upgraded to Air byte 2.0.1. I set...
# replication-ask-ai
n
@kapa.ai I upgraded to Air byte 2.0.1. I set up a new MSSQL source, snowflake destination and a new CDC connection between the two. When I run the newly set up job for the first time, I get an error "io.debezium.DebeziumException: Could not find existing redo log information while attempting schema only recovery snapshot". Why
k
The knowledge sources you provided don’t contain this specific Debezium error message for MSSQL (“Could not find existing redo log information while attempting schema only recovery snapshot”), so I can’t give a precise root cause from them. What they do confirm: - MSSQL CDC in Airbyte relies on Debezium and has a number of database‑side prerequisites (CDC enabled on the DB and tables, supported SQL Server version, etc.). [[MSSQL CDC limits](https://discuss.airbyte.io/t/453); [CDC limits](https://docs.airbyte.com/platform/2.0/understanding-airbyte/cdc#limitations)] - Snapshot isolation must be enabled for the database(s) you sync; this is required by Airbyte’s MSSQL CDC implementation to take the initial snapshot without locking tables. [[MSSQL CDC forum](https://discuss.airbyte.io/t/453)] - CDC only tracks changes for tables/schemas where CDC is correctly enabled and that are included in the sync. [[CDC limits](https://docs.airbyte.com/platform/2.0/understanding-airbyte/cdc#limitations)] Given that: 1. The error is coming from Debezium during a “schema only recovery snapshot”. 2. The docs/issues you shared don’t mention this exact error or a known bug in 2.0.1 for MSSQL. 3. The MSSQL troubleshooting page only covers a different CDC limitation (new columns not being captured) and not this startup failure. [[MSSQL troubleshooting](https://docs.airbyte.com/integrations/sources/mssql/mssql-troubleshooting)] I can only say with confidence, based on the docs, that you should double‑check: - Snapshot isolation is enabled on the source database(s) you’re syncing (both 
ALLOW_SNAPSHOT_ISOLATION
and, if required, 
READ_COMMITTED_SNAPSHOT
). [[MSSQL CDC forum](https://discuss.airbyte.io/t/453)] - CDC is enabled at the database level and on each table you selected for CDC. - You’re on a supported SQL Server version for CDC (SQL Server 2016 SP1+; specific Linux version constraints also apply). [[MSSQL CDC limits](https://discuss.airbyte.io/t/453)] Because the provided sources don’t document this exact Debezium “redo log information” error, I can’t definitively say why it’s happening in your setup from these materials alone. If those prerequisites are already satisfied, you’ll likely need to: - Inspect the full connector logs for more context around the Debezium exception. - Open a GitHub issue or support ticket with those logs, Airbyte version (2.0.1), MSSQL connector version, and SQL Server version, since this specific failure mode is not covered in the current docs/issues you shared.
n
@kapa.ai can you scan the knowledge sources once more to see any reference to the issue mentioned above?
k
A message from kapa.ai
Yes — the knowledge sources you provided do directly reference this exact issue and error. From the linked GitHub issue for the MSSQL source connector 4.3.2 / 4.3.3, the error: > 
io.debezium.DebeziumException: Could not find existing redo log information while attempting schema only recovery snapshot
is seen on first run / cold start when Debezium starts with: - 
No previous offsets found
- 
snapshot.mode = recovery
The initial analysis in that issue explains: - On a fresh or reset connection, there is no existing offset or schema history. - The connector’s cold-start path in 4.3.x generates a synthetic offset and uses 
snapshot.mode=recovery
. - When Debezium tries to do a schema-only recovery snapshot but cannot find redo log (transaction log) information or schema history to recover from, it throws this exact exception. [[MSSQL issue 73326](https://github.com/airbytehq/airbyte/issues/73326)] This is identified as a bug in the cold start path of the MSSQL source connector in 4.3.x. A workaround noted in the issue is: - Run an initial full load using MSSQL source connector 4.2.6. - Then upgrade to 4.3.x and switch to incremental/CDC; this works because the initial run has already created the state and schema history, so the problematic cold-start path is bypassed. [[MSSQL issue 73326](https://github.com/airbytehq/airbyte/issues/73326)] The issue is escalated internally and still open; there is no documented permanent fix yet in the provided sources. [[MSSQL issue 73326](https://github.com/airbytehq/airbyte/issues/73326)] So, based on these sources: - Your first-run failure with that Debezium error on a new MSSQL CDC connection is consistent with this known bug in the MSSQL source connector’s cold-start behavior. - The only documented workaround in the knowledge you shared is the “initial full load on 4.2.6, then upgrade” approach, with the caveat that it may risk data gaps and is “not ideal.” [[MSSQL issue 73326](https://github.com/airbytehq/airbyte/issues/73326)] If you need next steps, they would be to either apply that workaround or track the upstream issue for a fix, but the knowledge sources don’t yet describe a released connector version where this is resolved.
Open in Slack
PreviousNext
Powered by