Question 1

What does MySQL change capture need?

Accepted Answer

Grants for SELECT, REPLICATION CLIENT and REPLICATION SLAVE, with log_bin on, binlog_format set to ROW and binlog_row_image set to FULL. On MySQL 8.0.1 and later binlog_row_metadata should be FULL too. GTID with enforce_gtid_consistency is recommended, position based replication being the fallback. Keep binary logs at least twenty four hours so a paused sync resumes instead of needing a full reload.

Question 2

What actually happens when a row is hard deleted?

Accepted Answer

More than on other warehouses, because ClickHouse handles deletion as a mutation rather than an ordinary statement. Polytomic first inserts a tombstone version marked with a deleted at timestamp, which is enough on its own if you are happy with soft deletes. With hard deletes enabled it then forces a merge with OPTIMIZE FINAL and runs ALTER TABLE DELETE with mutation synchronisation turned on, so the run waits for the mutation to complete rather than leaving it in flight. That is heavier than a normal write, so it is worth enabling deliberately.

Question 3

Should I point this at a replica?

Accepted Answer

Often yes. A replica works provided it exposes readable binary logs and carries the same privileges and settings, and it is the usual arrangement when the primary is busy or policy keeps external systems away from it. What a replica does not change is the key requirement: a table still needs a primary key to use change capture, and that is normally what decides whether it streams or falls back to a tracking field.

Question 4

Why does a count return more rows than I expect?

Accepted Answer

Because ReplacingMergeTree keeps every version until a background merge collapses them. An updated row is written as a new version rather than modifying the old one, so between the write and the merge both exist. This is normal ClickHouse behaviour rather than a sync problem. Query with FINAL when you need settled state, or use aggregation that picks the latest version, and reach for OPTIMIZE TABLE FINAL only when you actually need to force it.

Question 5

Why replicate an application database into ClickHouse?

Accepted Answer

Because the analytical questions and the product workload want different engines. Aggregations across large tables are expensive on a server serving live traffic, and ClickHouse is built precisely for that scan heavy pattern. ETL into a data warehouse moves the work across while leaving MySQL to do what it is good at, which is the usual reason teams reach for this pairing rather than scaling the database itself.

Sync MySQL to ClickHouse

Sync MySQL to ClickHouse with Polytomic

Deletes from the binary log

Real deletes when you want them

Backfill then follow

Or sync ClickHouse to MySQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect MySQL in Polytomic

Connect ClickHouse in Polytomic

Create a sync between MySQL and ClickHouse

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