The error indicates an invalid collation-tailoring rule that tries to reset before a secondary ignorable character, preventing MySQL from loading or using the collation.
MySQL Error 91: EE_FAILED_TO_RESET_BEFORE_SECONDARY_IGNORABLE_CHAR surfaces when a custom collation rule resets before a secondary ignorable character, making the rule illegal. Fix it by editing or dropping the faulty collation, then reload or recreate it with valid Unicode Collation Algorithm syntax.
Failed to reset before a secondary ignorable character %s. EE_FAILED_TO_RESET_BEFORE_SECONDARY_IGNORABLE_CHAR was added in 8.0.16.
MySQL raises error code 91 with the message “Failed to reset before a secondary ignorable character” when it parses a collation rule that breaks Unicode Collation Algorithm (UCA) guidelines. The offending rule tries to start a reset sequence on a character whose primary weight is ignorable, which is disallowed.
The problem appears during server start, CREATE COLLATION, ALTER DATABASE … COLLATE, or any query that implicitly loads the customized collation.
MySQL 8.0.16 introduced the specific error constant EE_FAILED_TO_RESET_BEFORE_SECONDARY_IGNORABLE_CHAR to clarify the failure.
An illegal reset reference is the direct cause. UCA resets must target a character with a non-zero primary weight. When a rule references a secondary ignorable character (weight 0 at the primary level), MySQL stops parsing and throws error 91.
The error often arrives after manual edits to the ICU collation XML file or a CREATE COLLATION statement that includes a faulty TAILORING clause.
Upgrades can also surface latent issues because stricter validation began in 8.0.16.
Identify the failing collation with SHOW COLLATION or by reading the error log. Remove or correct the illegal rule so the reset target has a valid primary weight. Alternatively, drop the custom collation and fall back to a built-in one.
After editing, restart MySQL or run ALTER INSTANCE RELOAD DICTIONARY to reload metadata.
Always test the collation with SELECT 'x' COLLATE your_collation to confirm the server starts and queries succeed.
Server will not start: Comment out the faulty collation in the ICU XML, start the server, then patch and re-import the collation.
CREATE COLLATION fails: Revise the TAILORING clause, ensuring every reset symbol (&) references a character with a primary weight.
Upgrade failure: Run mysqlcheck --check-upgrade after updating.
It pinpoints schemas that depend on invalid collations so you can fix them before reopening traffic.
Adopt built-in collations when possible, because they are fully validated. When custom rules are needed, validate them with the ICU collation tailoring tool before loading them into MySQL.
Version-control every XML tailoring file. Test upgrades in staging with sql_mode='STRICT' and log_error_verbosity=3 so collation issues surface early.
Galaxy’s fast editor makes these dry-runs quick and shareable across your team.
EE_CANTOPEN_COLLATION: MySQL cannot locate the collation file. Check file paths and permissions.
EE_COLLATION_INVALID_WEIGHT: A rule assigns an impossible weight. Fix the numeric weight or remove the rule.
ER_CANT_SET_COLLATION: The specified collation is not permitted for the character set. Verify compatibility and retry.
.
MySQL 8.0.16 added stricter validation and the specific error code. Collations that previously loaded now fail because they violate UCA rules.
No. The server rejects the entire collation, which can block startup or any query that references it. Fix or drop the collation.
Yes. Built-in collations are prevalidated and cannot contain illegal resets, so the error disappears.
Galaxy surfaces MySQL startup and query logs in its editor, lets teams review faulty SQL together, and share corrected CREATE COLLATION statements, reducing repeat mistakes.
.avif)
.avif){kind=logo}
