[MDEV-4024] Found Index PRIMARY whose column info does not match that of MySQL Created: 2013-01-11 Updated: 2014-01-06 Resolved: 2013-11-01 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 10.0.1, 5.5.30, 5.3.12 |
| Fix Version/s: | 10.0.5 |
| Type: | Bug | Priority: | Major |
| Reporter: | Gordan Bobic | Assignee: | Sergei Golubchik |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux (RHEL6) |
||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Description |
| Comments |
| Comment by Elena Stepanova [ 2013-01-11 ] | |
|
Hi Gordan, Did you (or anybody who has enough access) do any ALTER table since the upgrade?
Thanks. | |
| Comment by Gordan Bobic [ 2013-01-11 ] | |
|
Definitely no ALTER TABLE statements since the upgrade. An example of the create table has been uploaded, file name is I have tried to fix the problem doing ALTER TABLE ... REBUILD PARTITION ... and that seems to make the problem go away for a particular partition, at least for a time, but I could have sworn that a table on which I had rebuilt the partitions had appeared with that error in the logs again afterwards. Several different versions were upgraded from, all 5.5.x. At least the following three (multiple servers): I am using MariaDB-10.0.0 RHEL6/CentOS6 binary rpms from the MariaDB rpm repository. Regarding XtraDB/plugin - we were using whatever the defaults for Percona's MySQL 5.5. On 5.6, however, I don't think XtraDB/plugin would have been included since that wasn't a Percona version. I did notice that 5.6 uses InnoDB version 1.2.6 and MariaDB 10 uses 1.2.0, so I originally attributed the error in the log to that, but that doesn't explain the same problem manifesting on 5.5.x upgraded to MariaDB. | |
| Comment by Elena Stepanova [ 2013-01-11 ] | |
|
Gordan, | |
| Comment by Gordan Bobic [ 2013-01-11 ] | |
|
Marvellous, thank you. If you could please provide some feedback regarding the potential for actual data corruption as a consequence of this issue, that would be most appreciated. | |
| Comment by Elena Stepanova [ 2013-01-12 ] | |
|
I cannot say for sure whether data corruption is possible due to this problem, as I'm not an expert at internals; as far as I can tell, in this particular place nothing critical should happen as the types are just compared there; but I suppose that conversion might fail somewhere else due to the same broken mapping. Anyway, I've updated the description and am passing it over to Monty now, who I'm sure will be able to answer at once. I've set the tentative fix version to 10.0.1 – although it's very close to the release at the moment, I hope the fix will be primitive and fast; if not, it will probably go to 10.0.2. | |
| Comment by Sergei Golubchik [ 2013-04-04 ] | |
|
This unintentional difference between XtraDB and InnoDB was introduced in 5.3. Your test case should show these warnings even in 5.3. I'm not sure what I can do about it, fixing XtraDB in 5.3 to match InnoDB or vice versa will, again, create a similar incompatibility between pre-fix XtraDB (or InnoDB, whichever we fix) tables and post-fix tables. Besides, it seems that the warning is not dangerous, it looks like no data corruption is possible, despite the warning. | |
| Comment by Jan Lindström (Inactive) [ 2013-07-29 ] | |
|
Inside a InnoDB the data is not corrupted. But what happens when you query is not fully known to me, if data type in MySQL and InnoDB are not exactly the same that could lead to data truncation, rounding, etc. Similarly, if you insert/update using MySQL data types and they are then incorrectly resolved to InnoDB data types similar could happen. Why both XtraDB and InnoDB use the same storage engine name ? R: Jan | |
| Comment by Jan Lindström (Inactive) [ 2013-07-29 ] | |
|
Fundamental issue here is that when you do create table a(date primary key) engine=innodb; It is not 100% clear is this table using Oracle innodb implementation of Percona XtraDB innodb implementation or soon create table a(data primary key) engine=xtradb; // Percona innodb If you try to access table b but you only have engine a available it should give you nice understandable error message. | |
| Comment by Jan Lindström (Inactive) [ 2013-07-29 ] | |
|
Based on code reading we have type #define DATA_FIXBINARY 3 /* binary string of fixed length / and type #define DATA_INT 6 / integer: can be any size 1 - 8 bytes */. I could not get any incorrect results from simple test. Actual message is harmless, innodb just does not create translation table. | |
| Comment by Jan Lindström (Inactive) [ 2013-07-29 ] | |
|
Reason for this is that XtraDB has: if (field->real_type() == MYSQL_TYPE_ENUM
While InnoDB has very different implementation, this: case HA_KEYTYPE_BINARY: return(DATA_FIXBINARY); Thus, the different data types on dictionary. This is a bug. | |
| Comment by Jan Lindström (Inactive) [ 2013-07-30 ] | |
|
I have now quite confident that this is what happens: If table is created using XtraDB InnoDB the used type is DATA_INT and that type is also used when values are stored when innodb plugin is used. Only thing that the server notes is that MySQL data dictionary and InnoDB data dictionary are not sync. Conversion between MySQL and InnoDB is done based on InnoDB dictionary. If table is created using innodb plugin the used type is FIXBINARY and again same type is used with XtraDB. We can easily fix the code so that all new created tables will use in innodb plugin DATA_INT, we may not change the existing tables, that is not safe because DATA_INT and FIXBINARY uses different storage format. | |
| Comment by Jeremy Cole [ 2013-10-30 ] | |
|
We found this bug during upgrade. Please see attached a patch for the bug. However, fixing it is not quite as trivial as restoring the correct behavior. Each table affected must be adjusted back to the correct type/value. This could be done by the user (using ALTER TABLE ... ENGINE=InnoDB) or a patch could be made to automatically adjust this type (without copying any data) on e.g. table open. I would find it rather irresponsible to leave this bug in MariaDB. Aside from its disabling the index translation table and generating complaintive log messages, it has a reasonably high chance of causing future more severe breakage if InnoDB changes its behavior and suddenly starts failing to understand ENUM/SET data in DATA_FIXBINARY columns. The fix is in theory quite simple (an InnoDB data dictionary fixup one time per table) – it should be done sooner rather than later. The commit message from my patch follows, since it contains a reasonably complete explanation: Use correct InnoDB storage type for 1-byte ENUM and SET In MariaDB 5.3, the get_innobase_type_from_mysql_type function was This InnoDB internal data type difference makes upgrades from older Query results should be unaffected by this bug, because the on-disk This change additionally sorts the get_innobase_type_from_mysql_type (Note that some errors in revisions 2661.777.35 and 2661.777.47 were fixed See the Bazaar revisions on Launchpad: | |
| Comment by Jeremy Cole [ 2013-10-30 ] | |
|
Note that the patch contributed here (innodb_1byte_data_int.patch.txt) is given under the New BSD License. | |
| Comment by Jeremy Cole [ 2013-11-01 ] | |
|
What's the fix? | |
| Comment by Sergei Golubchik [ 2013-11-02 ] | |
|
http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3874 | |
| Comment by Jeremy Cole [ 2013-11-06 ] | |
|
That is not really an adequate fix, IMHO. Also, why strip out useful explanatory comments about these special cases that I provided in my patch? Additionally, this bug also affects YEAR type which is internally stored as TINYINT UNSIGNED equivalent. |