A sudden power outage on the server resulted in data file corruption. Force shutdown without shutting down the MySQL service first, etc.
Analysis of causes of table damage
The following reasons are common causes of mysql table corruption:
1. The server suddenly loses power, causing data files to be damaged.
2. Force shutdown without closing the mysql service first.
3. The mysqld process is killed when writing tables.
4. While using myisamchk, mysqld is also operating the table.
5. Disk failure.
6. The server crashes.
7. Bugs in mysql itself.
Symptoms of table damage
Typical symptoms of a corrupted table are as follows:
1. When selecting data from the table, you get the following error:
Incorrect key file for table: '…'. Try to repair it
2. The query cannot find rows in the table or returns incomplete data.
3. Error: Table 'p' is marked as crashed and should be repaired.
4. Failed to open table: Can't open file: '×××.MYI' (errno: 145).
Prevent MySQL table corruption
You can use the following methods to prevent mysql table damage:
1. Regularly use myisamchk to check the MyISAM table (note that mysqld must be closed). It is recommended to use check table to check the table (without closing mysqld).
2. After a large number of update or delete operations, it is recommended to use OPTIMIZE TABLE to optimize the table, which not only reduces file fragmentation but also reduces the probability of table damage.
3. Before shutting down the server, shut down mysqld first (shut down the service normally, do not use kill -9 to kill the process).
4. Use UPS power supply to avoid sudden power outage.
5. Use the latest stable release version of mysql to reduce table damage caused by bugs in mysql itself.
6. For the InnoDB engine, you can use innodb_tablespace_monitor to check the integrity of file space management within the table space file.
7. RAID the disk to reduce disk errors and improve performance.
8. It is best for the database server to only run mysqld and other necessary services, and not to run other business services. This will reduce the possibility of table damage caused by a crash.
9. Don’t be afraid of any eventuality, just be afraid of accidents. Making regular backups is an effective way to prevent table damage.
MySQL table damage repair
MyISAM tables can be repaired using the following steps:
1. Use reapair table or myisamchk to repair.
2. If the above method is not effective, use backup to restore the table.
Specifically, you can refer to the following methods:
Stage 1: Check your table
If you have a lot of time, run myisamchk *.MYI or myisamchk -e *.MYI . Use the -s (silent) option to suppress unnecessary messages.
If the mysqld server is down, the --update-state option should be used to tell myisamchk to mark the table as checked.
You must repair only those tables for which myisamchk reports errors. For such tables, proceed to stage 2.
If while checking, you get strange errors (such as out of memory errors), or if myisamchk crashes, go to stage 3.
Phase 2: Simple and safe fix
Note: If you want to fix it faster, you should set the sort_buffer_size and Key_buffer_size variables to approximately 25% of the available memory when running myisamchk.
First, try myisamchk -r -q tbl_name (-r -q means "quick recovery mode"). This will attempt to repair the index files without touching the data files. If the data file contains everything it should and a delete link pointing to the correct location within the data file, this should work and the table can be repaired. Start repairing the next table. Otherwise, perform the following procedure:
Make a backup of your data files before continuing.
Use myisamchk -r tbl_name (-r means recovery mode). This will remove incorrect and deleted records from the data files and rebuild the index files.
If the previous steps fail, use myisamchk --safe-recover tbl_name . Safe recovery mode uses an older recovery method that handles the few cases where regular recovery mode doesn't work (but is slower).
If while repairing, you get strange errors (such as out of memory errors), or if myisamchk crashes, go to stage 3.
Phase 3: Difficult Repair
You should only get to this stage if the first 16K blocks of the index file are corrupted, or contain incorrect information, or if the index file is missing. In this case, a new index file needs to be created. Follow these steps:
Move data files to a safe location.
Create new (empty) data files and index files using the table description file:
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
If your version of MySQL does not have TRUNCATE TABLE, use DELETE FROM tbl_name.
Copy the old data file to the newly created data file. (Don't just move the old file back into the new one; you want to keep a copy in case something goes wrong.)
Back to stage 2. Now myisamchk -r -q should work. (This shouldn't be an infinite loop).
You can also use REPAIR TABLE tbl_name USE_FRM which will automatically execute the entire program.
Stage 4: Very difficult repair
You should only reach this stage if the .frm description file is also corrupted. This should never happen because the description file never changes after the table is created.
Restore the profile from a backup and then go back to stage 3. You can also restore the index files and go back to stage 2. For the latter, you should start it with myisamchk -r.
If you don't have a backup but know exactly how the table was created, create a copy of the table in another database. Delete the new data files and move the description files and index files from the other database to the corrupted database. This provides new description and index files, but leaves the .MYD data files alone. Go back to stage 2 and try to rebuild the index file.
InnoDB tables can be repaired using the following methods:
If the database pages are corrupted, you may want to use SELECT INTO OUTFILE to dump your table from the database; usually most of the data obtained this way is intact. Even so, corruption could cause SELECT * FROM tbl_name or InnoDB background operations to crash or assert, or even crash InnoDB rollforward recovery.
However, you can use it to force the InnoDB storage engine to start and prevent background operations from running so that you can dump your tables. For example, you can add the following line to the [mysqld] section of the options file before restarting the server:
[mysqld]
innodb_force_recovery = 4
The allowed non-zero values for innodb_force_recovery are as follows. A larger number encompasses all the precautions of a smaller number. If you can dump your table with an option value that's mostly 4, then you're relatively safe and only some data on the corrupted individual pages will be lost. A value of 6 is more exaggerated because database pages are left in a stale state, which in turn can cause more damage to B-trees and other database structures.
innodb_force_recovery
1 (SRV_FORCE_IGNORE_CORRUPT)
Leave the server running even if it detects a corrupted page; try having SELECT * FROM tbl_name skip corrupted index records and pages, which can help dump the table.
2 (SRV_FORCE_NO_BACKGROUND)
prevents the main thread from running, which will prevent a crash if it could occur during a purge operation.
3 (SRV_FORCE_NO_TRX_UNDO)
Do not run transaction rollback after recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
also prevents insert buffer merge operations. If you might cause a crash. It is best not to do these operations and not to calculate table statistics.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Do not check the unfinished log when starting the database: InnoDB treats unfinished transactions as committed.
6 (SRV_FORCE_NO_LOG_REDO)
Do not roll forward the log in the recovery connection.
The database cannot otherwise be used with any of these options allowed. As a security measure, InnoDB prevents users from performing INSERT, UPDATE, or DELETE operations when innodb_force_recovery is set to a value greater than 0.
Even if forced recovery is used, you can DROP or CREATE the table. If you know that a given table is causing rollback crashes, you can remove it. You can also use this to stop uncontrolled rollbacks caused by a failed bulk import or a failed ALTER TABLE. You can kill the mysqld process, then set innodb_force_recovery to 3 so that the database is suspended without rollback, and then discard the table that caused the uncontrolled rollback.