Question 1

What does MySQL change capture need?

Accepted Answer

Grants for SELECT, REPLICATION CLIENT and REPLICATION SLAVE, and server settings 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, with position based replication as the fallback. Keep binary logs at least twenty four hours so a paused sync resumes rather than needing a full reload.

Question 2

How do MySQL deletes appear in Databricks?

Accepted Answer

As a deleted at timestamp on the row by default, which keeps the record visible to anything that needs to count what has gone. Turning on propagate hard deletes removes those rows physically after the load and merge. Two constraints worth knowing: hard deletes require the Polytomic timestamp columns to stay enabled because the delete keys off them, and this option belongs to bulk syncs rather than model syncs, whose merge only ever applies the timestamp.

Question 3

Should I point this at a replica rather than the primary?

Accepted Answer

Often yes, and it is supported. A replica works provided it exposes readable binary logs and carries the same privileges and server settings, and it is the usual arrangement when the primary is under load or policy keeps outside systems away from it. The thing a replica does not solve is keys: 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

Does this need cloud storage on the Databricks side?

Accepted Answer

Yes, and it is the main setup difference from a warehouse that loads internally. Rows are written as load files into storage you own and then pulled in with COPY INTO. On AWS that is an S3 bucket using an access key or IAM role, and on Azure an ADLS Gen2 storage account read over abfss. There is no GCP destination path. Files are removed after a successful load, so the bucket is working space rather than a second copy of your data.

Question 5

Why replicate an application database into a lakehouse?

Accepted Answer

Because a database tuned to serve your product is the wrong place to run analysis, and the context you want was never in it. Long aggregations compete with live traffic, and CRM or billing history lives elsewhere. ETL into a data warehouse moves that work off production and puts application tables where notebooks, SQL and model training all reach the same copy rather than three different extracts.

Sync MySQL to Databricks

Sync MySQL to Databricks with Polytomic

Deletes come from the log

Soft or hard deletes

Backfill then follow

Or sync Databricks to MySQL

Trusted by businesses worldwide

Step-by-step integration guide

Connect MySQL in Polytomic

Connect Databricks in Polytomic

Create a sync between MySQL and Databricks

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