vitessio/vitess · error

unsupported type: %d, position: %d

Error message

unsupported type: %d, position: %d

What it means

vstreamer maps each MySQL column type code from the binlog TableMap event to a Vitess sqltypes type. When MySQLToType cannot translate a numeric type code, the column cannot be decoded and the table plan build fails. This guards against decoding rows with types Vitess does not understand.

Source

Thrown at go/vt/vttablet/tabletserver/vstreamer/vstreamer.go:1023

		FieldEvent: &binlogdatapb.FieldEvent{
			TableName: plan.Table.Name,
			Fields:    plan.fields(),
			Keyspace:  vs.vse.keyspace,
			Shard:     vs.vse.shard,
			// This mapping will be done, if needed, in the vstreamer when we process
			// and build ROW events.
			EnumSetStringValues: len(plan.EnumSetValuesMap) > 0,
		},
	}, nil
}

func (vs *vstreamer) buildTableColumns(tm *mysql.TableMap) ([]*querypb.Field, error) {
	var fields []*querypb.Field
	var txtFieldIdx int
	for i, typ := range tm.Types {
		t, err := sqltypes.MySQLToType(typ, 0)
		if err != nil {
			return nil, fmt.Errorf("unsupported type: %d, position: %d", typ, i)
		}
		// Use the collation inherited or the one specified explicitly for the
		// column if one was provided in the event's optional metadata (MySQL only
		// provides this for text based columns).
		var coll collations.ID
		switch {
		case sqltypes.IsText(t) && len(tm.ColumnCollationIDs) > txtFieldIdx:
			coll = tm.ColumnCollationIDs[txtFieldIdx]
			txtFieldIdx++
		case t == sqltypes.TypeJSON:
			// JSON is a blob at this (storage) layer -- vs the connection/query serving
			// layer which CollationForType seems primarily concerned about and JSON at
			// the response layer should be using utf-8 as that's the standard -- so we
			// should NOT use utf8mb4 as the collation in MySQL for a JSON column is
			// NULL, meaning there is not one (same as for int) and we should use binary.
			coll = collations.CollationBinaryID
		default: // Use the server defined default for the column's type
			coll = collations.CollationForType(t, vs.se.Environment().CollationEnv().DefaultConnectionCharset())

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Upgrade Vitess to a version that supports the column type reported in the error
2. Check the source server version and whether the column uses a new/unusual type
3. Reproduce the type with SHOW CREATE TABLE and consider altering the column to a supported type
4. Validate the binlog file with mysqlbinlog to rule out corruption

// Check source version vs Vitess support matrix before replicating:
// SELECT VERSION(); -- confirm all column types in tables are supported by your Vitess version

if strings.Contains(err.Error(), "unsupported type:") {
    // parse code/position from the error, map to the column via SHOW CREATE TABLE, plan an upgrade or ALTER
}

When it happens

Trigger: buildTableColumns iterates tm.Types; sqltypes.MySQLToType(typ, 0) returns an error for a type code at position i, producing this error with the code and column position.

Common situations: Replicating from a newer MySQL/MariaDB that introduced a column type the running Vitess doesn't know; corrupted TableMap type arrays; exotic column types or plugins.

Related errors

• unsupported constraint: %v
• can't parse binlog event: invalid data: %#v
• can't parse FORMAT_DESCRIPTION_EVENT: %v, event data: %#v
• got a real event before FORMAT_DESCRIPTION_EVENT: %#v
• can't strip checksum from binlog event: %v, event data: %#v

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