debezium / debezium/dbz

MariaDB EventBuffer drops standalone DDL GTID events when binlog.buffer.size is enabled

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

Description

## Bug report

**What Debezium connector do you use and what version?**

MariaDB connector on current `main` at `dc6df25384100e9441a3306ac79e6b2865eeebf6`.

---

**What is the connector configuration?**

The relevant settings are:

```properties
binlog.buffer.size=10000
include.schema.changes=true
```

MariaDB GTID is enabled.

---

**What is the captured database version and mode of deployment?**

MariaDB 11.4 in a standalone deployment.

---

**What behavior do you expect?**

A `MARIADB_GTID` event whose flag 1 is set should bypass transaction buffering because no commit event follows, but it should still be forwarded immediately to the streaming event handler.

The following standalone DDL schema change record should contain the current GTID in `source.gtid`, consistently with the behavior when `binlog.buffer.size=0`.

---

**What behavior do you see?**

When `binlog.buffer.size` is greater than zero, `EventBuffer` does not open a transaction for a flag 1 `MARIADB_GTID` event, but it also does not call `consumeEvent()` or `handleEvent()` for that event.

As a result, `MariaDbStreamingChangeEventSource.handleGtidEvent()` is not invoked and the schema change record emitted for the following DDL has a null `source.gtid`.

The flag 1 branch that drops the event is here:

https://github.com/debezium/debezium/blob/dc6df25384100e9441a3306ac79e6b2865eeebf6/debezium-connector-binlog/src/main/java/io/debezium/connector/binlog/EventBuffer.java#L110-L119

---

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

The behavior is present on the current `main` branch.

---

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

A MariaDB integration regression test reproduces the issue. Before the proposed change, it fails because `source.gtid` is null. After immediately forwarding the flag 1 GTID event, the test passes and the existing `MariaDbBinlogReaderBufferIT` suite remains green.

---

**How to reproduce the issue using our [tutorial](https://github.com/debezium/debezium-examples/tree/main/tutorial) deployment?**

1. Start MariaDB 11.4 with binary logging and GTID enabled.
2. Start the MariaDB connector with `binlog.buffer.size=10000` and `include.schema.changes=true`.
3. Execute a standalone DDL statement:

```sql
ALTER TABLE products ADD COLUMN volume FLOAT;
```

4. Inspect the emitted schema change record.
5. Compare its `source.gtid` with `@@GLOBAL.gtid_binlog_pos`.

With the current implementation, `source.gtid` is null. With buffering disabled, the GTID event reaches the normal handler and `source.gtid` contains the current DDL GTID.

The expected fix is to process this GTID event immediately without opening a buffered transaction.

Restart-position handling for commit-less DDL behaves the same with buffering enabled and disabled, so DDL replay after an immediate restart is not claimed as part of this bug.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.