Enable binary logging on MySQL: set binlog_format=ROW and binlog_row_image=FULL in my.cnf; confirm with SHOW VARIABLES LIKE 'binlog_format'.
Create a Debezium MySQL user with required privileges: GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'debezium'@'%'.
Deploy the Debezium MySQL connector via Kafka Connect REST API with a JSON config specifying connector.class=io.debezium.connector.mysql.MySqlConnector, database.hostname, database.port, database.user, database.password, database.server.id (unique integer), database.server.name, and database.history.kafka.topic.
Set snapshot.mode to initial (default) for a full initial snapshot followed by streaming, or to schema_only to skip data snapshot and capture only future changes.
Verify the connector is running with GET /connectors/{name}/status and consume from the output topic (database.server.name.schema.table) to confirm change events are flowing.
Known gotchas
The database.server.id must be unique across all MySQL replication clients connected to the same server; duplicate server IDs cause the MySQL binlog stream to silently drop one of the connections.
MySQL's binlog retention (expire_logs_days or binlog_expire_logs_seconds) must be long enough to cover any connector downtime; if the connector restarts after the binlog has been purged, it cannot resume and must re-snapshot.
The schema history Kafka topic (database.history.kafka.topic) must have infinite retention (retention.ms=-1) and replication factor ≥ 1; deleting or compacting this topic will corrupt the connector's schema history.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp