在读取到一个binlog文件的时候出现: InvalidData: stream did not contain valid UTF-8

[liuxuzxx]

1. 具体的日志信息如下:

2026-01-16T15:31:38.720029391+08:00 stderr F read mysql binlog error!: IoError(Error { kind: InvalidData, message: "stream did not contain valid UTF-8" })

2. 代码如下：

let mut stream = client
        .connect()
        .await
        .expect("connect to mysql read binlog file error!");

    loop {
        let result = stream.read().await; //代码出现问题的地方，stream是BinlogStream类型
        match result {
            Ok((_header, data)) => match data {
                EventData::Rotate(event) => {
                  ...
                }
                EventData::TableMap(event) => {
                   ...
                }
                EventData::WriteRows(event) => {
                  ...
                }
                EventData::DeleteRows(event) => {
                    ...
                }
                EventData::UpdateRows(event) => {
                    ...
                }
                EventData::NotSupported => {
                    ...
                },
                ......其他的事件类型处理
            },
            Err(err) => {
                panic!("read mysql binlog error:{:?}", err);//报错的就是这样抛出来的
            }
        }
    }

背景:

在这个错误之前，服务已经稳定运行了: 大概200天,大概每天处理: 1000个左右的binlog文件. 一共稳定处理了: 20w个.但是在处理这个错误的binlog的文件的时候，从新处理还是不行，尝试了5次，每次都是在同一个position出现问题.

[liuxuzxx]

看了下是在执行 String::from_utf8()这个方法的时候报错的，也就是说对应的字节Vec 不是UTF8的编码.所以报错.我在仔细的查找下为什么.

[caiq1nyu]

可以 mysqlbinlog -vvv --start-position= <BINARY_LOG_FILE> 看下这个出问题的position对应的binlog内容，方便的话可以贴出来给我们分析下

[liuruishan-2022]

可以 mysqlbinlog -vvv --start-position= <BINARY_LOG_FILE> 看下这个出问题的position对应的binlog内容，方便的话可以贴出来给我们分析下
这个在那时还没有实验。不过最近又出现了两次如下的日志报错:

2026-03-06 19:39:43	
2026-03-06T19:39:43.612002423+08:00 stderr F read mysql binlog error:UnexpectedData("Read binlog header timeout after 10s while waiting for packet header")

2026-03-06 19:39:43	
2026-03-06T19:39:43.612008574+08:00 stderr F note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

我看了下mysql-binlog-connector-rust的源码部分:

    async fn read_packet_info(&mut self) -> Result<(usize, u8), BinlogError> {
        let mut buf = vec![0u8; 4];
        match timeout(
            Duration::from_secs(self.timeout_secs),
            self.stream.read_exact(&mut buf),
        )
        .await
        {
            Ok(Ok(_)) => {}
            Ok(Err(e)) => return Err(BinlogError::from(e)),
            Err(_) => {
                return Err(BinlogError::UnexpectedData(format!(
                    "Read binlog header timeout after {}s while waiting for packet header",
                    self.timeout_secs
                )));
            }
        }
        let mut rdr = Cursor::new(buf);
        let length = rdr.read_u24::<LittleEndian>()? as usize;
        let sequence = rdr.read_u8()?;
        Ok((length, sequence))
    }

这个原因是:

1. 设置的超时时间太少了？(10s)

但是让人疑惑的是，出现时间，一个是在早上: 6点43分，另外一个是在晚上的: 19点39分，这两个时间都不是业务高峰期，业务高峰期的时候能够达到: 15w/s的binlog的处理速度,这两个时间点只有: 3.3w/s的binlog事件采集速度。按照道理来说，业务数据库应该不忙才对，还是说不应该用binlog的事件多少来评估mysql的繁忙程度？

2. 目前是做了如下的措施: 调整超时为60s,如果还是超时，那就在自己的业务代码进行重试，超过配置次数的重实就退出进程，让pod自己重启

[liuruishan-2022]

看了下mysql的监控，看到对应的时间点都有问题，InnoDB行锁等待，和TPS突然间增高