Kaputte MyISAM-Tabelle, unreparierbar ...

Ich habe hier eine kleine MyISAM-Tabelle, welche nach dem Update auf MySQL
5.1.19 einfach nur kaputt und nicht zugreifbar ist. Komischerweise laesst
sie sich auch auf keine mir bekannte Weise reparieren.

Mir kommt's nicht auf die Daten an - die habe ich noch im Backup -, ich
moechte einfach nur verstehen, was hier gerade schieflaeuft.

Primaeres Verhalten von MySQL ist dieses:

| mysql> desc addrs;
| ERROR 1034 (HY000): Incorrect key file for table 'addrs'; try to repair it

Aber im Einzelnen:

| # /etc/init.d/mysql stop
| Stopping MySQL database server: mysqld.
|
| # myisamchk --version
| myisamchk Ver 2.7 for pc-linux-gnu at i486
|
| # myisamchk --check -v addrs
| Checking MyISAM file: addrs
| Data records: 230 Deleted blocks: 0
| - check file-size
| - check record delete-chain
| No recordlinks
| - check key delete-chain
| block_size 1024:
| - check index reference
| - check data record references index: 1
| - check data record references index: 2
| - check record links
|
| # myisamchk --description -v addrs
|
| MyISAM file: addrs
| Record format: Packed
| Character set: latin1_swedish_ci (8)
| File-version: 1
| Creation time: 2001-01-06 16:51:32
| Recover time: 2007-08-30 8:03:37
| Status: checked,optimized keys
| Data records: 230 Deleted blocks: 0
| Datafile parts: 230 Deleted data: 0
| Datafile pointer (bytes): 4 Keyfile pointer (bytes): 4
| Datafile length: 21728 Keyfile length: 7168
| Max datafile length: 4294967294 Max keyfile length: 4398046510079
| Recordlength: 142
|
| table description:
| Key Start Len Index Type Rec/key Root Blocksize
| 1 7 4 multip. unsigned long 0 3072 1024
| 2 3 4 multip. unsigned long 0 6144 1024
|
| # myisamchk -r -v addrs
| - recovering (with sort) MyISAM-table 'addrs'
| Data records: 230
| - Fixing index 1
| - Searching for keys, allocating buffer for 1088 keys
| - Dumping 230 keys
| - Fixing index 2
| - Searching for keys, allocating buffer for 231 keys
| - Dumping 230 keys
|
| # ls -l addrs.*
| -rw-rw---- 1 mysql mysql 21728 Aug 30 10:07 addrs.MYD
| -rw-rw---- 1 mysql mysql 7168 Aug 30 10:07 addrs.MYI
| -rw-rw---- 1 mysql mysql 8922 Jan 6 2001 addrs.frm
|
| # /etc/init.d/mysql start
| Starting MySQL database server: mysqld.
| Checking for corrupt, not cleanly closed and upgrade needing tables..
|
| # mysql abi91
| Reading table information for completion of table and column names
| You can turn off this feature to get a quicker startup with -A
|
| Welcome to the MySQL monitor. Commands end with ; or \g.
| Your MySQL connection id is 7
| Server version: 5.1.19-beta-Debian_1-log Debian etch distribution
|
| Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
|
| mysql> desc addrs;
| ERROR 1034 (HY000): Incorrect key file for table 'addrs'; try to repair it
| mysql> repair table addrs \G
| *************************** 1. row ***************************
| Table: abi91.addrs
| Op: repair
| Msg_type: error
| Msg_text: Incorrect key file for table 'addrs'; try to repair it
| 1 row in set, 1 warning (0.00 sec)
|
| mysql> show table status like 'addrs' \G
| *************************** 1. row ***************************
| Name: addrs
| Engine: NULL
| Version: NULL
| Row_format: NULL
| Rows: NULL
| Avg_row_length: NULL
| Data_length: NULL
| Max_data_length: NULL
| Index_length: NULL
| Data_free: NULL
| Auto_increment: NULL
| Create_time: NULL
| Update_time: NULL
| Check_time: NULL
| Collation: NULL
| Checksum: NULL
| Create_options: NULL
| Comment: Incorrect key file for table 'addrs'; try to repair it
| 1 row in set (0.00 sec)

Es kann durchaus sein, dass die Tabelle schon zu 3.23-Tagen angelegt wurde,
kann ich leider nicht mehr nachvollziehen. Nur verwundert mich eben, dass
myisamchk (gehoert definitiv zur 5.1.19er Release, ist keine aeltere
Version) die Tabelle als einwandfrei ansieht, der mysqld aber nicht.
mysqlcheck hilft entsprechend auch nicht weiter (bei -r wieder das
"Incorrect key file ...").

Mich wuerde halt nur interessieren, was hier los sein koennte, fuer den Fall,
mal auf einem "richtigen" System auf sowas zu stossen ... Entsprechend waere
ich fuer Tips dankbar (und wenn es auch nur ein Verweis auf eine Bug-Nummer
oder ein "geht nicht" ist).

