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, binlog_row_image set to FULL, and on MySQL 8.0.1 and later binlog_row_metadata set to 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 given table can stream or has to fall back.

Question 3

What happens when the source schema changes?

Accepted Answer

DDL statements in the binary log are treated as informational rather than as row changes, so they are not replayed verbatim into the data warehouse. Schema discovery handles source changes separately, and newly discovered columns can be added downstream once selected. Additive changes are therefore straightforward. Destructive or incompatible changes, such as retyping a column in place, are the ones that need a configuration review or a resync, so it is worth knowing which of your tables churn.

Question 4

What if we cannot enable change capture?

Accepted Answer

Use a tracking field instead, normally updated_at or another monotonically increasing column. The first run after configuring it is a full scan, and later reads filter on the field being greater than the last recorded position. The tradeoff is specific and worth stating: tracking fields do not propagate deletes. A row removed from MySQL will simply stop being returned, and without reconciliation it will sit in the data warehouse indefinitely. Pairing the tracking field with a scheduled full ETL read is the usual answer.

Question 5

Why replicate MySQL into a data warehouse?

Accepted Answer

Because analytical queries and an operational database want opposite things. Aggregations across a large table are expensive on a server that is also serving your application, and joining that data to CRM, billing or marketing systems is awkward from inside the database. ETL into a data warehouse moves the analytical load off production and puts application data next to everything else, which is usually where the questions people actually ask happen to live.

Sync MySQL to Snowflake

Sync MySQL to Snowflake with Polytomic

Deletes carried by change capture

Primary key required for CDC

Backfill then stream

Or sync Snowflake to MySQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect MySQL in Polytomic

Connect Snowflake in Polytomic

Create a sync between MySQL and Snowflake

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 Snowflake?