milvus-io/milvus · critical

MetaStoreType %s not supported

Error message

MetaStoreType %s not supported

What it means

This panic comes from the Milvus mmap migration tool's root-coord catalog setup (cmd/tools/migration/mmap/tool/main.go:145). The tool's switch over the configured meta store backend only implements two cases, util.MetaStoreTypeEtcd ("etcd") and util.MetaStoreTypeTiKV ("tikv") (pkg/util/constant.go:31-32); any other value for metastore.type in the supplied milvus.yaml falls into default and aborts the tool before any migration runs.

Source

Thrown at cmd/tools/migration/mmap/tool/main.go:145

	case util.MetaStoreTypeEtcd:
		var metaKV kv.MetaKv
		var err error

		if metaKV, err = metaKVCreator(); err != nil {
			panic(err)
		}
		catalog = kvmetestore.NewCatalog(metaKV)
	case util.MetaStoreTypeTiKV:
		mlog.Info(ctx, "Using tikv as meta storage.")
		var metaKV kv.MetaKv
		var err error

		if metaKV, err = metaKVCreator(); err != nil {
			panic(err)
		}
		catalog = kvmetestore.NewCatalog(metaKV)
	default:
		panic(fmt.Sprintf("MetaStoreType %s not supported", paramtable.Get().MetaStoreCfg.MetaStoreType.GetValue()))
	}

	var meta rootcoord.IMetaTable
	if meta, err = rootcoord.NewMetaTable(ctx, catalog, allocator); err != nil {
		panic(err)
	}

	return meta, catalog
}

func prepareDataCoordCatalog() metastore.DataCoordCatalog {
	kv, err := metaKVCreator()
	if err != nil {
		panic(err)
	}
	return datacoord.NewCatalog(kv, "", "")
}

View on GitHub (pinned to b43a76673a)

Solutions

1. Set `metastore.type: etcd` (or `tikv`) under the correct `metastore:` key in the config file passed via -config, matching the backend your Milvus deployment actually uses
2. Verify the value is exactly the lowercase constant: grep the YAML for `metastore` and check nesting/indentation so the key is not silently ignored
3. Confirm the deployment really uses etcd or tikv as meta storage; if it uses another backend, this tool build cannot migrate it — use a matching tool version or migrate meta storage first
4. Check for unsubstituted env placeholders in templated configs before handing the file to the tool

Example fix

# before (milvus.yaml)
metastore:
  type: etcd3   # typo -> panic: MetaStoreType etcd3 not supported

# after
metastore:
  type: etcd

// Run before starting the mmap migration tool / equivalent switch over meta store type.
func validateMetaStoreType(yamlPath string) error {
    cfg, err := yaml.UnmarshalFile(yamlPath) // or use your config loader
    _ = cfg
    t := os.Getenv("META_STORE_TYPE") // or read from parsed yaml: metastore.type
    if t == "" {
        return fmt.Errorf("metastore.type is empty — set 'etcd' or 'tikv' in %s", yamlPath)
    }
    switch t {
    case "etcd", "tikv":
        return nil
    default:
        return fmt.Errorf("metastore.type %q not supported by this tool (use etcd or tikv)", t)
    }
}

When it happens

Trigger: Running the migration tool binary with -config pointing at a milvus.yaml whose `metastore.type` value is anything other than exactly "etcd" or "tikv" — e.g. an empty value from a mis-parsed YAML path, a typo like "etcd3"/"Etcd", a quoted env placeholder that never got substituted, or a backend constant this tool build does not support.

Common situations: YAML indentation mistake putting `type:` under the wrong parent so the key never lands in metastore; deploying with templated configs (helm values, ${META_STORE_TYPE} unsubstituted); running the tool against a Milvus deployment whose meta backend was compiled/configured differently from the tool's supported set; version skew between the migration tool and the milvus.yaml schema.

Related errors

• HTTP ${response.status}
• Empty payload received
• Failed to push config
• unexpected values type(%T) of fieldType %v
• index out of range

AI-assisted analysis of milvus-io/milvus@b43a76673a (2026-08-15). Data as JSON: /api/errors/1c7a20d99964d5b5. Report an issue: GitHub.