mysql connector sync job pullig 0 rows, I cannot open the logs

MySQL Connector Syncing 0 Rows There are several known causes for a MySQL sync pulling 0 records. Here are the most common ones to investigate: 1. Insufficient Permissions Ensure the Airbyte MySQL user has the required grants, especially for CDC:

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'airbyte'@'%';

[MySQL permissions fix] 2. CDC Binlogs Expired Under CDC incremental mode, if binlogs have been purged, Airbyte will trigger a full refresh from scratch. You'll see this log message: >

Saved offset no longer present on the server, Airbyte is going to trigger a sync from scratch

To fix this, increase binlog retention: • Standard MySQL: Set a higher

binlog_expire_logs_seconds

(recommended: 7 days) • Amazon RDS: Run

call mysql.rds_set_configuration('binlog retention hours', 24);

[CDC binlog troubleshooting] 3. Query Timeout If you see

MySQL Query Timeout: The sync was aborted because the query took too long

, set MySQL's

max_execution_time

higher than the

Checkpoint Target Time Interval

(default 300,000ms). [Query timeout fix] 4. Zero Date Values Causing OOM Tables with many

0000-00-00

date values can cause the sync to hang and eventually run out of memory, resulting in 0 records synced. As a workaround, add

zerodatetimebehavior=Converttonull

to the JDBC parameters in the source configuration. [Zero date OOM issue] 5. View Tables (not regular tables) If you're syncing a MySQL view (TABLE_TYPE = VIEW), there is a known bug in some connector versions where views sync 0 records. [View sync bug] Accessing Logs Since you mentioned you cannot open the logs, here are your options: • In the Airbyte UI, go to the connection's Job History tab → click the three grey dots next to a sync → select View logs or Download logs. • Search for

Error

,

Exception

, or

Fail

within the log viewer to find the root cause. • If using Airbyte OSS with

abctl

, you can access logs directly via:kubectl logs -n airbyte-abctl replication-job-id-attempt-n -f [Browsing logs] Could you share any error messages or context about your setup (CDC vs. Full Refresh, MySQL version, deployment type)? That would help narrow down the root cause further. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai no error is says success at the end of the job

This is a known issue where the MySQL sync reports success but syncs 0 records without triggering any error or failure notification. [MySQL 0 records bug] Based on community reports, the most common hidden root causes are: 1. Out of Memory (OOM) The replication pod runs out of memory and silently fails. Check the replication pod logs directly — the error won't surface in the Airbyte UI. [OOM issue] 2. Insufficient CPU Resources The replication pod gets stuck in

Pending

state due to

Insufficient cpu

. Increasing available vCPUs resolved this for some users. [CPU resource issue] 3. Hidden Errors Not Surfaced in UI Errors are not always reported correctly, causing the sync to show as successful when it has actually failed. One user found this hidden error in their logs: >

Failed to obtain or add access token

[Hidden errors] 4. Temporal Infrastructure Stress If you're on self-hosted Airbyte, Temporal database persistence issues can cause syncs to complete with 0 records while still reporting success. Check your Temporal database for high CPU, memory, or slow queries. [Temporal issues] What to Do Since the UI logs aren't accessible, try to get the raw replication pod logs directly:

kubectl logs -n <your-namespace> replication-job-<job-id>-attempt-0 -c source

Search for

error

,

OOM

,

Insufficient

, or

Exception

— the real cause is likely hidden there. This appears to be an open bug in Airbyte where errors in the replication pod are not correctly propagated to the UI, causing false success statuses. [Open bug] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai those are my pods:

airbyte-abctl-bootloader                             0/1     Completed   0             17d
airbyte-abctl-cron-6b7dbb458c-6qjss                  1/1     Running     0             21d
airbyte-abctl-manifest-server-5cb4db548b-phzkm       1/1     Running     0             21d
airbyte-abctl-server-6cc5ddd94d-lllpn                1/1     Running     1 (15d ago)   21d
airbyte-abctl-temporal-57867b8b87-t2w6x              1/1     Running     1 (25d ago)   111d
airbyte-abctl-worker-d7867ff7-kkdh7                  1/1     Running     0             21d
airbyte-abctl-workload-api-server-68b464c559-c9b59   1/1     Running     0             21d
airbyte-abctl-workload-launcher-66fb578f46-f2j4c     1/1     Running     0             17d
airbyte-db-0                                         1/1     Running     1 (25d ago)   111d

