using MySQL V3.52.3 on Airbyte 2.0.0; I'm seeing in the connection state for incremental streams the "cursor_record_count" is always 0 = this is causing the syncs to take hours to run on larger tables - is this a known defect?

I'm sorry, but the knowledge sources do not contain enough information to confirm whether the specific

cursor_record_count

always being

0

in the connection state is a known defect in MySQL source v3.52.3 on Airbyte 2.0.0. The knowledge sources do cover some related MySQL incremental sync issues, but none of them match your exact symptom: • A microsecond precision truncation bug in cursor-based incremental sync (v3.50.9) that caused 0 records to be returned. [MySQL microsecond issue] • An ArithmeticException (/ by zero) in partition boundary calculation for large tables (v3.50.x), fixed in v3.0.8. [MySQL partition bug] • A BIGINT UNSIGNED partition boundary fix released in v3.52.2. [BIGINT UNSIGNED fix] None of these directly describe a

cursor_record_count = 0

state field causing slow syncs in v3.52.3. Recommended next steps: 1. Check the Airbyte GitHub issues for source-mysql to search for

cursor_record_count

— this may be a newly filed or unreported bug. 2. Join the Airbyte Community Slack where you can get peer support and visibility from the Airbyte team. 3. If you're on Airbyte Cloud, open a support ticket at support.airbyte.com referencing your connector version and the specific state field behavior. 4. As a workaround, you might consider whether switching to CDC (binlog-based) replication is feasible for your large tables, which avoids cursor-based limitations entirely. [Incremental Append Limitations] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.