解决数据库 TABLE 'CONTENT_TAGS' IS MARKED A

解决数据库 TABLE 'CONTENT_TAGS' IS MARKED AS CRASHED AND SHOULD BE REPAIRED 表损坏问题

今天突然网站的TAG页面打不开，打开debug，找到提示
Table 'content_tags' is marked as crashed and should be repaired
  这样的错误

问题分析：
        出现这个提示，说明'%s'表损坏，可能是非正常关机造成的，需要修复。

解决方案：
REPAIR TABLE `content_tags`
也可以用 myisamchk 修复。

初步估计可能是除了索引重建时的问题，

至此，问题解决了！

PS：还有一些问题需要收集
第一阶段：检查你的桌子
如果您有很多时间，请运行 myisamchk *.MYI 或 myisamchk -e *.MYI 。使用 -s（静默）选项来抑制不必要的信息。


如果 mysqld 服务器已关闭，应使用 --update-state 选项告诉 myisamchk 将表标记为“已检查”。


您必须只修复 myisamchk 报告有错误的那些表。对于这样的表，继续第 2 阶段。


如果在检查时遇到奇怪的错误（例如内存不足错误），或者如果 myisamchk 崩溃，请转到第 3 阶段。


第 2 阶段：简单安全的修复


注意：为了更快地修复，您应该在运行 myisamchk 时将 sort_buffer_size 和 Key_buffer_size 变量的值设置为可用内存的大约 25%。


首先，尝试 myisamchk -r -q tbl_name（-r -q 表示“快速恢复模式”）。这将尝试在不接触数据文件的情况下修复索引文件。如果数据文件包含它应该包含的所有内容以及指向数据文件中正确位置的删除链接，那么这应该可以工作并且可以修复表。开始修理下一张桌子。否则，请执行以下过程：


在继续之前备份您的数据文件。


使用 myisamchk -r tbl_name（-r 表示“恢复模式”）。这将从数据文件中删除不正确和已删除的记录并重建索引文件。


如果前面的步骤失败，请使用 myisamchk --safe-recover tbl_name 。安全恢复模式使用旧的恢复方法来处理常规恢复模式不起作用（但速度较慢）的少数情况。


如果在修复时遇到奇怪的错误（例如内存不足错误），或者如果 myisamchk 崩溃，请转到第 3 阶段。


第 3 阶段：难以修复


仅当索引文件的前 16K 块已损坏、包含不正确的信息或索引文件丢失时，才应进入此阶段。在这种情况下，需要创建一个新的索引文件。进行如下操作：


将数据文件移动到安全的地方。


使用表描述文件创建一个新的（空）数据文件和索引文件：

shell> mysql db_name


mysql> SET AUTOCOMMIT=1;


mysql> TRUNCATE TABLE tbl_name;


mysql> quit


如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。


将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）


回到阶段2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。


你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
第 4 阶段：非常困难的修复


只有在 .frm 描述文件也损坏时，您才应该进入此阶段。这永远不会发生，因为在创建表后描述文件从未更改过。


从备份中恢复描述文件并返回第 3 阶段。您还可以恢复索引文件并返回第 2 阶段。对于后者，您应该从 myisamchk -r 开始。


如果您没有备份但确切地知道该表是如何创建的，请在另一个数据库中创建该表的副本。删除新的数据文件，然后将描述和索引文件从另一个数据库移动到损坏的数据库。这提供了新的描述和索引文件，但单独保留了 .MYD 数据文件。返回第 2 阶段并尝试重建索引文件。


InnoDB 表可以通过以下方式修复：


如果数据库页面损坏，您可能希望使用 SELECT INTO OUTFILE 从从数据库中转储您的表，通常这种方式获得的大多数数据都是完整的。即便如此，损坏也会导致 SELECT * FROM tbl_name 或 InnoDB 后台操作崩溃或断言，甚至导致 InnoDB 前滚恢复崩溃。但是，您可以使用它来强制 InnoDB 存储引擎启动，同时阻止后台操作运行，以便您可以转储表。例如，您可以在重新启动服务器之前将以下行添加到选项文件的 [mysqld] 部分：
    [mysqld]innodb_force_recovery = 4 innodb_force_recovery允许的非零值如下。较大的数字包含较小数字的所有预防措施。如果您可以使用大多数为 4 的选项值来转储您的表，那么您相对安全，只有损坏的单个页面上的一些数据会丢失。值 6 更加夸张，因为数据库页面处于陈旧状态，这反过来又会对 B 树和其他数据库结构造成更大的破坏。
    1 (SRV_FORCE_IGNORE_CORRUPT)
即使检测到损坏的页面，也让服务器保持运行；尝试让 SELECT * FROM tbl_name 跳过损坏的索引记录和页面，这有助于转储表。


2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，这将防止在清除操作期间发生崩溃。
    3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不要运行事务回滚。
    4 (SRV_FORCE_NO_IBUF_MERGE)
