Yanquan Lv created FLINK-40691:
----------------------------------
Summary: Fix comparison logic for binlog filename with more than 6
digits
Key: FLINK-40691
URL: https://issues.apache.org/jira/browse/FLINK-40691
Project: Flink
Issue Type: Improvement
Components: Flink CDC
Affects Versions: cdc-3.5.0, cdc-3.4.0, cdc-3.2.1, cdc-3.3.0, cdc-3.1.1,
cdc-3.2.0, cdc-3.1.0
Reporter: Yanquan Lv
h3. Background
MySQL writes binlog files as {{{}<base-name>.NNNNNN{}}}, where the sequence
number is zero‑padded to *at least* 6 digits. The padding is a {_}minimum{_},
not a fixed width: once an instance rotates past {{{}999999{}}}, the file names
grow to 7, 8, … digits (e.g. {{mysql-bin.999999}} → {{{}mysql-bin.1000000{}}}).
Long‑running or write‑heavy instances (and instances with a small
{{{}max_binlog_size{}}}) do reach this boundary, and some managed/archived
binlog sources use a different padding width as well.
h3. Problem
{{BinlogOffset#compareTo}} compared binlog file names purely with
{{{}String#compareToIgnoreCase{}}}, i.e. lexicographically. When the two file
names have a different number of digits, the lexicographic order is the
opposite of the real chronological order:
{code:java}
"mysql-bin.999999".compareToIgnoreCase("mysql-bin.1000000") > 0
// 999999 sorts AFTER 1000000 {code}
So a _newer_ offset is reported as {_}older{_}, and vice versa. The same
corruption propagates to every helper built on top of {{{}compareTo{}}}:
{{{}isBefore{}}}, {{{}isAfter{}}}, {{{}isAtOrBefore{}}}, {{{}isAtOrAfter{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
