CopySchemaShard was not successful because the schemas betwe

Error message

CopySchemaShard was not successful because the schemas between the two tablets %v and %v differ: %v

What it means

Final verification of CopySchemaShard ran successfully but found real differences (diffs) between the source and destination schemas. This usually means MySQL silently skipped statements (e.g. CREATE DATABASE IF NOT EXISTS when the DB already existed with different options like charset/collation) or some CREATEs were applied inconsistently.

Source

Thrown at go/vt/wrangler/schema.go:261

	// Remember the replication position after all the above were applied.
	destPrimaryPos, err := wr.tmc.PrimaryPosition(ctx, destTabletInfo.Tablet)
	if err != nil {
		return fmt.Errorf("CopySchemaShard: can't get replication position after schema applied: %v", err)
	}

	// Although the copy was successful, we have to verify it to catch the case
	// where the database already existed on the destination, but with different
	// options e.g. a different character set.
	// In that case, MySQL would have skipped our CREATE DATABASE IF NOT EXISTS
	// statement.
	if !skipVerify {
		diffs, err = schematools.CompareSchemas(ctx, wr.ts, wr.tmc, sourceTabletAlias, destShardInfo.PrimaryAlias, tables, excludeTables, includeViews)
		if err != nil {
			return fmt.Errorf("CopySchemaShard failed because schemas could not be compared finally: %v", err)
		}
		if diffs != nil {
			return fmt.Errorf("CopySchemaShard was not successful because the schemas between the two tablets %v and %v differ: %v", sourceTabletAlias, destShardInfo.PrimaryAlias, diffs)
		}
	}

	// Notify Replicas to reload schema. This is best-effort.
	reloadCtx, cancel := context.WithTimeout(ctx, waitReplicasTimeout)
	defer cancel()
	resp, err := wr.VtctldServer().ReloadSchemaShard(reloadCtx, &vtctldatapb.ReloadSchemaShardRequest{
		Keyspace:       destKeyspace,
		Shard:          destShard,
		WaitPosition:   destPrimaryPos,
		Concurrency:    10,
		IncludePrimary: true,
	})
	if resp != nil {
		for _, e := range resp.Events {
			logutil.LogEvent(wr.Logger(), e)
		}
	}

View on GitHub (pinned to 01a25a7d17)

Solutions

Read the diffs in the error to identify mismatched objects.
Drop/recreate the differing tables or the database with the correct charset on the destination, then rerun CopySchemaShard.
Align database defaults (ALTER DATABASE ... CHARACTER SET/COLLATE) to match the source.

Example fix

// before (mismatched db charset)
CREATE DATABASE `vt_ks` CHARACTER SET latin1;
// after
DROP DATABASE `vt_ks`;
CREATE DATABASE `vt_ks` CHARACTER SET utf8mb4; -- match source

Defensive patterns

Strategy: validation

Validate before calling

diffs, err := schematools.CompareSchemas(ctx, ts, tmc, src, dst, tables, excl, incl)
if err == nil && diffs != nil {
    return fmt.Errorf("fix schema drift before copying: %v", diffs)
}

Try / catch

err := wr.CopySchemaShard(ctx, src, dst, tables, excl, false)
if err != nil && strings.Contains(err.Error(), "schemas between the two tablets") {
    // inspect diffs, drop/recreate mismatched objects, retry
}

Prevention

Keep database charsets/collations identical across shards.
Diff schemas proactively as part of reshard runbooks.
Never hand-edit schema on a single shard.

When it happens

Trigger: Destination database pre-existed with different charset/collation or tables differing from the source; the earlier create loop partially failed; includeViews/excludeTables choices cause differing table sets to be compared.

Common situations: Shard restored from an old backup; someone hand-edited schema on one shard; DB created manually with a different default character set than the source.

Related errors

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