Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
5.5.33
-
None
-
Debian squeeze
Description
Since the release of the version 5.5.33 yesterday I have upgraded 3 different servers and they all broke the same aria table. The servers started to crash on first call to that table and I see [ERROR] mysqld: Incorrect information in file in the servers logs.
In order to recover I had to move the table files and recreate the table.
I'm attaching the problematic frm file that is causing the crash.
The table definition is: CREATE TABLE `man_logs` ( |
`LOG_ID` bigint(32) unsigned NOT NULL AUTO_INCREMENT, |
`USER_ID` int(11) DEFAULT NULL, |
`LOG_TIME` datetime NOT NULL DEFAULT '0000-00-00 00:00:00', |
`ACTION` varchar(255) DEFAULT NULL, |
`IP_ADDRESS` varchar(25) DEFAULT NULL, |
`DESCR` varchar(255) DEFAULT NULL, |
`MEM` blob,
|
`SUCCES` int(11) DEFAULT NULL, |
`OBJ_ID` int(11) DEFAULT NULL, |
`OBJ_TYPE` varchar(50) DEFAULT NULL, |
`REF_ID` int(11) DEFAULT NULL, |
`EXEC_TIME` decimal(18,9) DEFAULT NULL, |
`ENDPOINT` varchar(255) DEFAULT NULL, |
PRIMARY KEY (`LOG_ID`), |
KEY `LOG_TIME` (`LOG_TIME`), |
KEY `OBJ_TYPE` (`OBJ_TYPE`,`OBJ_ID`), |
KEY `MAN_LOGS_EXEC_TIME` (`EXEC_TIME`) |
) ENGINE=Aria AUTO_INCREMENT=12000983 DEFAULT CHARSET=utf8 PAGE_CHECKSUM=1 TRANSACTIONAL=1 |
On my test servers I didn't experience that behavior so I cannot recreate the issue, except on the production servers.
The table was upgraded from myisam to aria and then to transactional aria.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
Activity
Yes. The issue is the same as #MDEV-5029. The 4th byte was 0x2b and when I change it to 0x2a mariadb starts ok.
Does this mean that I have to edit .frm file before the upgrade?
Or should I wait for 5.5.34 release? Will 5.5.34 fix the file on startup?
5.5.34 will open these files normally, but it won't rewrite .frm files.
And yes, we do plan to release it very soon, you don't need to edit your frm files manually 
Please, check if your issue is the same as in
MDEV-5029