I notice there are no replication pods running in your pod list. This is actually a key clue. What This Means The replication job pod (e.g.,

replication-job-<id>-attempt-0

) is created temporarily during a sync and then removed. Since it's gone, you need to check the workload launcher logs to see what happened during the sync. Steps to Investigate 1. Check workload launcher logs:

kubectl logs -n airbyte-abctl airbyte-abctl-workload-launcher-66fb578f46-f2j4c --tail=200

2. Check the worker logs:

kubectl logs -n airbyte-abctl airbyte-abctl-worker-d7867ff7-kkdh7 --tail=200

3. Check Kubernetes events for resource issues:

kubectl get events -n airbyte-abctl --sort-by='.lastTimestamp' | tail -50

Look for messages like: •

Insufficient cpu

•

Insufficient memory

•

OOMKilled

•

ResourceConstraintException

Things to Note From Your Pod List • Your

airbyte-abctl-temporal

pod has restarted once (25d ago) — worth checking if Temporal is healthy • Your

airbyte-abctl-server

pod has also restarted once (15d ago) These restarts could be related to the silent failure issue reported by other users. [Temporal issues] [Resource constraint bug] Can you share the output of the workload launcher logs? That will most likely reveal the hidden error. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai

2026-06-12 18:01:07,099 [Workflow Executor taskQueue="CONNECTION_UPDATER", namespace="default": 12253]  WARN    i.t.i.w.WorkflowWorker$TaskHandlerImpl(logExceptionDuringResultReporting):676 - Failure while reporting workflow progress to the server. If seen continuously the workflow might be stuck. WorkflowId=connection_manager_c79ef843-9d8f-4332-9465-1f141d7f4d82, RunId=e21c5fff-2855-4aa4-bdfb-6a402de629fd, startedEventId=138
io.temporal.internal.retryer.GrpcMessageTooLargeException: RESOURCE_EXHAUSTED: grpc: received message larger than max (5176868 vs. 4194304)
        at io.temporal.internal.retryer.GrpcMessageTooLargeException.tryWrap(GrpcMessageTooLargeException.java:29)
        at io.temporal.internal.retryer.GrpcRetryerUtils.createFinalExceptionIfNotRetryable(GrpcRetryerUtils.java:61)
        at io.temporal.internal.retryer.GrpcSyncRetryer.retry(GrpcSyncRetryer.java:57)
        at io.temporal.internal.retryer.GrpcRetryer.retryWithResult(GrpcRetryer.java:40)
        at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.sendTaskCompleted(WorkflowWorker.java:616)
        at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:444)
        at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.handle(WorkflowWorker.java:343)
        at io.temporal.internal.worker.PollTaskExecutor.lambda$process$1(PollTaskExecutor.java:76)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: grpc: received message larger than max (5176868 vs. 4194304)
        at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:368)
        at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:349)
        at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:174)
        at io.temporal.api.workflowservice.v1.WorkflowServiceGrpc$WorkflowServiceBlockingStub.respondWorkflowTaskCompleted(WorkflowServiceGrpc.java:6386)
        at io.temporal.internal.worker.WorkflowWorker$TaskHandlerImpl.lambda$sendTaskCompleted$0(WorkflowWorker.java:621)
        at io.temporal.internal.retryer.GrpcSyncRetryer.retry(GrpcSyncRetryer.java:49)
        ... 8 common frames omitted

Root Cause Found: Temporal gRPC Message Too Large The error is clear:

GrpcMessageTooLargeException: RESOURCE_EXHAUSTED: grpc: received message larger than max (5176868 vs. 4194304)

Your Temporal workflow history has grown too large — 5.17 MB vs the 4 MB gRPC limit. This is why the sync silently reports success with 0 records: Temporal cannot report the workflow progress back to the server, so the workflow gets stuck or orphaned. Why This Happens This is a known issue where the

StandardSyncInput

