Details
-
New Feature
-
Status: Confirmed (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
Table will encounter rebuild during minor version upgrade if contains hashing index on TEXT type unique key
The old long hashing function had a bug (MDEV-27653) which will allow duplicate key. After the fix is merged, all tables contains long hashing indexes needs to be rebuilt when upgrading to the versions (10.11.2, 10.4.28, 10.5.19, 10.6.12, 10.7.8, 10.8.7, 10.9.5, 10.10.3 ) contain the fix, no matter it's major version upgrade or minor version upgrade
This kind of unexpected table rebuild sometimes will make minor version upgrade takes even longer than the major version upgrade. For a case we encountered, table rebuild took almost 10 days to rebuild a 73 GB table.
Method to reproduce:
- Create a 10.4 22 instance
- Create a table contains the hashing unique key
CREATE TABLE `test` (
|
`id` bigint(20) NOT NULL AUTO_INCREMENT, |
`fakeCol1` bigint(20) NOT NULL, |
`fakeCol2` text NOT NULL,
|
PRIMARY KEY (`id`),
|
UNIQUE KEY `fakeKey` (`fakeCol1`,`fakeCol2`) USING HASH
|
) ENGINE=InnoDB
|
- Insert some data to the table
INSERT INTO test (fakeCol1, fakeCol2) VALUES ('12345678','qwertyuiopasdfghjklzxcvbnm');
INSERT INTO test (fakeCol1, fakeCol2) VALUES ('12345679','qwertyuiopasdfghjklzxcvbnm');
INSERT INTO test (fakeCol1, fakeCol2) VALUES ('12345680','qwertyuiopasdfghjklzxcvbnm');
- Upgrade instance to 10.6.11 (Table rebuild won't happen)
- Upgrade instance to 10.6.19 (Table rebuild will happen)
Ask
- Can the community make changes to skip this kind of table rebuild during minor version upgrade if it's caused by a bug from community ?
- If a table rebuilt is required, can the community make changes to only rebuild the problematic part, not the whole table during the minor version upgrade(in this case, the hashing index on TEXT type unique key)?
Attachments
Issue Links
- is caused by
-
MDEV-27653 long uniques don't work with unicode collations
- Closed
- relates to
-
MDEV-371 Unique indexes for blobs
- Closed