database table ' content

Table ' Content_tags ' is marked as crashed and should are repaired

Such a mistake

Problem Analysis:
This prompt indicates that the '%s ' table is damaged and may have been caused by an abnormal shutdown and need to be repaired.
Workaround:
REPAIR TABLE ' <span style= ' font-family:arial, Helvetica, Sans-serif; >content_tags</span> '

You can also use Myisamchk to fix it.

The initial estimate may be that when the index is rebuilt, in addition to the problem,

At this point, solve the problem!

PS: Some other issues to collect
Phase 1: Check your watch

If you have a lot of time, run Myisamchk *. Myi or MYISAMCHK-E *. Myi. Use the-S (silence) option to prohibit unnecessary information.

If the MYSQLD server is down, use the--update-state option to tell Myisamchk to mark the table as ' checked '.

You have to fix only those tables where the MYISAMCHK report errors. For such a table, continue to stage 2.

If in check, you get strange errors (such as out of memory error), or if Myisamchk crashes, to Stage 3.

Phase 2: Simple and secure repair

Note: If you want to repair faster, you should set the value of the sort_buffer_size and key_buffer_size variables to about 25% of the available memory when you run MYISAMCHK.

First, try Myisamchk-r-Q tbl_name (-r-q means "quick recovery mode"). This will attempt to repair the index file without touching the data file. This should work if the data file contains everything it should and a delete connection to the correct location in the data file, and the table can be repaired. Begin to repair the next table. Otherwise, perform the following procedures:

Back up the data file before continuing.

Using Myisamchk-r tbl_name (-R means "recovery mode"). This deletes the incorrect records and deleted records from the data file and rebuilds the index files.

If the previous step fails, use Myisamchk--safe-recover tbl_name. The security recovery model uses an old recovery method to handle a small number of cases (but more slowly) that do not work with the normal recovery model.

If you get a strange error (for example out of memory error), or if the myisamchk crashes, to Stage 3.

Stage 3: Difficult fixes

Only the first 16K block of the index file is corrupted, or contains incorrect information, or if the index file is lost, you should be at this stage. In this case, you need to create a new index file. Do the following steps:

Move the data file to a safe place.

To create a new (empty) data file and index file by using a table description file:

shell> MySQL db_name

Mysql> SET autocommit=1;

mysql> TRUNCATE TABLE tbl_name;

Mysql> quit

If your MySQL version has no truncate TABLE, use the delete from Tbl_name.

Copy old data files to the newly created data file. (Don't just move old files back into new files; you need to keep a copy in case something goes wrong.) ）

Back to Stage 2. Now Myisamchk-r-Q should be working. (This should not be an infinite loop).

You can also use the repair TABLE tbl_name use_frm to automatically execute the entire program.

Stage 4: Very difficult to repair

only. frm The description file is destroyed, you should get to this stage. This should never have happened because the description file does not change after the table is created.

Restore the description file from one backup and then back to Phase 3. You can also recover the index file and then return to Stage 2. For the latter, you should start 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 file and move the profile and index files from other databases to the corrupted database. This provides a new description and index file, but lets. The myd data file was left alone. Go back to Stage 2 and try to rebuild the index file.

The InnoDB table can be repaired in the following ways:

If the database page is corrupted, you may want to dump your table from the database using SELECT INTO OutFile, and most of the data obtained in this way is intact. Even so, corruption can cause a select * from Tbl_name or InnoDB background operation to crash or assert, or even make the InnoDB roll back crash. However, you can use it to force the InnoDB storage engine to start and prevent the background operation 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 = 4innodb_force_recovery the allowable 0 values are as follows. A larger number contains preventive measures of all smaller numbers. If you can dump your table with an option value that is mostly 4, you are safe, and only some of the data on the corrupted individual page is lost. A value of 6 is exaggerated because the database page is left in a stale state, which in turn can cause more damage to the B-tree and other database structures. &NBSP
1 (srv_force_ignore_corrupt)  
If the server detects a corrupted page and lets the server run; try to have the select * from tbl_name skip corrupted index records and pages. This helps to dump the table.

2 (srv_force_no_background) &NBSP
blocks the main thread from running, which will block if the crash may occur during the purge operation. &NBSP
3 (srv_force_no_trx_undo)  
does not run a transaction rollback after recovery. &NBSP
4 (srv_force_no_ibuf_merge)  
also blocks the insertion of a buffer merge operation. If you could cause a crash. It is best not to do these operations, do not calculate table tables.
5 (Srv_force_no_undo_log_scan)  
starts the database without viewing the unfinished log: InnoDB treats the unfinished transaction as committed. &NBSP
6 (Srv_force_no_log_redo)  
Do not roll the log forward in the recovery connection. &NBSP
The database cannot be used separately with the options allowed in these options. As a security measure, when Innodb_force_recovery is set to a value greater than 0, InnoDB prevents the user from performing an insert, UPDATE, or delete operation.  
Even if forced recovery is used, you can drop or CREATE table. If you know that a given table is causing a rollback crash, you can remove it. You can also use this to stop runaway rollback caused by failed bulk imports or failed alter TABLE. You can kill the MYSQLD process and set the Innodb_force_recovery to 3, leaving the database suspended without the need to roll back, and then discarding the table that caused the runaway rollback.