If the mysqld server is stopped, you should use the
--update-state option to tell myisamchk to mark the table as “checked.”
Stage 2: Easy safe repair
First, try myisamchk -r -q tbl_name
-r -q means “quick recovery mode”). This attempts to repair the index file without touching the data file. If the data file contains everything that it should and the delete links point at the correct locations within the data file, this should work, and the table is fixed. Start repairing the next table. Otherwise, use the following procedure:
Make a backup of the data file before continuing.
If the preceding step fails, use myisamchk --safe-recover tbl_name. Safe recovery mode uses an old recovery method that handles a few cases that regular recovery mode does not (but is slower).
Stage 3: Difficult repair
You should reach this stage only if the first 16KB block in the index file is destroyed or contains incorrect information, or if the index file is missing. In this case, it is necessary to create a new index file. Do so as follows:
Move the data file to a safe place.
Use the table description file to create new (empty) data and index files:
Copy the old data file back onto the newly created data file. (Do not just move the old file back onto the new file. You want to retain a copy in case something goes wrong.)
If you are using replication, you should stop it prior to performing the above procedure, since it involves filesystem operations, and these are not logged by MySQL.
You can also use the
REPAIR TABLE SQL statement, which performs the whole procedure automatically. There is also no possibility of unwanted interaction between a utility and the server, because the server does all the work when you use
Syntax”REPAIR TABLE. See Section 188.8.131.52, “REPAIR TABLE.
Stage 4: Very difficult repair
You should reach this stage only if the
.frm description file has also crashed. That should never happen, because the description file is not changed after the table is created:
If you do not have a backup but know exactly how the table was created, create a copy of the table in another database. Remove the new data file, and then move the
.MYIindex files from the other database to your crashed database. This gives you new description and index files, but leaves the
.MYDdata file alone. Go back to Stage 2 and attempt to reconstruct the index file.