MySQL Bugs: #35606: REPAIR TABLE `...` will cause corrputed *.frm file

Bug #35606	REPAIR TABLE `...` will cause corrputed *.frm file
Submitted:	27 Mar 2008 13:57	Modified:	7 Apr 2008 14:56
Reporter:	Christian Meisinger	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S2 (Serious)
Version:	5.1.23-ndb-6.3.10-telco	OS:	Linux (SuSE 9.3)
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	corrupt, frm, Repair

Description:
I've upgraded from MySQL 5.0.45 to 5.1.23-ndb-6.3.10-telco. No dump and import.
I compiled MySQL from source.
Then i used mysql_upgrade.
No problems.
Afterwards i tried repairing a table with REPAIR TABLE ``; -> will corrupt its *.frm file.
Before REPAIR TABLE the table was ok, it was just a test.

How to repeat:
Compile and install MySQL 5.0.45 from source.
Copy projects_notes table with projects_notes.frm.original.
Compile and upgrade it with 5.1.23-ndb-6.3.10-telco.
REPAIR TABLE `projects_notes`;
-> table invalid.
i've attached my invalid *.frm file too so you can compare then.

projects_notes MYI, MYD and both frm files

Attachment: projects_notes.zip (application/zip, text), 2.88 KiB.

Christian,

many thanks for writing a bug report.
I can't reproduce this by using newest 5.0 and 5.1 sources and will try to reproduce it with the same versions that you used.

My first check was an encoding check and I figured out that you don't have encoding problems in your databases.

Christian,

many thanks for writing a bug report.
Unfortunately I can't repeat this:

I installed MySQL 5.0.45 from source (compiled it)
Also I installed MySQL 5.1.23-ndb-6.3.10-telco from source.

I made a mysql_install_db for MySQL 5.0.45 to get a data directory.

I copied your data into my MySQL 5.0.45 data directory (/MYPATH/var/mydb/projects_notes*).

I started MySQL 5.0.45 and opened the CLI for looking if your table is in my database. All were fine.

Now I copied the data directory from MySQL 5.0.45 to MySQL 5.1.23-ndb-6.3.10-telco.

I started the daemon with ./libexec/mysqld --defaults-path=/MYPATH/my.cnf

The daemon suggested to make a mysql_upgrade first.

I made: ./bin/mysql_upgrade

all works fine ... I started CLI:

mysql> select * from projects_notes;
lots of results ... looks good

mysql> repair table projects_notes;
+------------------------+--------+----------+----------+
| Table                  | Op     | Msg_type | Msg_text |
+------------------------+--------+----------+----------+
| miracee.projects_notes | repair | status   | OK       | 
+------------------------+--------+----------+----------+

looks good too, but:

mysql> select * from projects_notes;
Server crash with Signal 6

I opened a new bug #35708 and will make a deeper analysation.

Christian,

I made some more tests here. This only occurs with 5.1.23-ndb-6.3.10-telco.
A workaround for you could be:
Download our 5.1.23-rc source release tree instead of this telco tree.
All will work fine with the 5.1.23-rc version that you can download from:

http://dev.mysql.com/downloads/mysql/5.1.html

I tested here by compiling from source tree.

Set to cluster because this only occurs on 5.1.23-ndb-6.3.10-telco.

Duplicate of bug#35708

There is one more possible fix. 

This issue can happen if innodb is disabled  i.e.  inside my.cnf you can see an entry as "skip-innodb ". You can delete this entry  .. This shall fix the issue.