Bug #17329 Tables get corrupted (errors 127 and 134)
Submitted: 12 Feb 2006 9:10 Modified: 14 Sep 2014 19:29
Reporter: Martin Spasov Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:5.0.18, 5.5.38 OS:Linux (Linux x86_64)
Assigned to: CPU Architecture:Any
Tags: corruption, myisam

[12 Feb 2006 9:10] Martin Spasov
Description:
We have migrated a production server to 5.0.18 from a 4.1.x, and almost instant there was a table corruption(134 and 127). After a while we found that the concurrent insert feature causes most of them. Disabling concurrent insert stopped the corruption (or just minimised it - now it's 2-3 times a day _only_). I get even corrupted temp tables (t).

The server has about 2,000 connections, 60 myisam tables, running from 1500 to 3000 qps.
Data and temp partition is running on reiserfs (noatime, notail mount options).

The server runs precompiled binary distribution (emt 64, icc).

How to repeat:
We were unable to isolate this issue on a non-production server (10-20 qps), still trying.
[12 Feb 2006 9:21] Valeriy Kravchuk
Thank you for a problem report. Please, describe your upgrade procedure. Did you perform mysqldump in 4.x.y and restore in 5.0.18, as reccommended, or just installed new binaries over old data?
[12 Feb 2006 9:27] Martin Spasov
Full dump, than restore. After initial corruption we stopped all clients and did full repair from console (repair table...). I got more corrupted tables, so I repaired again, dumped (from 5.0.18) and reimported the database. Than we found that the concurrent insert is causing troubles.
[12 Feb 2006 9:31] Martin Spasov
This is rescent mysqld error log, 2-3 corruptions/24h.

Attachment: mysql-err.log (text/x-log), 4.55 KiB.

[12 Feb 2006 10:06] Valeriy Kravchuk
Please, send the SHOW CREATE TABLE results for tables that are usually corrupted. Your my.cnf file content will be also useful.
[12 Feb 2006 10:22] Martin Spasov
SHOW TABLE STATUS
| tr_country         | MyISAM |      10 | Dynamic    | 1425449 |             29 |    42741064 |    281474976710655 |     32163840 |        40 |           NULL | 2006-02-08 17:13:01 | 2006-02-12 11:53:59 | 2006-02-12 00:46:46 | cp1251_general_ci   |     NULL |                |                           |

SHOW CREATE TABLE tr_country
 CREATE TABLE `tr_country` (
  `trid` int(11) NOT NULL default '0',
  `countryid` int(11) NOT NULL default '0',
  `completed_by` varchar(255) NOT NULL default '',
  `times_completed` int(10) unsigned NOT NULL default '0',
  `ls` int(10) unsigned NOT NULL default '0',
  `sd` int(10) unsigned NOT NULL default '0',
  `visible` enum('yes','no') NOT NULL default 'yes',
  `downloaded` bigint(20) unsigned NOT NULL default '0',
  `uploaded` bigint(20) unsigned NOT NULL default '0',
  PRIMARY KEY  (`trid`,`countryid`),
  KEY `visible` (`visible`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251

cat /etc/mysql/my.cnf |egrep -v ^#

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /old-sql/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/english
skip-external-locking
default-character-set=cp1251

old-passwords   = 1
key_buffer              = 64M
max_allowed_packet      = 16M
thread_stack            = 128K
thread_cache            = 1024
table_cache             = 8096
query_cache_limit      = 1048576
query_cache_size        = 26214400
query_cache_type        = 1
set-variable = wait-timeout=15
set-variable = concurrent_insert=0
set-variable = delay-key-write=OFF
ft_min_word_len=3
set-variable=max_connections=4096
set-variable=wait_timeout=15
set-variable=max_tmp_tables=512
myisam_sort_buffer_size = 64M
skip-innodb

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]

[isamchk]
ft_min_word_len = 3
key_buffer              = 16M

daemon started with:
# ./bin/safe_mysqld --user=mysql --open-files=65535 --log-error=/var/log/mysql/mysql.err --skip-name-resolve --myisam-recover
[15 Feb 2006 12:50] Martin Spasov
Ok, after some tweaking i have found that the problem is in the delayed_key_write=all variable. I have disabled this and everything seems to be fine (no more corrupted tables). Here is what I did:
 use tr;
Database changed
mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired

>Meanwhile the error log is empty - no errors reported. I have few (100-200) threads that are using this table. I have repaired the table few seconds later:

mysql> repair table tr_country;
+---------------------------+--------+----------+----------+
| Table                     | Op     | Msg_type | Msg_text |
+---------------------------+--------+----------+----------+
| tr.tr_country             | repair | status   | OK       |
+---------------------------+--------+----------+----------+
1 row in set (7.73 sec)

>It seems everything is ok. Now let's alter again (10 seconds after the repair said ok I hit this):

mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired

>Seems that repair does not work ?! Is this the issue here? Let's try again with extended options appended:

mysql> repair table tr_country extended;
+---------------------------+--------+----------+----------+
| Table                     | Op     | Msg_type | Msg_text |
+---------------------------+--------+----------+----------+
| tr.tr_country             | repair | status   | OK       |
+---------------------------+--------+----------+----------+
1 row in set (14.37 sec)

mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired

>I'm getting nervous.. Trying to solve the problem blindly...

mysql> flush tables;
Query OK, 0 rows affected (1.92 sec)

mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired
mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired
mysql> repair table tr_country;
+---------------------------+--------+----------+----------+
| Table                     | Op     | Msg_type | Msg_text |
+---------------------------+--------+----------+----------+
| tr.tr_country             | repair | status   | OK       |
+---------------------------+--------+----------+----------+
1 row in set (5.01 sec)

mysql> ALTER TABLE `tr_country` DROP completed_by;
ERROR 1194 (HY000): Table 'tr_country' is marked as crashed and should be repaired

Doesn't work. So let's try to disable the delay_key_write options:

mysql> set global delay_key_write=off;
Query OK, 0 rows affected (0.00 sec)

mysql> flush tables;
Query OK, 0 rows affected (0.29 sec)

mysql> repair table tr_country;
+---------------------------+--------+----------+----------+
| Table                     | Op     | Msg_type | Msg_text |
+---------------------------+--------+----------+----------+
| tr.tr_country             | repair | status   | OK       |
+---------------------------+--------+----------+----------+
1 row in set (5.03 sec)

mysql> ALTER TABLE `tr_country` DROP completed_by;
Query OK, 1435759 rows affected (19.24 sec)
Records: 1435759  Duplicates: 0  Warnings: 0

It's done. I left delayed_key_write off and the server is working ok. I have reported a bug (overflow) which may be connected to this one - 17328
[1 Mar 2006 15:08] Valeriy Kravchuk
Sorry, but you had delay_key_write=off by default according to your my.cnf content, or I misinterpreted it? Moreover, you had not set DELAY_KEY_WRITE for that particular table... Anyway, can you try to repeat with a copy of that table and onl one session, trying to perform ALTER. Please, do and inform about the results.
[1 Mar 2006 15:21] Martin Spasov
We have enabled this on the fly (by seting the global variable to "all", then flushing tables and threads), that's why this was not in the config file.

I'll try to reproduce the problem described in the last post on a non-production machine.
[2 Mar 2006 11:07] Valeriy Kravchuk
Please, do and inform about the results.
[2 Apr 2006 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[6 Apr 2006 13:41] Vygintas Krasauskas
I have found this bug page while I was searching for a problem solution:
several big (1-5 GB) MyISAM tables get often corrupted on my MySQL 5 (5.0.19) server. All of them have DELAY_KEY_WRITE=1.

It mostly happens when some big/heavy query is running, eg. data transformation/loading using INSERT INTO ..... SELECT FROM. Sometimes (rarely) the whole server crashes but mostly a table gets broken after such operation is done. The error message mostly says "Incorrect key file for table ...." so no data is lost, but it takes long until index is repaired.

Few hours ago one index file got corrupted after I have started an UPDATE query and then have killed it after it took 2-3 minutes.

Now I will try to disable DELAY_KEY_WRITE for all tables.
[18 Mar 2010 14:21] Jerry Champlin
Yesterday we experienced this issue in a production environment on 5.0.33 and a test environment on 5.1.36.  Both databases reside on servers running CentOS 5.2.

5.1.36 error:
100316 21:15:09 [ERROR] /opt/mysql/libexec/mysqld: Table './log_loader_caches/malog' is marked as crashed and should be repaired

5.0.33 error:
100314 18:02:39 [ERROR] /opt/mysql-5.0.33/libexec/mysqld: Table './data_loader_caches/madata_18' is marked as crashed and last (automatic?) repair failed

Both tables are MyISAM tables.  The 5.0.33 table is a merge table.

After altering the tables to set DELAY_KEY_WRITE=0 the crashes have stopped.  I will post an update if the problem happens with DELAY_KEY_WRITE turned off.
[5 Aug 2014 16:33] Michael Brunnbauer
Had index crashes with 5.5.38 on heavily used tables with DELAY_KEY_WRITE=1 and full text indices. It seems that setting DELAY_KEY_WRITE=0 stopped the errors.
[14 Aug 2014 19:29] Sveta Smirnova
Michael,

thank you for the feedback.

We were not able to repeat this issue internally. Please upload to our FTP server files of problematic table compressed. Please also check if you parallel queries to the same table when doing alter.
[15 Sep 2014 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".