Database Table 'content _ tags'... shocould be rewritable red Table corruption

Table 'content _ tags' is marked as crashed and shoshould be retried red

Such errors

Problem Analysis:
This prompt indicates that the '% s' table is corrupted and may be caused by an abnormal shutdown. you need to fix it.
Solution:
Repair table '<span style = "font-family: Arial, Helvetica, sans-serif;"> content_tags </span>'

You can also use myisamchk to fix the issue.

The preliminary estimation may be caused by the index reconstruction, except for the problem,

Now, the problem is solved!

PS: collect other questions
Phase 1: Check your table

If you have a lot of time, run myisamchk *. MYI or myisamchk-e *. MYI. Use the-s (SILENCE) option to disable unnecessary information.

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

You must fix only tables with errors reported by myisamchk. For such a table, continue to Stage 2.

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

Phase 2: simple and secure repair

Note: If you want to fix it faster, you should set the values of the sort_buffer_size and Key_buffer_size variables to about 25% of the available memory when running myisamchk.

First, try myisamchk-r-q tbl_name (-r-q means "quick recovery mode "). This will try to repair the index file without contacting the data file. If the data file contains everything it should have and the deletion link pointing to the correct location in the data file, this should work and the table can be repaired. Start to repair the next table. Otherwise, execute the following process:

Back up data files before continuing.

Use myisamchk-r tbl_name (-r means "recovery mode "). This will delete incorrect records and deleted records from the data file and recreate the index file.

If the previous step fails, use myisamchk -- safe-recover tbl_name. The security recovery mode uses an old recovery method to handle a few cases (but slower) where the conventional recovery mode does not work ).

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

Phase 3: difficult repairs

Only when the first 16 K block of the index file is damaged, 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. Perform the following operations:

Move data files to a safe place.

Create a new (empty) data file and index file using the table description file:

Shell> mysql db_name

Mysql> set autocommit = 1;

Mysql> truncate table tbl_name;

Mysql> quit

If your MySQL version does not have a truncate table, delete from tbl_name is used.

Copy the old data file to the newly created data file. (Do not just move the old file back to the new file; keep a copy to prevent some errors .)

Return to Stage 2. Now myisamchk-r-q should work. (This should not be an infinite loop ).

You can also use repair table tbl_name USE_FRM to automatically execute the entire program.

Phase 4: very difficult repairs

Only when the. frm description file is damaged should you reach this stage. This should never happen, because after the table is created, the description file will not change.

Recover the description file from a backup and return to phase 3. You can also restore the index file and return to phase 2. For the latter, you should start with myisamchk-r.

If you do not have a backup, but you know exactly how the table is created, create a copy of the table in another database. Delete the new data file and move the description file and index file from other databases to the damaged database. This provides a new description and index file, but leaves the. MYD data file alone. Go back to Stage 2 and try to recreate the index file.

The InnoDB table can be repaired using the following methods:

If the database page is damaged, you may want to use select into outfile to dump your table from the database. Generally, most of the data obtained in this way is intact. Even so, the damage may cause the SELECT * FROM tbl_name or InnoDB background operation to crash or assert, or even cause the InnoDB roll-back recovery to crash. 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 lines in the [mysqld] section of the Option file before restarting the server:
[Mysqld] innodb_force_recovery = 4innodb_force_recovery the following non-zero values are allowed. A larger number contains all smaller numbers. If you can use an option value of 4 to dump your table, you are safe, and only some data on damaged individual pages will be lost. A value of 6 is even more exaggerated because the database page is left in an old state, which in turn can cause more damage to the B tree and other database structures.
1 (srv_force_ignore_0000upt)
Even if the server detects a corrupted page, it also causes the server to run. Try to let SELECT * FROM tbl_name skip the damaged index records and pages, which will help dump the table.

2 (SRV_FORCE_NO_BACKGROUND)
Prevents the main thread from running. If the crash may occur during the cleaning operation, this will block it.
3 (SRV_FORCE_NO_TRX_UNDO)
Do not run transaction rollback after recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
It also prevents insert buffer merge operations. If you may cause a crash. We recommend that you do not perform these operations or calculate statistical tables.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
When starting the database, do not view unfinished logs: InnoDB regards unfinished transactions as committed.
6 (SRV_FORCE_NO_LOG_REDO)
Do not roll logs before restoring the connection.
The database cannot be used with the allowed options in these options. As a security measure, when innodb_force_recovery is set to a value greater than 0, InnoDB prevents users from performing INSERT, UPDATE, or DELETE operations.
Even if force recovery is used, you can DROP or CREATE a table. If you know that a given table is causing a rollback crash, you can remove it. You can also use this to stop the out-of-control rollback caused by failed large imports or failed ALTER tables. You can kill the mysqld process and set innodb_force_recovery to 3, so that the database is suspended and does not need to be rolled back. Then, you can discard the tables that lead to out-of-control rollback.