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

Bug report

While investigating an issue where the MySQL connector fails with:

The client was disconnected by the server because of inactivity

I found that even though the connector logs Reconnecting after finishing schema recovery, the actual connection object is reused and not revalidated. If the MySQL server silently drops the connection during a long schema recovery (due to wait_timeout), this leads to a failure when setAutoCommit(false) is called.

What Debezium connector do you use and what version?

Debezium MySQL 2.4.2

What is the connector configuration?

– Confidential

What is the captured database version and mode of deployment?

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

Cloud based MySQL 5.6

What behavior do you expect?

Reconnect if connection is not valid

What behavior do you see?

Disconnect during schema recovery

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

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

Yes

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

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

– No

How to reproduce the issue using our tutorial deployment?

Make your connector go into schema recover (one that takes more time than your wait_timeout)

Feature request or enhancement

For feature requests or enhancements, provide this information, please:

I'd like to contribute a patch that:

• Validates the JDBC connection after schema recovery,

• And reconnects if the existing connection is no longer valid

Which use case/requirement will be addressed by the proposed feature?

MySQL and MariaDB connector enhancement

Implementation ideas (optional)

I'd like to contribute a patch that:

• Validates the JDBC connection after schema recovery,

• And reconnects if the existing connection is no longer valid