Enabling Binary Logging on Amazon Aurora Serverless (MySQL) for Fivetran

If you’re setting up a Fivetran MySQL connector against Amazon Aurora Serverless (MySQL-compatible) and you see an error like:

Binary logging must be enabled: SHOW MASTER STATUS must return a non-empty result

…you’re running into a requirement for incremental (CDC) syncing. Fivetran needs a binlog file + position so it can resume from the last processed change.

This guide shows you how to enable and validate binary logging on Aurora Serverless and avoid the most common pitfalls.

Why “automated backups enabled” isn’t enough on Aurora

On standard RDS MySQL, enabling automated backups (retention > 0) often implies binlogging is available. Aurora MySQL behaves differently: binary logging is driven primarily by DB cluster parameter group settings.

So it’s totally possible to have backups set to 2+ days and still see:

Step 0: Confirm whether you’re Aurora Serverless v1 or v2

This is important because it determines which incremental method is viable.

• Aurora Serverless v1: many CDC/binlog-based approaches are not supported the same way as provisioned Aurora. You may need to use a non-binlog incremental method (for Fivetran, that’s often Teleport Sync).
• Aurora Serverless v2 (or provisioned Aurora): binlog-based incremental sync is typically viable once enabled correctly.

Where to check: AWS Console → RDS → Databases → select your cluster → look for Serverless v1/v2 and the engine version.

Step 1: Verify the error condition from the same endpoint Fivetran uses

Connect to the exact hostname/endpoint configured in Fivetran (writer endpoint is typical) and run:

What you want:

• log_bin = ON
• SHOW MASTER STATUS returns at least one row (a binlog file name and position)

If SHOW MASTER STATUS is empty, Fivetran can’t safely do incremental sync.

Sanity-check you’re on the writer

Aurora clusters can have writer + readers. Ensure you’re connected to the writer endpoint:

If @@read_only = 1, you’re not on the writer.

Step 2: Enable binary logging via the DB cluster parameter group

Aurora uses DB cluster parameter groups (not instance parameter groups) to control binlog behavior.

2.1 Create or select a DB cluster parameter group

AWS Console → RDS → Parameter groups → Create parameter group

• Type: DB cluster parameter group
• Family: must match your Aurora MySQL major version (for example, Aurora MySQL 5.7 vs 8.0)

2.2 Set the key binlog parameter

Set:

• binlog_format = ROW

ROW is the most compatible choice for change data capture.

Note: Changing binlog_format commonly requires a reboot/failover to take effect (it’s often a static parameter).

2.3 Apply the parameter group to the cluster

AWS Console → RDS → Databases → select your cluster → Modify → attach the new/updated DB cluster parameter group.

2.4 Apply changes (reboot/failover)

If AWS indicates the parameter is static, you’ll need to reboot the writer or perform a failover for the new setting to apply.

Step 3: Set binlog retention so Fivetran doesn’t “fall behind”

Aurora can purge binlogs aggressively. If your connector lags behind (maintenance, network issues, large loads), it may lose the binlog window and fail.

Set a retention window using Aurora’s stored procedure:

Suggested starting points:

• 24 hours: minimum reasonable baseline
• 72–168 hours (3–7 days): safer for busy systems, heavy ETL, or maintenance windows

Choose a value that matches your operational reality.

Step 4: Validate that binlogging is working

After applying the cluster parameter group and reboot/failover, re-check:

If log_bin is still OFF:

• Confirm you changed a DB cluster parameter group (not instance)
• Confirm the cluster is using that parameter group
• Confirm you applied the change (reboot/failover if required)
• Confirm you’re connecting to the writer endpoint

Step 5: Complete Fivetran setup and run a historical re-sync

Once SHOW MASTER STATUS returns a row, Fivetran should be able to establish the incremental position.

If Fivetran previously attempted syncs without binlogs, you’ll typically need to run a historical re-sync after enabling binary logging to ensure data integrity.

Common gotchas (and quick fixes)

“Backups are enabled but log_bin is OFF”

That’s normal on Aurora if binlog_format is still OFF or not applied. Fix: cluster parameter group → binlog_format=ROW.

“It worked for a day, then broke”

Binlogs were purged before the connector caught up. Fix: increase binlog retention hours.

“We have readers—does it matter?”

Yes. Fivetran should typically connect to the writer for binlog-based CDC unless you’ve explicitly designed a replica-based approach.

Quick checklist

• Confirm Serverless v1 vs v2
• Connect to the same endpoint Fivetran uses
• log_bin=ON and SHOW MASTER STATUS returns rows
• DB cluster parameter group sets binlog_format=ROW
• Reboot/failover if required
• Set binlog retention hours to a realistic window
• Run Fivetran historical re-sync