lifetype 掛了，看不到文章內容

又過了好幾天沒有給自己的部落格一點關愛的眼神，昨天突想到，連上網看了一下，哇！怎麼只看得到類別，而沒有文章內容？！

仔細一想，好像幾天前有過一次停電，該不會是這個原因吧？！用 mysql client 連上，SELECT * FROM plog_article_text，嘿！果然有點問題，看訊息似乎是資料表有些損毀，無法讀出來。

又借了一下 GOOGLE 的神威，看到 dev.mysql.com 的說明文章指出修復的方法與注意事項。把它記錄下來，以便參考。

※ 要做修復資料庫動作之前，請先停止 MySQL伺服器: mysqladmin shutdown，停止mysqld 命令執行之後，mysqld 可能還會運作一會兒，直到所有的查詢動作和索引更動做完為止。

步驟一: 命令列: 檢查資料表
執行 myisamchk *.MYI or myisamchk -e *.MYI

步驟二:命令列: 快速又安全地修復
myisamchk -r -q tbl_name (-r -q 表示「快速修復模式(quick recovery mode)」).

1. 
   

   Make a backup of the data file before continuing.

   
   


2. 
   

   Use myisamchk -r tbl_name (-r means 「recovery mode」). This removes incorrect rows and deleted rows from the data file and reconstructs the index file.

   
   


3. 
   

   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).

   
   

步驟三: Difficult repair

1. 
   

   Move the data file to a safe place.

   
   


2. 
   

   Use the table description file to create new (empty) data and index files:

   
   

   
   shell> mysql db_name
   mysql> SET AUTOCOMMIT=1;
   mysql> TRUNCATE TABLE tbl_name;
   mysql> quit
   



3. 
   

   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.)

   
   

Go back to Stage 2. myisamchk -r -q should work. (This should not be an endless loop.)

步驟四: 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:

1. 
   

   Restore the description file from a backup and go back to Stage 3. You can also restore the index file and go back to Stage 2. In the latter case, you should start with myisamchk -r.

   
   


2. 
   

   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 .frm description and .MYI index files from the other database to your crashed database. This gives you new description and index files, but leaves the .MYD data file alone. Go back to Stage 2 and attempt to reconstruct the index file.