vitessio/vitess · error

cannot determine database flavor details for version %s

Error message

cannot determine database flavor details for version %s

What it means

NeedInnoDBRedoLogSubdir formats the MySQL server version and asks mysql.ServerVersionCapableOf for the matching flavor capabilities. When no flavor matches the version string, this error is returned because Vitess cannot decide whether InnoDB redo-log handling applies. It guards version-specific backup behavior against unknown or unsupported MySQL flavors.

Source

Thrown at go/vt/mysqlctl/blackbox/utils.go:168

// NeedInnoDBRedoLogSubdir indicates whether we need to create a redo log subdirectory.
// Starting with MySQL 8.0.30, the InnoDB redo logs are stored in a subdirectory of the
// <innodb_log_group_home_dir> (<datadir>/. by default) called "#innodb_redo". See:
//
//	https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log.html#innodb-modifying-redo-log-capacity
func NeedInnoDBRedoLogSubdir() (needIt bool, err error) {
	mysqldVersionStr, err := mysqlctl.GetVersionString()
	if err != nil {
		return needIt, err
	}
	_, sv, err := mysqlctl.ParseVersionString(mysqldVersionStr)
	if err != nil {
		return needIt, err
	}
	versionStr := fmt.Sprintf("%d.%d.%d", sv.Major, sv.Minor, sv.Patch)
	capableOf := mysql.ServerVersionCapableOf(versionStr)
	if capableOf == nil {
		return needIt, fmt.Errorf("cannot determine database flavor details for version %s", versionStr)
	}
	return capableOf(capabilities.DynamicRedoLogCapacityFlavorCapability)
}

const MysqlShutdownTimeout = 1 * time.Minute

func SetBuiltinBackupMysqldDeadline(t time.Duration) time.Duration {
	old := mysqlctl.BuiltinBackupMysqldTimeout
	mysqlctl.BuiltinBackupMysqldTimeout = t

	return old
}

func createBackupDir(root string, dirs ...string) error {
	for _, dir := range dirs {
		if err := os.MkdirAll(path.Join(root, dir), 0o755); err != nil {
			return err
		}

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Print the actual mysqld version (`mysqld --version`) and confirm it is a flavor/Version CapableOf supports.
2. Check mysql.ServerVersionCapableOf mappings for the version you run; upgrade Vitess if the flavor is newer than supported.
3. Force the expected flavor/version by fixing the mysqld binary or container image used by mysqlctl.
4. If you maintain a fork, add the missing flavor capability mapping for your version.

sv, err := mysql.GetVersionStringCapabilities(versionString)
if err != nil || mysql.ServerVersionCapableOf(versionString) == nil {
	return fmt.Errorf("unsupported MySQL flavor/version: %s", versionString)
}

needIt, err := utils.NeedInnoDBRedoLogSubdir(ctx, cnf)
if err != nil {
	return fmt.Errorf("redo log capability check failed (check mysqld version/flavor): %w", err)
}

When it happens

Trigger: During backup/restore (SetupCluster, TestExecuteBackup*) the connected mysqld reports a version for which ServerVersionCapableOf returns nil — e.g. a MariaDB version, an unsupported MySQL 8.x point release, or a version parsed as 0.0.0 because version detection failed.

Common situations: Pointing Vitess at MariaDB or Percona when only MySQL flavors are mapped; custom MySQL builds reporting unusual version strings; mysqld version string not parseable so Major/Minor/Patch are zero.

Related errors

• mysqld >= 8.0.21 required to disable the redo log
• running MySQL version %q is newer than backup MySQL version
• running MySQL version %q is older than backup MySQL version
• running MySQL version %q is too new for backup MySQL version
• cannot use backup between different flavors: %q vs. %q

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