vitessio/vitess · error

Log file number is zero, cannot detect previous file

Error message

Log file number is zero, cannot detect previous file

What it means

BinlogCoordinates.PreviousFileCoordinatesBy guesses the previous binlog/relaylog file by decrementing the file number in the coordinate's log file name. If the current file number is 0 there is no earlier file to compute, so it returns this error.

Source

Thrown at go/vt/vtorc/inst/binlog.go:137

// Example: FileNumber() of mysqld.log.000789 is (789, 6)
func (binlogCoordinates *BinlogCoordinates) FileNumber() (int, int) {
	tokens := strings.Split(binlogCoordinates.LogFile, ".")
	numPart := tokens[len(tokens)-1]
	numLen := len(numPart)
	fileNum, err := strconv.Atoi(numPart)
	if err != nil {
		return 0, 0
	}
	return fileNum, numLen
}

// PreviousFileCoordinatesBy guesses the filename of the previous binlog/relaylog, by given offset (number of files back)
func (binlogCoordinates *BinlogCoordinates) PreviousFileCoordinatesBy(offset int) (BinlogCoordinates, error) {
	result := BinlogCoordinates{LogPos: 0, Type: binlogCoordinates.Type}

	fileNum, numLen := binlogCoordinates.FileNumber()
	if fileNum == 0 {
		return result, errors.New("Log file number is zero, cannot detect previous file")
	}
	newNumStr := strconv.Itoa((fileNum - offset))
	newNumStr = strings.Repeat("0", numLen-len(newNumStr)) + newNumStr

	tokens := strings.Split(binlogCoordinates.LogFile, ".")
	tokens[len(tokens)-1] = newNumStr
	result.LogFile = strings.Join(tokens, ".")
	return result, nil
}

// PreviousFileCoordinates guesses the filename of the previous binlog/relaylog
func (binlogCoordinates *BinlogCoordinates) PreviousFileCoordinates() (BinlogCoordinates, error) {
	return binlogCoordinates.PreviousFileCoordinatesBy(1)
}

// PreviousFileCoordinates guesses the filename of the previous binlog/relaylog
func (binlogCoordinates *BinlogCoordinates) NextFileCoordinates() (BinlogCoordinates, error) {
	result := BinlogCoordinates{LogPos: 0, Type: binlogCoordinates.Type}

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Guard the call: skip previous-coordinate computation when the file number is 0 and use the current coordinates directly
2. Advance/rotate the binlog so a previous file exists, or obtain coordinates another way (SHOW BINARY LOG STATUS)
3. Validate the LogFile name is well-formed (e.g. mysql-bin.000002) before computing previous coordinates

Example fix

// before
prev, err := coords.PreviousFileCoordinates()
// after
if fileNum, _ := coords.FileNumber(); fileNum == 0 {
    prev = coords // no previous file exists
} else {
    prev, err = coords.PreviousFileCoordinates()
}

if fileNum, _ := coords.FileNumber(); fileNum == 0 {
    return coords, nil // no previous file exists
}
prev, err := coords.PreviousFileCoordinates()

When it happens

Trigger: Calling PreviousFileCoordinates (which delegates to PreviousFileCoordinatesBy) on coordinates whose log file name has number 000001 (FileNumber()==0 in its internal representation), e.g. the very first binlog file.

Common situations: Failover/topology code (vtorc) computing previous coordinates for a server whose binlog is still at the first file, or parsing a malformed log file name that yields file number 0.

Related errors

• ParseBinlogCoordinates: Cannot parse BinlogCoordinates from
• ParseBinlogCoordinates: invalid pos: %s
• GetPreviousGTIDs: previous GTIDs not found
• syslog is not supported on windows
• ReadTopologyInstance(%+v): %+v

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