Question 1

What does change data capture require on the MySQL side?

Accepted Answer

Grants for SELECT, REPLICATION CLIENT and REPLICATION SLAVE, and server settings with log_bin enabled, binlog_format set to ROW and binlog_row_image set to FULL. On MySQL 8.0.1 and later, binlog_row_metadata should also be FULL. GTID with enforce_gtid_consistency is recommended, with position based replication as the fallback. Retain binary logs for at least twenty four hours so a paused sync can resume rather than needing a full resync.

Question 2

Can we read from a replica instead of the primary?

Accepted Answer

Yes. A replica is not required, but pointing the connection at one is supported provided it exposes readable binary logs and has the privileges and settings above. This is the usual arrangement when the primary is under load, or when policy keeps external systems away from it. Tables still need a primary key to use change capture, which is the constraint that most often decides whether a table can stream or has to fall back.

Question 3

Do deletes actually land as deletes in Redshift?

Accepted Answer

Yes, with change capture enabled and a primary key present. Redshift supports tombstones, and by default a deleted row is recorded as a soft delete against a deletion timestamp column so it stays visible to queries that want it. Enabling propagate hard deletes removes the rows physically instead. One constraint to know: hard deletes cannot be combined with excluding the Polytomic timestamp columns, since those columns are what the deletion is recorded against.

Question 4

How long does a full reload take?

Accepted Answer

It depends on table size and on your cluster, but the shape is predictable. The initial load reads tables in full and stages the data to S3, then Redshift COPY brings it in, which is considerably faster than row by row inserts. After that first pass, ongoing runs move only what changed. Syncing more frequently generally makes each run cheaper, since Redshift receives a smaller batch of updates at a time rather than a large backlog, so each ETL run stays proportional to the change volume rather than to the size of the database.

Question 5

Why replicate MySQL into a data warehouse?

Accepted Answer

Because an application database is tuned for serving your product, not for answering questions about it. Long running aggregations compete with production traffic, and the context you need, such as CRM records, billing history or support tickets, is not in MySQL at all. ETL into a data warehouse moves that analytical work onto Redshift and lands the application tables beside everything else, which is the point at which cross system reporting stops being a project in itself.

Sync MySQL to Redshift

Sync MySQL to Redshift with Polytomic

Deletes carried by change capture

Primary key required for CDC

Backfill then stream

Or sync Redshift to MySQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect MySQL in Polytomic

Connect Redshift in Polytomic

Create a sync between MySQL and Redshift

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect MySQL with Redshift?