What causes "error reading binlog event %v: %v" in vitessio/vitess?

Inspect the wrapped error: connection-closed implies retry/reconnect; protocol/packet errors imply binlog corruption.

error reading binlog event %v: %v

Error message

error reading binlog event %v: %v

What it means

While probing a binlog file for its first event's timestamp, getBinlogTimeStamp calls conn.ReadBinlogEvent in a loop. A read failure (IO error, malformed packet, server disconnect) aborts the probe with this error, which includes both the binlog filename and the underlying error. It means the event stream from that file could not be read at all.

Source

Thrown at go/vt/binlog/binlog_connection.go:279

func (bc *BinlogConnection) getBinlogTimeStamp(filename string) (blTimestamp int64, err error) {
	conn, err := connectForReplication(bc.cp)
	if err != nil {
		return 0, err
	}
	defer conn.Close()

	if err := conn.WriteComBinlogDump(bc.serverID, filename, 4, 0); err != nil {
		return 0, fmt.Errorf("failed to send the ComBinlogDump command: %v", err)
	}

	// Get the first event to get its timestamp. We skip
	// events that don't have timestamps (although it seems
	// most do anyway).
	for {
		event, err := conn.ReadBinlogEvent()
		if err != nil {
			return 0, fmt.Errorf("error reading binlog event %v: %v", filename, err)
		}
		if !event.IsValid() {
			return 0, fmt.Errorf("first event from binlog %v is not valid", filename)
		}
		if ts := event.Timestamp(); ts > 0 {
			return int64(ts), nil
		}
	}
}

// Close closes the binlog connection, which also signals an ongoing dump
// started with StartBinlogDump() to stop and close its BinlogEvent channel.
// The ID for the binlog connection is recycled back into the pool.
func (bc *BinlogConnection) Close() {
	if bc.Conn != nil {
		log.Info("closing binlog socket to unblock reads")
		bc.Conn.Close()

View on GitHub (pinned to 01a25a7d17)

Solutions

Inspect the wrapped error: connection-closed implies retry/reconnect; protocol/packet errors imply binlog corruption.
If corruption is suspected, run mysqlbinlog --verify-binlog-checksum on the named file on the primary.
Reconnect and let findFileBeforeTimestamp continue with the next (older) candidate file if the current one is unusable.
Remove proxies from the replication path or configure them to pass raw TCP unchanged for replication connections.

Defensive patterns

Strategy: fallback

Validate before calling

// on the primary: verify the candidate file before streaming it
// mysqlbinlog --verify-binlog-checksum /var/lib/mysql/binlog.000123

Try / catch

if err != nil && strings.Contains(err.Error(), "error reading binlog event") {
	// treat as unreadable file: skip to next older binlog or re-sync via backup
}

Prevention

Monitor disk health on primaries to prevent binlog corruption.
Never hand-copy binlog files with rsync/cp; use proper backup tooling.
Keep Vitess and MySQL protocol versions compatible.
Alert on server-side disconnects during replication.

When it happens

Trigger: getBinlogTimeStamp (via findFileBeforeTimestamp → StartBinlogDumpFromBinlogBeforeTimestamp) reads a corrupted/truncated binlog file, the server disconnects mid-event, or the packet stream is garbled by a proxy.

Common situations: Corrupted binlogs after a primary crash or disk issue; binlog files partially purged on disk; intervening proxies mangling raw replication protocol; MySQL killed mid-dump.

Related errors

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/0ff01b34076fe24a. Report an issue: GitHub.