debezium / debezium/dbz

The connector stopped streaming data even though the status API shows it as RUNNING and there are no errors in the logs. [DBZ-9467]

Open
#90 0 comments 0 reactions 0 assignees View on GitHub
component/mysql-connector migrated-from-jira type/bug
Dominant language
HTML
Stars
6
Forks
8
Avg merge
2d 19h
Merged PRs (30d)
1

Description

Migrated from [DBZ-9467](https://issues.redhat.com/browse/DBZ-9467)

In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.
h1. Bug report

For bug reports, provide this information, please:
h2. What Debezium connector do you use and what version?

2.7.1.Final-mysql connect
h2. What is the connector configuration?

 
{code:java}
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: mysql-connector-orders namespace: kafka-prod labels: strimzi.io/cluster: kafka-connect-prod spec: class: io.debezium.connector.mysql.MySqlConnector tasksMax: 1 config: tasks.max: 1 database.hostname: orders-db.prod.internal database.port: 3306 database.user: debezium_user database.password: ${secrets:kafka-prod/mysql-credentials:password} database.server.id: 10001 topic.prefix: mysql database.include.list: orders_db table.include.list: orders_db.* schema.history.internal.kafka.bootstrap.servers: kafka-bootstrap:9092 schema.history.internal.kafka.topic: schema-changes.mysql.orders snapshot.mode: schema_only snapshot.locking.mode: none value.converter: org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable: false key.converter: org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable: false This connector status keeps showing RUNNING with HTTP 200, but no CDC data is produced. Recovery Attempt (Example) We created a new connector with a new name and server ID and tried to start from the last known binlog position: apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: mysql-connector-orders-recovery namespace: kafka-prod labels: strimzi.io/cluster: kafka-connect-prod spec: class: io.debezium.connector.mysql.MySqlConnector tasksMax: 1 config: tasks.max: 1 database.hostname: orders-db.prod.internal database.port: 3306 database.user: debezium_user database.password: ${secrets:kafka-prod/mysql-credentials:password} database.server.id: 10002 topic.prefix: mysql database.include.list: orders_db table.include.list: orders_db.* schema.history.internal.kafka.bootstrap.servers: kafka-bootstrap:9092 schema.history.internal.kafka.topic: schema-changes.mysql.orders database.initial.binlog.filename: mysql-bin-changelog.012345 database.initial.binlog.position: 1234567 snapshot.mode: schema_only snapshot.locking.mode: none value.converter: org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable: false key.converter: org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable: false But even with the binlog filename and position, it does not resume correctly.

 {code}
h2. What is the captured database version and mode of deployment?

We have deployed kafka on eks using strimzi and running mysql-connect on eks.
h2. Do you have the connector logs, ideally from start till finish?

Connector logs are not showing any error and showing status 200 when we are checking connector status.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the issue with the supplied MySQL connector configuration and checking the status API alongside connector logs and the binlog position. Compare the original and recovery configurations, including the initial binlog filename and position. Done means the connector resumes producing CDC data while its reported status remains accurate.

Written by the indexing model from the issue text.

Assessment

Tech stack
kafka, kubernetes, mysql
Domain
databases, distributed-systems, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.