Re: Kaputte MyISAM-Tabelle, unreparierbar ...

Sven Paulus!

> Ich habe hier eine kleine MyISAM-Tabelle, welche nach dem Update auf MySQL
> 5.1.19 einfach nur kaputt und nicht zugreifbar ist. Komischerweise laesst
> sie sich auch auf keine mir bekannte Weise reparieren.
[..]
> | mysql> desc addrs;
> | ERROR 1034 (HY000): Incorrect key file for table 'addrs'; try to repair it

Der Fehler kann auch auftreten, wenn mysqld nicht auf die Platte schreiben
kann, z.B. weil sie voll ist, aber auch aus anderen Gründen. Kannst du
das ausschließen?

Wie sieht die my.cnf aus?


Grundsätzlich sollte sich sowas mit einem Dump der Tabelle mit der alten
Version und Import in der neuen lösen lassen. Besonders, wenn das Update
ein Upgrade auf eine andere Familie war. Der "creation time" entnehme ich
mal, dass diese Tabelle sowas noch nicht hinter sich hat.


Gruß
Daniel

Re: Kaputte MyISAM-Tabelle, unreparierbar ...

Daniel Fischer wrote:
> Der Fehler kann auch auftreten, wenn mysqld nicht auf die Platte schreib=
en
> kann, z.B. weil sie voll ist, aber auch aus anderen Gründen. Kannst=
du
> das ausschließen?

Ja, Permissions passen und Plattenplatz ist reichlich an, auch in
tmp-Verzeichnissen. Und r/o gemountet ist auch nichts. Ich denke, sonst
wuerde myisamchk auch meckern, der schreibt ja beim rebuilden temporaere
Dateien und benennt dann um. Ausserdem funktionieren andere Datenbanken am
gleichen Speicherort praechtig.

> Wie sieht die my.cnf aus?

Minimalst (die Kiste hat halt "so nebenbei" eine MySQL mitlaufen) und
voellig ungetuned, "vanilla" quasi:

| # egrep -v '^(#|$)' /etc/mysql/my.cnf=20
| [client]
| port =3D 3306
| socket =3D /var/run/mysqld/mysqld.sock
| [mysqld_safe]
| socket =3D /var/run/mysqld/mysqld.sock
| nice =3D 0
| [mysqld]
| user =3D mysql
| pid-file =3D /var/run/mysqld/mysqld.pid
| socket =3D /var/run/mysqld/mysqld.sock
| port =3D 3306
| basedir =3D /usr
| datadir =3D /var/lib/mysql
| tmpdir =3D /var/tmp
| language =3D /usr/share/mysql/english
| skip-external-locking
| bind-address =3D 127.0.0.1
| key_buffer =3D 32M
| max_allowed_packet =3D 32M
| thread_stack =3D 128K
| thread_cache_size =3D 8
| query_cache_limit =3D 1M
| query_cache_size =3D 16M
| log =3D /var/log/mysql/mysql.log
| log_slow_queries =3D /var/log/mysql/mysql-slow.log
| long_query_time =3D 1
| log-queries-not-using-indexes
| [mysqldump]
| quick
| quote-names
| max_allowed_packet =3D 16M
| [mysql]
| [isamchk]
| key_buffer =3D 16M

> Grundsätzlich sollte sich sowas mit einem Dump der Tabelle mit der =
alten
> Version und Import in der neuen lösen lassen. Besonders, wenn das U=
pdate
> ein Upgrade auf eine andere Familie war. Der "creation time" entnehme ic=
h
> mal, dass diese Tabelle sowas noch nicht hinter sich hat.

Hat sie bislang definitiv nicht. Aber im Grunde moechte ich derartige
dump-/restore-Orgien wenn moeglich auch vermeiden, bei produktiven
Datenbanken waeren's halt mal ein paar Millionen Zeilen und sowas dauert
dann irgendwas zwischen lang und ewig. Mich hat's nur verwundert, weil ich=
-
soweit ich mich erinnere - problemlos andere Tabellen von 3.23 (mit
Zwischenstufen) nach 5.1 mitgeschleppth habe und nur bei den vorgenannten
gibt's ploetzlich ein Problem, deswegen wuerde ich gerne dieses Problem
verstehen. Auf der gleichen Kiste sind andere Tabellen, die sogar noch
aelter sind und trotzdem funktionieren.

Ich hatte auch schon bei MySQL gesucht, aber auf Anhieb nichts gefunden,
welche MyISAM-Versionen in welchen Versionen eigentlich unterstuetzt werde=
n.

Wie bekomme ich denn eigentlich die Version einer MyISAM-Tabellenstruktur
raus? Klar, "SHOW TABLE STATUS" zeigt sie an ("Version"), aber soweit komm=
e
ich ja gar nicht, da kommen ja nur NULLen. "File-Version" bei "myisamchck
--description" scheint was anderes zu sein.