ParseBinlogCoordinates: Cannot parse BinlogCoordinates from

Error message

ParseBinlogCoordinates: Cannot parse BinlogCoordinates from %s. Expected format is file:pos

What it means

vtorc's inst.ParseBinlogCoordinates expects a string of the form 'file:pos' (e.g. 'mysql-bin.000001:12345'). If the input has no colon-delimited second token, parsing fails with this error. It is used to convert replication position strings into BinlogCoordinates structs.

Source

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

const (
	BinaryLog BinlogType = iota
	RelayLog
)

// BinlogCoordinates described binary log coordinates in the form of log file & log position.
type BinlogCoordinates struct {
	LogFile string
	LogPos  uint64
	Type    BinlogType
}

// ParseBinlogCoordinates will parse a string representation such as "mysql-bin.000001:12345"
// into a BinlogCoordinates struct.
func ParseBinlogCoordinates(logFileLogPos string) (*BinlogCoordinates, error) {
	tokens := strings.SplitN(logFileLogPos, ":", 2)
	if len(tokens) != 2 {
		return nil, fmt.Errorf("ParseBinlogCoordinates: Cannot parse BinlogCoordinates from %s. Expected format is file:pos", logFileLogPos)
	}

	logPos, err := strconv.ParseUint(tokens[1], 10, 64)
	if err != nil {
		return nil, fmt.Errorf("ParseBinlogCoordinates: invalid pos: %s", tokens[1])
	}
	return &BinlogCoordinates{LogFile: tokens[0], LogPos: logPos}, nil
}

// DisplayString returns a user-friendly string representation of these coordinates
func (binlogCoordinates *BinlogCoordinates) DisplayString() string {
	return fmt.Sprintf("%s:%d", binlogCoordinates.LogFile, binlogCoordinates.LogPos)
}

// String returns a user-friendly string representation of these coordinates
func (binlogCoordinates BinlogCoordinates) String() string {
	return binlogCoordinates.DisplayString()
}

View on GitHub (pinned to 01a25a7d17)

Solutions

Ensure the input is exactly 'binlog-file:position' with a non-empty file name and integer position
Check where the string originates (ShowMasterStatus/ShowSlaveStatus field mapping) and fix column ordering
Handle empty positions before calling: return early if the source string is blank
If the topology uses GTID replication, use the GTID-aware position APIs instead of binlog coordinates

Example fix

// before
coords, err := inst.ParseBinlogCoordinates("mysql-bin.000001")
// after
coords, err := inst.ParseBinlogCoordinates("mysql-bin.000001:4711")

Defensive patterns

Strategy: validation

Validate before calling

func validBinlogCoords(s string) bool {
    parts := strings.SplitN(s, ":", 2)
    if len(parts) != 2 || parts[0] == "" || parts[1] == "" {
        return false
    }
    _, err := strconv.ParseUint(parts[1], 10, 64)
    return err == nil
}

Try / catch

if !validBinlogCoords(raw) {
    return fmt.Errorf("skipping invalid coordinates %q", raw)
}
coords, err := inst.ParseBinlogCoordinates(raw)
if err != nil { return err }

Prevention

Always format positions as file:pos with strconv before passing in
Never pass GTID sets or bare file names into ParseBinlogCoordinates
Trim and normalize strings scraped from shell output before parsing
Unit-test coordinate parsing with real SHOW status output formats

When it happens

Trigger: Calling ParseBinlogCoordinates (via getBinlogCoordinatesFromPositionString) with a string lacking a colon, e.g. an empty string, a bare binlog file name 'mysql-bin.000001', or a GTID set instead of file:pos coordinates.

Common situations: Feeding SHOW MASTER STATUS output columns in the wrong order, passing an empty ExecMasterPosition from a server that never replicated, or mixing GTID-based positions into file:pos-based code paths.

Related errors

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