canal.Canal emits an empty e.Header.LogPos event in mariadb 11.4

[alarbada]

BUG

I originally mentioned this behaviour here.

The LogPos header value is empty, as you will be able to see in the test logs. I've looked into the output of show binlog events in 'mysql-bin.000002' and it shows me this:

I can see that for the Write_rows_v1 event the end_log_pos is 0. The Pos is still non zero though.

I've checked the code here, which I believe is the responsible for parsing the event header, but I think it is fine.

I'm a bit lost on how to continue debugging this. From the docker commands canal.Canal should in theory be able to fill the LogPos, I cannot see any mariadb docs specifying that LogPos is empty:

https://mariadb.com/kb/en/2-binlog-event-header

how to reproduce

I've created a small reproduction example here:

https://github.com/alarbada/go-mysql/tree/mariadb-logpos-bug

Basically, git clone the repo and run this test. There's also docker commands to setup the mysql and mariadb instances.

[lance6716]

Let me restate the issue to see if I understand it correctly:

1. The output of show binlog events in 'mysql-bin.000002' shows some binlog events have zero End_log_pos. I think this is a hidden behaviour of MariaDB. It's not related to go-mysql.

2. And because go-mysql is just a translator package that output a golang representation of binlog, so the output field can also be zero.

3. And for the user of canal interface, this is not easy to use.

If so, please give more details about the difficulty you have met. We can discuss a solution for it.

[alarbada]

@lance6716 Yeah, moreless like this. In mariadb, the logpos in the row event is empty, and we use that field heavily in our mysql conduit connector. For example, here's the json dump of a received event from mariadb when I insert a user row:

e.RowsEvent {
  "Table": {
    "Schema": "meroxadb",
    "Name": "users",
    "Columns": [
      {
        "Name": "id",
        "Type": 1,
        "Collation": "",
        "RawType": "bigint(20)",
        "IsAuto": true,
        "IsUnsigned": false,
        "IsVirtual": false,
        "IsStored": false,
        "EnumValues": null,
        "SetValues": null,
        "FixedSize": 0,
        "MaxSize": 0
      },
      {
        "Name": "username",
        "Type": 5,
        "Collation": "utf8mb4_uca1400_ai_ci",
        "RawType": "longtext",
        "IsAuto": false,
        "IsUnsigned": false,
        "IsVirtual": false,
        "IsStored": false,
        "EnumValues": null,
        "SetValues": null,
        "FixedSize": 0,
        "MaxSize": 0
      },
      {
        "Name": "email",
        "Type": 5,
        "Collation": "utf8mb4_uca1400_ai_ci",
        "RawType": "longtext",
        "IsAuto": false,
        "IsUnsigned": false,
        "IsVirtual": false,
        "IsStored": false,
        "EnumValues": null,
        "SetValues": null,
        "FixedSize": 0,
        "MaxSize": 0
      },
      {
        "Name": "created_at",
        "Type": 6,
        "Collation": "",
        "RawType": "datetime(3)",
        "IsAuto": false,
        "IsUnsigned": false,
        "IsVirtual": false,
        "IsStored": false,
        "EnumValues": null,
        "SetValues": null,
        "FixedSize": 0,
        "MaxSize": 0
      }
    ],
    "Indexes": [
      {
        "Name": "PRIMARY",
        "Columns": [
          "id"
        ],
        "Cardinality": [
          2
        ],
        "NoneUnique": 0
      }
    ],
    "PKColumns": [
      0
    ],
    "UnsignedColumns": null
  },
  "Action": "insert",
  "Rows": [
    [
      4,
      "dXNlci00",
      "dXNlci00QGV4YW1wbGUuY29t",
      "2025-05-13T06:43:43.229Z"
    ]
  ],
  "Header": {
    "Timestamp": 1747118623,
    "EventType": 23,
    "ServerID": 1,
    "EventSize": 81,
    "LogPos": 0,
    "Flags": 0
  }
}

You can see that the Header has LogPos 0.

I am quite novice into the intrinsics of the mysql binlog, but so far from what I've seen, what in the event handler is called LogPos is actually the End_Log_Pos?

I must add that I'm not sure whether this is an issue from this library itself, it might just be that I have to get the position of the event from somewhere else.

I'll keep this issue updated for whether I find a proper way to get the logpos.

[lance6716]

This is the doc of header of MariaDB https://mariadb.com/kb/en/2-binlog-event-header/#event-header-structure-19-bytes . You can see that the only position field in the header means "Next Event position" or "End_Log_Pos".

We also use this library to build a MySQL -> TiDB (our database product) replication software. https://github.com/pingcap/tiflow/blob/c594ef6f5a535bffc4d8706299dad91635f3181b/go.mod#L36 . As a database replication developer, here are my thoughts for this behaviour of zero postion:

1. I guess MariaDB suggests that don't bother to consider positions within a transaction. You can see the zero position appears only between BEGIN and COMMIT. Even if the replication layer need to implement checkpoint / progress reporting / failover or other things, it may just treat the transaction as a whole, so don't need to use intra-transaction positions.
2. If there's a must to use intra-transaction positions, you can manually add the EventSize to last valid position to maintain it. Or you can count the index of rows events within a transaction to distinguish them.

[alarbada]

Thanks @lance6716 for the detailed answer! Yeah, I was just surprised to get different behaviour in mariadb for the same transaction in mysql, but I guess that's where its compatibility starts to diverge.

If there's a must to use intra-transaction positions, you can manually add the EventSize to last valid position to maintain it. Or you can count the index of rows events within a transaction to distinguish them.

Yup, will try that.

And because go-mysql is just a translator package that output a golang representation of binlog, so the output field can also be zero.

I'm closing this as this behaviour is actually expected from canal.

Thanks for the detailed answer @lance6716 !