 |
Thank you for reporting this problem. The matter is, both Object.id and TagTree.id are unique because each is a primary key, therefore the compound keys are always unique. It is unfortunate that MySQL has lost the ability to verify this relation automatically. Anyway, could you provide the steps to reproduce the problem? Which OS and MySQL version did you use? |
 |
I was using bash-5.1$ mysql --version mysql Ver 9.1.0 for Linux on x86_64 (MySQL Community Server - GPL) running on bash-5.1$ cat /etc/redhat-release Red Hat Enterprise Linux release 9.4 (Plow) and restoring a dump of racktables 0.21.5 There is a pull request to fix the bug: https://github.com/RackTables/racktables/pull/291 |
|
|
Another issue: when using a mysql cluster, it complains: ERROR: The following tables do not have a Primary Key or equivalent column: racktables_db.IPv4LB 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. 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" The solution: ALTER TABLE IPv4LB DROP INDEX `LB-VS`, ADD PRIMARY KEY (`object_id`, `vs_id`); |
- Anonymous
