Fixes #2105 - database tables can't be created on MySQL >= 8.4 because KEY is not unique

[ntavares]

Quote:

When using MySQL 8.4 or higher, there are a few tables that can't be created because a Key is not unique and there is a foreign key that references it, and from MySQL 8.4 it's not allowed to reference non-unique KEYs.

the keys that are bad (not UNIQUE) are:
Object.id-tid
TagTree.id-is_assignable

The fix:
ALTER TABLE Object DROP KEY `id-tid`, ADD UNIQUE KEY `id-tid` (`id`,`objtype_id`);
ALTER TABLE TagTree DROP KEY `id-is_assignable`, ADD UNIQUE KEY `id-is_assignable` (`id`,`is_assignable`);

Additional info: https://bugs.mysql.com/bug.php?id=114838

[ntavares]

I've added an additional commit as we've came across another issue at restoring an old MySQL backup onto MySQL 8.4. These changes are non-breaking.

Group Replication requires tables to use InnoDB and have a PRIMARY KEY or PRIMARY KEY Equivalent (non-null unique key). Tables that do not follow these requirements will be readable but not updateable when used with Group Replication. If your applications make updates (INSERT, UPDATE or DELETE) to these tables, ensure they use the InnoDB storage engine and have a PRIMARY KEY or PRIMARY KEY Equivalent.

Ref: https://dev.mysql.com/doc/refman/8.4/en/group-replication-requirements.html

If you can't change the tables structure to include an extra visible key to be used as PRIMARY KEY, you can make use of the INVISIBLE COLUMN feature available since 8.0.23: https://dev.mysql.com/doc/refman/en/invisible-columns.html

@infrastation I was going to patch upgrade.php as well, but there's no slot for the "next version" and I don't know what's the release plan. If that changes, or you suggest the "next version" to add to, I'd be happy to provide that as well.

[infrastation]

The second change does not look right, let me have some time to verify that. Let's solve one problem at a time.

upgrade.php now has a section for the next release, which is going to be 0.21.1. One issue with the proposed change is that it does not state the problem correctly. As I mentioned in the bug report, the keys have been unique for a very long time. The loss of capability in MySQL to recognise unique keys as such is a new thing and is the problem.

[ntavares]

@infrastation thank you for the followup. A bit of context: while migrating from MySQL 5.x single server to MySQL 8(.4) HA setup, the database dump will not load. Both commits are related to that - that could well be the title of #2105 - I'm not sure how you'd like it to be rephrased... We did not run the install.php, but considering the timing of the error (upon CREATE TABLE) I expect Racktables to not install on MySQL 8.4 in its current form.

PS: Despite me running cardinality tests against IPv4LB, I only now realised our tables are empty - we don't use that funcionality... I've only changed it to PRIMARY KEY to get rid of the warnings while being able to reuse the index but if you need the NULLs then we'll have to use the "invisible PK" for this to suceed - therefore adding to the table rather than reusing that index.

Thanks for the additions in upgrade.php, I'll add them later, depending on your verification of the above.

[ntavares]

Hi, just to add that we just verified a fresh install.php with these patches, racktables-0.22.0 and mysql-9.1, all went well.