Bug report

What Debezium connector do you use and what version?

• Connector: io.debezium.connector.mariadb.MariaDbConnector

• Version: 3.2.1.Final , The latest stable version available. The issue is present in recent versions. 

What is the connector configuration?

Here is a sanitized version of the relevant connector configuration:

{     "connector.class": "io.debezium.connector.mariadb.MariaDbConnector",     "tasks.max": "1",     "topic.prefix": "my_prefix",     "database.server.id": "277459",     "database.hostname": "...",     "database.port": "3306",     "database.user": "...",     "database.password": "...",     "database.include.list": "cashback_engine_rebates_api",     "table.include.list": "cashback_engine_rebates_api.rebate_account",     "database.ssl.mode": "disable",     "snapshot.mode": "initial",     "snapshot.locking.mode": "none",     "schema.history.internal.skip.unparseable.ddl": "true",     "schema.history.internal.store.only.captured.tables.ddl": "true",     "schema.history.internal.kafka.topic": "my_prefix.history",     "schema.history.internal.kafka.bootstrap.servers": "...",     "include.schema.changes": "false" }

What is the captured database version and mode of deployment?

• Database: MariaDB (11.4.5-MariaDB-log).

• Deployment: cloud.

What behavior do you expect?

I expect the Debezium MariaDB connector to correctly parse the CREATE TABLE DDL for a MariaDB system-versioned table. Specifically, it should understand the syntax for columns defined as GENERATED ALWAYS AS ROW START/END, the PERIOD FOR SYSTEM_TIME clause, and the WITH SYSTEM VERSIONING table option.

The schema for the table should be successfully registered, and the connector should proceed to capture its data without any parsing errors.

What behavior do you see?

The connector's DDL parser fails when it encounters a CREATE TABLE statement for a system-versioned table that uses custom column names (ts, te) for the transaction-time period.

Even with schema.history.internal.skip.unparseable.ddl set to true, the connector logs a warning and a io.debezium.text.ParsingException, effectively ignoring the table and preventing any data from being captured from it.

The unparseable DDL statement is:

CREATE TABLE `rebate_account` (
`id`char(36) NOT NULL,
...
`ts`timestamp(6) GENERATEDALWAYSASROWSTART,
`te`timestamp(6) GENERATEDALWAYSASROWEND,
`assigned_account_id`char(36) DEFAULTNULL,
`assigned_user_id`char(36) DEFAULTNULL,
PRIMARY KEY (`id`,`te`),
UNIQUEKEY`rebate_account_unique` (`account_id`,`te`),
...
KEY`idx` (`id`),
PERIODFORSYSTEM_TIME (`ts`, `te`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci WITH SYSTEM VERSIONING

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

Yes, this behavior is present in the latest stable release.

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

Yes, here is the relevant stack trace from the log:

WARN [mysql-source-cashback-engine-rebates|task-0] Ignoring unparseable DDL statement 'CREATE TABLE `rebate_account` ( ... ) WITH SYSTEM VERSIONING' (io.debezium.connector.binlog.BinlogDatabaseSchema)
io.debezium.text.ParsingException: DDL statement couldn't be parsed. Please open a Jira issue with the statement 'CREATE TABLE `rebate_account` ( ... ) WITH SYSTEM VERSIONING'
no viable alternative at input 'CREATE TABLE `rebate_account` (... `ts` timestamp(6) GENERATED ALWAYS AS ROW'
at io.debezium.antlr.ParsingErrorListener.syntaxError(ParsingErrorListener.java:43)
at org.antlr.v4.runtime.ProxyErrorListener.syntaxError(ProxyErrorListener.java:41)
at org.antlr.v4.runtime.Parser.notifyErrorListeners(Parser.java:543)
at org.antlr.v4.runtime.DefaultErrorStrategy.reportNoViableAlternative(DefaultErrorStrategy.java:310)
at org.antlr.v4.runtime.DefaultErrorStrategy.reportError(DefaultErrorStrategy.java:136)
at io.debezium.ddl.parser.mariadb.generated.MariaDBParser.sqlStatements(MariaDBParser.java:1271)
at io.debezium.ddl.parser.mariadb.generated.MariaDBParser.root(MariaDBParser.java:991)
at io.debezium.connector.mariadb.antlr.MariaDbAntlrDdlParser.parseTree(MariaDbAntlrDdlParser.java:73)
at io.debezium.connector.mariadb.antlr.MariaDbAntlrDdlParser.parseTree(MariaDbAntlrDdlParser.java:46)
at io.debezium.antlr.AntlrDdlParser.parse(AntlrDdlParser.java:73)
at io.debezium.connector.binlog.BinlogDatabaseSchema.parseDdl(BinlogDatabaseSchema.java:311)
at io.debezium.connector.binlog.BinlogDatabaseSchema.parseSnapshotDdl(BinlogDatabaseSchema.java:243)
at io.debezium.connector.binlog.BinlogSnapshotChangeEventSource.addSchemaEvent(BinlogSnapshotChangeEventSource.java:298)
... 19 more
Caused by: org.antlr.v4.runtime.NoViableAltException
... 23 more

How to reproduce the issue using our tutorial deployment?

• Set up a Debezium environment with a MariaDB connector pointing to a MariaDB instance.

• Connect to the MariaDB instance and execute the CREATE TABLE statement provided in the "What behavior do you see?" section.

• Configure the MariaDB connector to include this table (e.g., table.include.list: "your_database.rebate_account").

• Start the connector and trigger a snapshot.

• Observe the connector's logs. You will see the ParsingException shown above, and no data for the rebate_account table will be produced to Kafka.