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

Bug report

For bug reports, provide this information, please:

What Debezium connector do you use and what version?

io.debezium.connector.mariadb.MariaDbConnector

(I have also tested with the MySQLConnector in Mariadb mode)

What is the connector configuration?

   connector.class = io.debezium.connector.mariadb.MariaDbConnector
   schema.history.internal.store.only.captured.tables.ddl = true
   schema.history.internal.store.only.captured.databases.ddl = true
   provide.transaction.metadata = true
   schema.history.internal.file.filename = /data/schemahistory.dat
   connector.adapter = mariadb
   topic.prefix = ignored
   database.jdbc.driver = org.mariadb.jdbc.Driver
   offset.storage.file.filename = /data/offsets.dat
   record.processing.threads = 1
   errors.retry.delay.initial.ms = 300
   value.converter = org.apache.kafka.connect.json.JsonConverter
   key.converter = org.apache.kafka.connect.json.JsonConverter
   database.user = debezium-service
   offset.storage = org.apache.kafka.connect.storage.FileOffsetBackingStore
   database.server.id = 453535
   database.server.name = server1
   offset.flush.timeout.ms = 5000
   errors.retry.delay.max.ms = 10000
   database.snapshot.mode = when_needed
   database.port = 3306
   offset.flush.interval.ms = 0
   database.ssl.mode = trust
   database.protocol = jdbc:mariadb
   schema.history.internal = io.debezium.storage.file.history.FileSchemaHistory
   errors.max.retries = -1
   database.hostname = mariadb-0
   database.password = ********
   name = debezium
   table.include.list = <roughly 40 tables across two schemas>
   database.include.list = schema1,schema2

What is the captured database version and mode of deployment?

(E.g. on-premises, with a specific cloud provider, etc.)

Server version: 10.11.9-MariaDB-log MariaDB Server

In Kubernetes environments

What behavior do you expect?

<Your answer>

What behavior do you see?

I am testing the situation in which, while Debezium is down, the binary log is purged.  When Debezium comes back up it fails with the following error (more context attached):

{{{{2025-04-14 20:14:48,621 ERROR [io.deb.emb.EmbeddedEngine] (pool-6-thread-1) Error while trying to run connector class 'io.debezium.connector.mariadb.MariaDbConnector': org.apache.kafka.connect.errors.ConnectException: An exception occurred in the change event producer. This connector will be stopped.
at io.debezium.pipeline.ErrorHandler.setProducerThrowable(ErrorHandler.java:67)
at io.debezium.connector.binlog.BinlogStreamingChangeEventSource$ReaderThreadLifecycleListener.onCommunicationFailure(BinlogStreamingChangeEventSource.java:1248)
at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:1110)
at com.github.shyiko.mysql.binlog.BinaryLogClient.connect(BinaryLogClient.java:657)
at com.github.shyiko.mysql.binlog.BinaryLogClient$7.run(BinaryLogClient.java:959)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: io.debezium.DebeziumException: Error: connecting slave requested to start from GTID 0-151826122-469153, which is not in the master's binlog Error code: 1236; SQLSTATE: HY000.
at io.debezium.connector.binlog.BinlogStreamingChangeEventSource.wrap(BinlogStreamingChangeEventSource.java:1202)
... 5 more
Caused by: com.github.shyiko.mysql.binlog.network.ServerException: Error: connecting slave requested to start from GTID 0-151826122-469153, which is not in the master's binlog
at com.github.shyiko.mysql.binlog.BinaryLogClient.listenForEventPackets(BinaryLogClient.java:1074)
... 3 more}}}}

Do you see the same behaviour using the latest released Debezium version?

(Ideally, also verify with latest Alpha/Beta/CR version)

Yes, with 3.1.0

Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide DEBUG/TRACE level log)

I will attach the log file