还可以防止插入缓冲区合并操作。如果你能导致崩溃。最好不要做这些操作，不要计算表统计表。
    5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库时不要查看未完成的日志：InnoDB 将未完成的事务视为已提交。
    6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接上执行日志前滚。
    数据库不能与这些选项中允许的选项一起使用。作为一项安全措施，当 innodb_force_recovery 设置为大于 0 的值时，InnoDB 会阻止用户执行 INSERT、UPDATE 或 DELETE 操作。
    即使使用强制恢复，您也可以 DROP 或 CREATE 表。如果您知道给定的表正在使回滚崩溃，则可以将其删除。您还可以使用它来阻止因批量导入失败或 ALTER TABLE 失败而导致的失控回滚。可以杀掉mysqld进程，然后将innodb_force_recovery设置为3，这样数据库就挂起不回滚，然后丢弃导致回滚失控的表。

(Solve database table 'content_ Tags' is marked as broken and around be repaired
Today, suddenly the tag page of the website couldn't be opened. Open debug and find the prompt
Table 'content_ tags' is marked as crashed and should be repaired
Such a mistake
Problem analysis:
This prompt indicates that the '% s' table is damaged, which may be caused by abnormal shutdown and needs to be repaired.
Solution:
REPAIR TABLE `content_ tags`
It can also be repaired with myisamchk.
The preliminary estimation may be in addition to the problem of index reconstruction,
So far, the problem has been solved!
PS: there are still some questions to collect
Stage 1: check your desk
If you have a lot of time, run myisamchk * MYI or myisamchk - E * MYI 。 Use the - S (silent) option to suppress 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 those tables that myisamchk reports errors. For such a table, continue to phase 2.
If you encounter strange errors while checking (for example, out of memory errors), or if myisamchk crashes, go to phase 3.
Phase 2: simple and safe repair
Note: to fix faster, you should set sort when running myisamchk_ buffer_ Size and key_ buffer_ The value of the size variable is set to about 25% of the available memory.
First, try myisamchk - R - Q TBL_ Name (- R - Q stands for "quick recovery mode"). This will attempt to repair the index file without touching the data file. If the data file contains everything it should contain and a delete link to the correct location in the data file, this should work and repair the table. Start repairing the next table. Otherwise, perform the following procedure:
Back up your data files before continuing.
Use myisamchk - R TBL_ Name (- R stands for "recovery mode"). This will delete incorrect and deleted records from the data file and rebuild the index file.
If the previous steps fail, use myisamchk -- safe recover TBL_ name 。 The secure recovery model uses the old recovery method to deal with a few cases where the conventional recovery model does not work (but is slow).
If you encounter strange errors during repair (such as out of memory errors), or if myisamchk crashes, go to phase 3.
Stage 3: difficult to repair
This stage should only be entered if the first 16K block of the index file is damaged, contains incorrect information, or the index file is missing. In this case, you need to create a new index file. Do the following:
Move the data file 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 truncate table, use delete from TBL_ name 。
Copy the old data file to the newly created data file. Don't just move old files back into new ones; keep a copy in case something goes wrong
Return to phase 2. Now myisamchk - R - Q should work. (this should not be an infinite loop).
You can also use repair TABLE tbl_ name USE_ Frm, the whole program will be executed automatically.
Stage 4: very difficult repair
Only in You should only enter this stage if the frm description file is also corrupted. This will never happen because the description file has never changed since the table was created.
Recover the description file from the backup and return to phase 3. You can also recover 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 know exactly how the table was created, create a copy of the table in another database. Delete the new data file, and then move the description and index files from another database to the damaged database. This provides a new description and index file, but is retained separately MyD data file. Return to phase 2 and try to rebuild the index file.
InnoDB table can be repaired in the following ways:
If the database page is damaged, you may want to use select into output to dump your table from the database. Usually, most of the data obtained in this way is complete. Even so, damage can cause select * from TBL_ Name or InnoDB background operation crashes or asserts, and even causes InnoDB roll forward recovery crash. However, you can use it to force the InnoDB storage engine to start while preventing background operations from running so that you can dump 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 innodb_ force_ The non-zero values allowed by recovery are as follows. The larger number contains all precautions for the smaller number. If you can dump your table with most option values of 4, you are relatively safe, and only some data on a corrupted single page will be lost. The value of 6 is more exaggerated because the database page is in an old state, which in turn will cause greater damage to the B-tree and other database structures.
1 (SRV_FORCE_IGNORE_CORRUPT)
Keep the server running even if a damaged page is detected; Try to make select * from TBL_ Name skips corrupt index records and pages, which helps dump tables.
2 (SRV_FORCE_NO_BACKGROUND)
Prevents the main thread from running, which prevents crashes during cleanup operations.
3 (SRV_FORCE_NO_TRX_UNDO)
Do not run transaction rollback after recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
You can also prevent insert buffer merge operations. If you can cause a crash. It's best not to do these operations and do not calculate the statistical table.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Do not view the incomplete log when starting the database: InnoDB regards the incomplete transaction as committed.
6 (SRV_FORCE_NO_LOG_REDO)
Do not perform log roll forward on the recovery connection.
The database cannot be used with the options allowed in these options. As a safety measure, when InnoDB_ force_ When recovery is set to a value greater than 0, InnoDB will prevent users from performing insert, update or delete operations.
You can drop or create tables even with forced recovery. If you know that a given table is crashing a rollback, you can delete it. You can also use it to prevent uncontrolled rollback caused by batch import failure or alter table failure. You can kill the mysqld process, and then set InnoDB_ force_ Recovery is set to 3, so that the database is suspended without rollback, and then the tables that cause the rollback to get out of control are discarded.
)