Twitter this

Powered by MariaDB Powered by nginx ...

MariaDB – ERROR 130 (HY000): Incorrect file format

We have had an issue the last 2 days with a table that apeared corrupt. Selecting from this table returns an error all the sudden. Since upgrading to MariaDB 5.2 a few weeks ago we had this twice. So far only moderated panic applies. I've never seen this since the start of this project which is almost 5 years now and only since this upgrade. I couldn't find any Maria related bugs using google nor the bugtracker. Could this one be new ? We are planning an 64bit upgrade soon so I'm wondering if this would eliminate this from happening after that. Hope is a better word.

Moderately busy runtime table stopped working

- Problem turned out to be a DB error.
- ERROR 130 (HY000): Incorrect file format
- Worked fine for weeks. No reports of corruption in Error logs so far on these.

Platform

- running 5.2.8-MariaDB-mariadb102 - debian-linux-gnu on i486
- 32bit (mem/64bit upgrade in process of waiting for hardware)
- Signal 11 problem we have since MySql 5.1. Coredumps not configured in kernel so we can only guess at this point.
- Not very busy (cpu use is very low on average)

Symptoms of the problem

- The tables seem to stop functioning all the sudden, repair doesn't work.
- show create doesn't work but truncate table does recreate it correctly(?)
- happened twice in 2 days (among a pack of ~ 150 similar tables in design and functionality)
- lots of updates
- few inserts
- about 40 records per table on average
- Problem only apeared after switching over to MariaDB 5.2
- Last time the database came down with Signal 11 when hitting it hard with repairs.

1
2
MariaDB [traceme]> SHOW CREATE TABLE LastSeen_h;
ERROR 130 (HY000): Incorrect file format 'LastSeen_h'

Schema
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE TABLE `LastSeen_h` (
  `imei` bigint(20) NOT NULL,
  `lastComms` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `eventDate` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `eventState` int(10) UNSIGNED DEFAULT NULL,
  `eventLon` int(10) UNSIGNED NOT NULL,
  `eventLat` int(10) UNSIGNED NOT NULL,
  `eventDelta` time NOT NULL,
  `eventRecordid` int(10) UNSIGNED DEFAULT NULL,
  `eventIO` int(10) UNSIGNED DEFAULT NULL,
  `eventSwitch` int(10) UNSIGNED DEFAULT NULL,
  `lastDate` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `lastState` int(10) UNSIGNED DEFAULT NULL,
  `lastLon` int(10) UNSIGNED NOT NULL,
  `lastLat` int(10) UNSIGNED NOT NULL,
  `lastRecordid` int(10) UNSIGNED DEFAULT NULL,
  `lastIO` int(10) UNSIGNED DEFAULT NULL,
  `lastSwitch` int(10) UNSIGNED DEFAULT NULL,
  PRIMARY KEY (`imei`),
  KEY `Index_date1` (`imei`,`lastComms`),
  KEY `Index_date2` (`imei`,`eventDate`)
) ENGINE=Aria DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1

Solution (none so far)

- We have no real solution so far but to drop/create the table. We are lucky as this data is being cached in sqlite so we just reimport and the customers are back online. We do not have this happen on tables that do a lot of inserts. We have other aria tables that are very important to us with severely processed data (takes a lot of time to recreate those).
- truncate works too but I find this weird since 'show create table' doesn't. I prefer to drop it first (which works too) and create it again.

Anyone else have this since using MariaDB 5.2?

- We only had this happen twice but my gut feeling is that something is up with Aria. (I've upgraded this server from MariaDB 5.1). This went fine at the time. Since then we have restored this DB from backups except 'mysql' database which we ended up fixing and cleaning first but those are Isam so I don't think they matter.
- I love to hear if anyone has the same experience.

Comments are closed.

recruitment
recruitment
recruitment
recruitment