Overview of the Issue
When attempting to run PlannedReparentShard on a cluster with long-ish tablet aliases, it throws the following error:
failed: Data too long for column 'primary_alias' at row 1
From the logs, it's clear that the error is coming from
INSERT INTO _vt.reparent_journal (time_created_ns, action_name, primary_alias, replication_position) VALUES <redacted>
The current column definition is varbinary(32). It should be increased to varbinary(250) or even 255.
Reproduction Steps
Create a test vitess cluster with a tablet alias > 32 characters.
Attempt to PRS to that tablet.
Presumably this will also fail ERS (EmergencyReparentShard), but I haven't tried it.
Binary Version
Initially found with v15.0.3, but I've verified that every version is affected up to current `main`.
Operating System and Environment details
Log Fragments
No response
Overview of the Issue
When attempting to run PlannedReparentShard on a cluster with long-ish tablet aliases, it throws the following error:
From the logs, it's clear that the error is coming from
The current column definition is varbinary(32). It should be increased to varbinary(250) or even 255.
Reproduction Steps
Create a test vitess cluster with a tablet alias > 32 characters.
Attempt to PRS to that tablet.
Presumably this will also fail ERS (EmergencyReparentShard), but I haven't tried it.
Binary Version
Initially found with v15.0.3, but I've verified that every version is affected up to current `main`.Operating System and Environment details
Log Fragments
No response