(which contains the full catalog and state) grows too large to fit within Temporal's gRPC message size limit. It commonly happens on the second sync onwards because state is only added after the first sync, which is why your initial syncs may have worked fine. [MySQL incremental failure] Recommended Fixes 1. Split your connection into multiple smaller connections Reduce the number of streams/tables per connection so the catalog + state stays under the 4 MB limit. This is the most reliable workaround. [Split connections] 2. Reset the connection state A state reset can temporarily reduce the message size: • Go to the connection in the Airbyte UI • Click Reset to clear the saved state • Re-run the sync Note this will trigger a full refresh. 3. Increase Temporal's gRPC message size limit The knowledge sources mention tweaking Temporal's

BlobSize

configuration, but the exact configuration steps for

abctl

deployments are not detailed in the available sources, so I'd recommend reaching out to Airbyte support for guidance on this specific approach. [Temporal BlobSize] The most practical immediate fix is to split your MySQL connection into multiple connections with fewer tables each to keep the payload under the 4 MB gRPC limit. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai start with one single table, ow I can see logs:

2026-06-12 15:49:43 source INFO i.d.c.m.MySqlStreamingChangeEventSource(handleChange):791 Skipping previously processed row event: Event{header=EventHeaderV4{timestamp=1780585304000, eventType=DELETE_ROWS, serverId=42164, headerLength=19, dataLength=8178, nextPosition=79662500, flags=0}, data=DeleteRowsEventData{tableId=27, includedColumns={0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}, rows=[
    [3375073313, 12571202, [B@50740616, 0, [B@53e6e598, 2, [B@1cb414c5, 2022-03-14T16:41:23, null, [B@78dcf519, 0, 0, 288, 0.0, 0, 0, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@8e818a2, [B@6cc6e602, [B@50e8c563, 0, 0, 0],
    [3375073314, 12571202, [B@4f83865a, 0, [B@766aa00, 2, [B@5ccbba18, 2022-03-14T16:41:23, null, [B@4a1ebf3f, 0, 0, 6, 0.0, 0, 0, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@19fc4170, [B@2b78cee5, [B@2ae2aae8, 0, 0, 0],
    [3375073315, 12571202, [B@153a1fcc, 0, [B@6eb63bda, 2, [B@354cf0f, 2022-03-14T16:41:23, null, [B@3c5e9067, 0, 0, 18, 0.0, 0, 5, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@79df3c5f, [B@26e8a055, [B@3612f30, 0, 0, 0],
    [3375073316, 12571202, [B@4bf45a93, 0, [B@4bc9aa76, 2, [B@28c04152, 2022-03-14T16:41:23, null, [B@22d2e3d5, 0, 0, 30, 0.0, 0, 6, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@4b1b15de, [B@4d879cd1, [B@67e78ee2, 0, 0, 0],
    [3375073317, 12571202, [B@521e1580, 0, [B@41385ff8, 2, [B@3028221a, 2022-03-14T16:41:23, null, [B@6b632a63, 0, 0, 29, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@49f3909a, [B@4ab7d1c3, [B@3bfe127d, 0, 0, 0],
    [3375073318, 12571202, [B@493c1753, 0, [B@1c1e39ae, 2, [B@68d3da27, 2022-03-14T16:41:23, null, [B@237540ba, 0, 0, 26, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@ada5d08, [B@6764d6b4, [B@11902a9d, 0, 0, 0],
    [3375073319, 12571202, [B@18e9c885, 0, [B@4083e48d, 3, [B@1934b5f, 2022-03-15T12:45:45, null, [B@11c75d32, 0, 0, 12, 0.0, 0, 3, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@473c126f, [B@18c43189, [B@316487d, 0, 0, 0],
    [3375073320, 12571202, [B@2813abe0, 0, [B@f1b6be7, 3, [B@366a4bf4, 2022-03-15T12:45:45, null, [B@78ea8e4, 0, 0, 19, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@32774f5e, [B@66674ea4, [B@2b68c77, 0, 0, 0],
    [3375073321, 12571202, [B@700dcd4d, 0, [B@780871ad, 3, [B@24c60266, 2022-03-15T12:45:45, null, [B@12a5f7bd, 0, 0, 10, 0.0, 0, 2, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@cdc3701, [B@3762aa2e, [B@23234b96, 0, 0, 0],
    [3375073322, 12571202, [B@1e065850, 0, [B@738f10ae, 3, [B@519ef72b, 2022-03-15T12:45:45, null, [B@68587975, 0, 0, 89, 0.0, 0, 14, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@443078f6, [B@4f311abe, [B@69b09bdc, 0, 0, 0],
    [3375073323, 12571202, [B@4208c44e, 0, [B@538e331, 3, [B@421bedc2, 2022-03-15T12:45:45, null, [B@2f18e026, 0, 0, 11, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@2bb66b3f, [B@69552413, [B@743db106, 0, 0, 0],
    [3375073324, 12571202, [B@1c4c6677, 0, [B@43b0952, 3, [B@440ec07a, 2022-03-15T12:45:45, null, [B@5da2fc7c, 0, 0, 248, 0.0, 0, 37, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@22225661, [B@7e8faaee, [B@4cb0b855, 0, 0, 0],
    [3375073325, 12571202, [B@6bbeca3, 0, [B@369a234b, 3, [B@354137ac, 2022-03-15T12:45:45, null, [B@7cfa4341, 0, 0, 220, 0.0, 0, 38, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@25fd6689, [B@421a8906, [B@7e5a3abe, 0, 0, 0],
    [3375073326, 12571202, [B@50149e7f, 0, [B@1e9363da, 3, [B@8d79bb7, 2022-03-15T12:45:45, null, [B@27f7cfd9, 0, 0, 242, 0.0, 0, 39, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@53644a3e, [B@56ec7e3b, [B@62d25d72, 0, 0, 0],
    [3375073327, 12571202, [B@7bc2dff6, 0, [B@a864f0a, 3, [B@3faee5c7, 2022-03-15T12:45:45, null, [B@4f67068d, 0, 0, 153, 0.0, 0, 29, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@22b75df8, [B@1af1a8bb, [B@52b9f6ff, 0, 0, 0],
    [3375073328, 12571202, [B@259dd14b, 0, [B@3ddd009d, 3, [B@2afed3ed, 2022-03-15T12:45:45, null, [B@37edd643, 0, 0, 63, 0.0, 0, 10, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@7cb14e7c, [B@293d709f, [B@7580afee, 0, 0, 0],
    [3375073329, 12571202, [B@2c8620d3, 0, [B@5ab25991, 3, [B@18c963d0, 2022-03-15T12:45:45, null, [B@68c650f8, 0, 0, 315, 0.0, 0, 50, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@75db658b, [B@3d6dd470, [B@6e69e7ee, 0, 0, 0],
    [3375073330, 12571202, [B@34722b4b, 0, [B@1aabf773, 3, [B@49367e02, 2022-03-15T12:45:45, null, [B@68c1a65d, 0, 0, 12, 0.0, 0, 3, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@4dccf07d, [B@81986d8, [B@72a53fb7, 0, 0, 0],
    [3375073331, 12571202, [B@17339cf0, 0, [B@3d56d973, 3, [B@793da747, 2022-03-15T12:45:45, null, [B@22be6750, 0, 0, 36, 0.0, 0, 5, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@2961abeb, [B@22f772f5, [B@36e4ee73, 0, 0, 0],
    [3375073332, 12571202, [B@67b18b18, 0, [B@43ab5af6, 3, [B@5a52f8ac, 2022-03-15T12:45:45, null, [B@4bd412e3, 0, 0, 26, 0.0, 0, 5, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@2056b9ca, [B@39b32bdc, [B@74e933de, 0, 0, 0],
    [3375073333, 12571202, [B@1f4174aa, 0, [B@a4c1661, 3, [B@2a81313f, 2022-03-15T12:45:45, null, [B@17cb8072, 0, 0, 20, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@3bb4205, [B@692eb30d, [B@4a056fde, 0, 0, 0],
    [3375073334, 12571202, [B@186aefc, 0, [B@58747fa3, 3, [B@445e097b, 2022-03-15T12:45:45, null, [B@25c4e5b1, 0, 0, 6, 0.0, 0, 1, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@11814ebb, [B@6a73a24f, [B@5ed26bab, 0, 0, 0],
    [3375073335, 12571202, [B@5cb9f4ad, 0, [B@47569d17, 3, [B@30c02e68, 2022-03-15T12:45:45, null, [B@7d0284e8, 0, 0, 9, 0.0, 0, 1, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@6e8d1b79, [B@1dc08d9a, [B@2cc24324, 0, 0, 0],
    [3375073336, 12571202, [B@450ea790, 0, [B@435e3a9b, 3, [B@5a6bd337, 2022-03-15T12:45:45, null, [B@648e603d, 0, 0, 31, 0.0, 0, 6, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@540c791b, [B@66b40be3, [B@62428e69, 0, 0, 0],
    [3375073337, 12571202, [B@75da9594, 0, [B@42a9ee95, 3, [B@4041e30, 2022-03-15T12:45:45, null, [B@72c3e91f, 0, 0, 44, 0.0, 0, 7, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@5394b4e6, [B@5e443547, [B@7a954521, 0, 0, 0],
    [3375073338, 12571202, [B@17f3c07d, 0, [B@61b675e1, 3, [B@1ea79a9d, 2022-03-15T12:45:45, null, [B@4e4b7825, 0, 0, 65, 0.0, 0, 10, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@4732b9b9, [B@15f9d5c3, [B@3728c693, 0, 0, 0],
    [3375073339, 12571202, [B@22371a03, 0, [B@701a808d, 3, [B@2b161480, 2022-03-15T12:45:45, null, [B@5a7b532f, 0, 0, 77, 0.0, 0, 12, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@4086bd61, [B@643c4314, [B@7f15f907, 0, 0, 0],
    [3375073340, 12571202, [B@7f773fe1, 0, [B@a6ff8db, 3, [B@c4d2e61, 2022-03-15T12:45:45, null, [B@5c40232e, 0, 0, 88, 0.0, 0, 17, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@1a8e9770, [B@6fd21dda, [B@a091867, 0, 0, 0],
    [3375073341, 12571202, [B@570d135b, 0, [B@39563bdd, 3, [B@4615cde0, 2022-03-15T12:45:45, null, [B@49d2f65, 0, 0, 24, 0.0, 0, 4, 0.0, 0.0, 0, 0, 0, 0, 0, null, null, null, [B@3b357366, [B@33352f0e, [B@5ba78e45, 0, 0, 0]

Root Cause: CDC Skipping Previously Processed Rows The key log line is:

Skipping previously processed row event: Event{...eventType=DELETE_ROWS...}

This means your CDC connector is seeing binlog events but intentionally skipping them because it considers them already processed. This is a CDC state/offset issue — the connector's saved binlog position is ahead of or misaligned with the actual data, causing it to skip rows it should be syncing. Why This Happens This is a known CDC issue where after a reset or restart, the Debezium offset stored in Airbyte's state points to a position in the binlog that causes rows to be skipped as "already seen." [CDC incremental issue] What To Do 1. Reset the connection state (most likely fix) In the Airbyte UI: • Go to your connection → Status tab • Click Reset (or "Clear data" depending on your version) • This clears the saved CDC offset and forces a fresh full refresh This will re-sync all data from scratch for this table. 2. After resetting, verify binlog retention Make sure your binlogs won't expire during the sync:

-- Check current setting
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

-- Set to 7 days (recommended)
SET GLOBAL binlog_expire_logs_seconds = 604800;

[Binlog retention] 3. Consider switching to Full Refresh temporarily To verify the table syncs correctly without CDC complexity: • Edit the connection → change sync mode to Full Refresh • Run one successful sync • Then switch back to CDC incremental The good news is this is not a resource or infrastructure problem — it's a CDC state alignment issue that a connection reset should fix. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai don't wabt to reload table

I understand you don't want to do a full reload. Unfortunately, the knowledge sources do not contain enough information to provide a confident alternative solution for fixing the CDC offset misalignment without triggering a full refresh. What I can say from the available sources is: Possible Option: Edit Connection State Manually Airbyte allows you to manually edit the CDC state/offset to adjust where the sync resumes from, without a full reset: 1. Go to your connection in the Airbyte UI 2. Click the Settings tab 3. Click the Advanced dropdown 4. Edit the Connection State to adjust the binlog position > ⚠️ Warning: Updates to connection state should be handled with extreme care. Updates may break your syncs. Make changes only as directed by the Airbyte team. [Connection state docs] My Recommendation Since manually editing the state requires knowing the exact correct binlog file and position, and getting it wrong could make things worse, I'd strongly suggest: • Opening a support ticket with Airbyte or posting in the Airbyte GitHub issues with your logs • The Airbyte team can guide you on setting the correct binlog offset to resume CDC without a full reload The knowledge sources do not provide a safe step-by-step procedure for this specific scenario beyond what's described above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.