@kapa.ai sync dies midway with

message='activity Heartbeat timeout', timeoutType=TIMEOUT_TYPE_HEARTBEAT

between MySQL source and Postgres destination. What does this mean?

Activity Heartbeat Timeout Explained The error

activity Heartbeat timeout, timeoutType=TIMEOUT_TYPE_HEARTBEAT

means that Airbyte's platform did not receive a "heartbeat" signal from your source (MySQL) or destination (Postgres) within the configured time threshold, and the sync was automatically failed and restarted as a result. [Heartbeats Docs] How Heartbeats Work Airbyte monitors both the source and destination for signs of activity: • Source heartbeat: The platform tracks

RECORD

and

STATE

messages emitted by the source. If no message is received within the threshold (default: 3 hours), the sync fails with

The source is unresponsive

. [Technical Details] • Destination heartbeat: The platform monitors whether a call to the destination has taken longer than the configured timeout (default: 24 hours). If exceeded, the sync fails with

The destination is unresponsive

. [Technical Details] Common Causes for MySQL → Postgres For your specific setup, the most likely culprits are: 1. Slow MySQL query response — especially if you're using an un-indexed column as a cursor in an incremental sync, or if the database is under-provisioned. [Heartbeats Docs] 2. MySQL query timeout — MySQL's

max_execution_time

setting may be canceling long-running queries before Airbyte can emit records. You can address this by increasing

max_execution_time

or adjusting the

Checkpoint Target Time Interval

in the source config. [MySQL Troubleshooting] 3. Slow Postgres destination writes — If the destination is slow to accept writes (e.g., due to resource constraints or a connection pooler enforcing a low

statement_timeout

), the sync can time out on the destination side. 4. CDC-specific issues — If you're using CDC (Change Data Capture) mode with MySQL, a growing schema history or binlog expiry can cause syncs to stall during startup, hitting the heartbeat timeout before any records are emitted. [MySQL CDC Issue] What You Can Do • Check your cursor column: Ensure it is indexed if using incremental sync. • Check MySQL's

max_execution_time

: Set it higher than your

Checkpoint Target Time Interval

(default 5 minutes = 300,000ms). [MySQL Troubleshooting] • Check Postgres destination resources: Ensure the destination has sufficient resources to handle the write volume. • If using CDC: Check binlog retention and schema history size. • Adjust heartbeat thresholds (self-hosted only): You can modify

heartbeat-max-seconds-between-messages

and

destination-timeout-max-seconds

in

flags.yaml

. [Technical Details] If the issue persists, it's worth checking the detailed sync logs for which side (source or destination) triggered the timeout, as the error message will indicate either

The source is unresponsive

or

The destination is unresponsive

. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.