1、mysql日志報錯

innodb引擎提示數據庫沒有正常關閉，報innodb錯誤180112??0:49:28??InnoDB:?Database?was?not?shut?down?normally!

InnoDB:?Starting?crash?recovery.

InnoDB:?Reading?tablespace?information?from?the?.ibd?files...

InnoDB:?Restoring?possible?half-written?data?pages?from?the?doublewrite

InnoDB:?buffer...

InnoDB:?Doing?recovery:?scanned?up?to?log?sequence?number?2580576839

180112??0:49:28??InnoDB:?Error:?page?1?log?sequence?number?2580582651

InnoDB:?is?in?the?future!?Current?system?log?sequence?number?2580576839.

InnoDB:?Your?database?may?be?corrupt?or?you?may?have?copied?the?InnoDB

InnoDB:?tablespace?but?not?the?InnoDB?log?files.?See

InnoDB:?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?for?more?information.

180112??0:49:28??InnoDB:?Error:?page?5?log?sequence?number?2580579963

InnoDB:?is?in?the?future!?Current?system?log?sequence?number?2580576839.

InnoDB:?Your?database?may?be?corrupt?or?you?may?have?copied?the?InnoDB

InnoDB:?tablespace?but?not?the?InnoDB?log?files.?See

InnoDB:?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?for?more?information.

180112??0:49:29??InnoDB:?Error:?page?65565?log?sequence?number?2580577006

InnoDB:?is?in?the?future!?Current?system?log?sequence?number?2580576839.

InnoDB:?Your?database?may?be?corrupt?or?you?may?have?copied?the?InnoDB

InnoDB:?tablespace?but?not?the?InnoDB?log?files.?See

InnoDB:?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?for?more?information.

180112??0:49:29??InnoDB:?Error:?page?65566?log?sequence?number?2580577176

InnoDB:?is?in?the?future!?Current?system?log?sequence?number?2580576839.

InnoDB:?Your?database?may?be?corrupt?or?you?may?have?copied?the?InnoDB

InnoDB:?tablespace?but?not?the?InnoDB?log?files.?See

InnoDB:?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?for?more?information.

180112??0:49:29??InnoDB:?Starting?an?apply?batch?of?log?records?to?the?database...

InnoDB:

Progress?in?percents:?41?42?43?44?45?46?47?48?49?50?51?52?53?54?55?56

57?58?59?60?61?62?63?64?65?66?67?68?69?70?71?72?73?74?75?76?77?78?79?80

81?82?83?84?85?86?87?88?89?90?91?92?93?94?95?96?97?98?99?180112

0:49:29??InnoDB:?Assertion?failure?in?thread?140330795001600?in?file

rem0rec.c?line?569

InnoDB:?We?intentionally?generate?a?memory?trap.

InnoDB:?Submit?a?detailed?bug?report?to?http://bugs.mysql.com.

InnoDB:?If?you?get?repeated?assertion?failures?or?crashes,?even

InnoDB:?immediately?after?the?mysqld?startup,?there?may?be

InnoDB:?corruption?in?the?InnoDB?tablespace.?Please?refer?to

InnoDB:?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?about?forcing?recovery.

16:49:29?UTC?-?mysqld?got?signal?6?;

This?could?be?because?you?hit?a?bug.?It?is?also?possible?that?this?binary

or?one?of?the?libraries?it?was?linked?against?is?corrupt,?improperly?built,

or?misconfigured.?This?error?can?also?be?caused?by?malfunctioning?hardware.

We?will?try?our?best?to?scrape?up?some?info?that?will?hopefully?help

diagnose?the?problem,?but?since?we?have?already?crashed,

something?is?definitely?wrong?and?this?may?fail.

2、查看mysql服務狀態，提示mysql沒在運行，但是鎖定文件存在ERROR!?MySQL?is?not?running，but?lock?file?(/var/lock/subsys/mysql)?exists

3、重啟mysql服務，提示錯誤[root@mail?subsys]#?/etc/init.d/umail_mysqld?restart

ERROR!?MySQL?server?PID?file?could?not?be?found!

Starting?MySQL.?ERROR!?The?server?quit?without?updating?PID?file?(/usr/local/u-mail/data/mysql/default.pid).

日志報下面的錯誤：180112??9:12:44?InnoDB:?Cannot?initialize?created?log?files?because

180112??9:12:44?InnoDB:?data?files?are?corrupt,?or?new?data?files?were

180112??9:12:44?InnoDB:?created?when?the?database?was?started?previous

180112??9:12:44?InnoDB:?time?but?the?database?was?not?shut?down

180112??9:12:44?InnoDB:?normally?after?that.

180112??9:12:44?[ERROR]?Plugin?'InnoDB'?init?function?returned?error.

180112??9:12:44?[ERROR]?Plugin?'InnoDB'?registration?as?a?STORAGE?ENGINE?failed.

將數據庫下ib_logfile文件移動走后(因為最開始看日志的時候提示了InnoDB: tablespace but not the InnoDB log files. See )，可以重啟mysql服務。

4、以為重啟mysql成功后就可以，但是沒想到innodb引擎表已經損壞了。

日志提示：180112??9:37:40?[ERROR]?Cannot?find?or?open?table?umail/core_auth_log?from

the?internal?data?dictionary?of?InnoDB?though?the?.frm?file?for?the

table?exists.?Maybe?you?have?deleted?and?recreated?InnoDB?data

files?but?have?forgotten?to?delete?the?corresponding?.frm?files

of?InnoDB?tables,?or?you?have?moved?.frm?files?to?another?database?

or,?the?table?contains?indexes?that?this?version?of?the?engine

doesn't?support.

See?http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html

how?you?can?resolve?the?problem

(1)用phpmyadmin進去看提示正在使用，修復提示Unknown storage engine 'InnoDB '錯誤。

(2)mysql命令控制臺輸入show engines;查看，也沒有innodb引擎。

5、解決辦法(數據會丟失，除非有備份數據)

(1)將ib開頭的日志文件和數據文件移動走(最好停止umail后移動走，然后再開啟umail)

(2)使用drop tables 表名;，刪除innodb表

(3)停止與mysql服務相關的服務

(4)使用show processlist;命令查看是否有鎖定

(5)將創建這幾個表的sql文件放在一個路徑下

(6)到mysql命令控制臺輸入source /usr/local/kx-mail/data/mysql/default/base_table.sql導入表結構

(7)重啟mysql服務

6、總結(平時數據庫要用mysqldump最好備份，也可以單獨對表做備份，出現問題的時候還原)

ibdata1文件很多，將近2GB(innodb_file_per_table參數可以給ibdata文件瘦身)。可能和這個文件太大，而且又突然斷電有關系。

分析日志后發現，數據庫無法重啟的原因是因為ibdata1文件損壞，重啟后無法正常恢復。

解決辦法：

需要跳過恢復步驟，修改my.cnf文件，在my.cnf中的[mysqld]中添加：

innodb_force_recovery = 6

innodb_purge_threads = 1

解釋：

innodb_force_recovery可以設置為1-6,大的數字包含前面所有數字的影響。

具體數字對應的含義：

1-----(SRVFORCEIGNORECORRUPT):忽略檢查到的corrupt頁。

2-----(SRVFORCENOBACKGROUND):阻止主線程的運行，如主線程需要執行full purge操作，會導致crash。

3-----(SRVFORCENOTRXUNDO):不執行事務回滾操作。

4-----(SRVFORCENOIBUFMERGE):不執行插入緩沖的合并操作。

5-----(SRVFORCENOUNDOLOGSCAN):不查看重做日志，InnoDB存儲引擎會將未提交的事務視為已提交。

6-----(SRVFORCENOLOG_REDO):不執行前滾的操作。

再次啟動mysql就ok了.

如果還無法啟動，則需要刪除數據目錄datafile下的 ibdata1,ib_logfile*等文件。然后恢復數據庫信息(本次用的方法)

突然收到MySQL報警，從庫的數據庫掛了，一直在不停的重啟，打開錯誤日志，發現有張表壞了。innodb表損壞不能通過repair table 等修復myisam的命令操作。現在記錄下解決過程，下次遇到就不會這么手忙腳亂了。

處理過程：

一遇到報警之后，直接打開錯誤日志，里面的信息：InnoDB:?Database?page?corruption?on?disk?or?a?failed

InnoDB:?file?read?of?page?30506.

InnoDB:?You?may?have?to?recover?from?a?backup.

130509?20:33:48??InnoDB:?Page?dump?in?ascii?and?hex?(16384?bytes):

##很多十六進制的代碼

……

……

InnoDB:?End?of?page?dump

130509?20:37:34??InnoDB:?Page?checksum?1958578898,?prior-to-4.0.14-form?checksum?3765017239

InnoDB:?stored?checksum?3904709694,?prior-to-4.0.14-form?stored?checksum?3765017239

InnoDB:?Page?lsn?5?614270220,?low?4?bytes?of?lsn?at?page?end?614270220

InnoDB:?Page?number?(if?stored?to?page?already)?30506,

InnoDB:?space?id?(if?created?with?>=?MySQL-4.1.1?and?stored?already)?19

InnoDB:?Page?may?be?an?index?page?where?index?id?is?54

InnoDB:?(index?"PRIMARY"?of?table?"maitem"."email_status")

InnoDB:?Database?page?corruption?on?disk?or?a?failed

InnoDB:?file?read?of?page?30506.

InnoDB:?You?may?have?to?recover?from?a?backup.

InnoDB:?It?is?also?possible?that?your?operating

InnoDB:?system?has?corrupted?its?own?file?cache

InnoDB:?and?rebooting?your?computer?removes?the

InnoDB:?error.

InnoDB:?If?the?corrupt?page?is?an?index?page

InnoDB:?you?can?also?try?to?fix?the?corruption

InnoDB:?by?dumping,?dropping,?and?reimporting

InnoDB:?the?corrupt?table.?You?can?use?CHECK

InnoDB:?TABLE?to?scan?your?table?for?corruption.

InnoDB:?See?also?http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

InnoDB:?about?forcing?recovery.

InnoDB:?A?new?raw?disk?partition?was?initialized?or

InnoDB:?innodb_force_recovery?is?on:?we?do?not?allow

InnoDB:?database?modifications?by?the?user.?Shut?down

InnoDB:?mysqld?and?edit?my.cnf?so?that?newraw?is?replaced

InnoDB:?with?raw,?and?innodb_force_...?is?removed.

130509?20:39:35?[Warning]?Invalid?(old?)?table?or?database?name?'#sql2-19c4-5'

從錯誤日志里面很清楚的知道哪里出現了問題，該怎么處理。這時候數據庫隔幾s就重啟，所以差不多可以說你是訪問不了數據庫的。所以馬上想到要修復innodb表了。

以前在Performance的blog上看過類似文章。

當時想到的是在修復之前保證數據庫正常，不是這么異常的無休止的重啟。所以就修改了配置文件的一個參數：innodb_force_recoveryinnodb_force_recovery影響整個InnoDB存儲引擎的恢復狀況。默認為0，表示當需要恢復時執行所有的

innodb_force_recovery可以設置為1-6,大的數字包含前面所有數字的影響。當設置參數值大于0后，可以對表進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。

2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執行full?purge操作，會導致crash。

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 設置為1，忽略檢查到的壞頁。重啟數據庫之后，正常了，沒有出現上面的錯誤信息。找到錯誤信息出現的表：

(index?"PRIMARY"?of table?"maitem"."email_status")

數據頁面的主鍵索引(clustered key index)被損壞。這種情況和數據的二級索引(secondary

indexes)被損壞相比要糟很多，因為后者可以通過使用OPTIMIZE TABLE命令來修復，但這和更難以恢復的表格目錄(table

dictionary)被破壞的情況來說要好一些。

操作步驟：

因為被破壞的地方只在索引的部分，所以當使用innodb_force_recovery = 1運行InnoDB時，操作如下：執行check，repair?table?都無效

alter?table?email_status?engine?=myisam;??#也報錯了，因為模式是innodb_force_recovery?=1。

ERROR?1025?(HY000):?Error?on?rename?of?'...'?to?'....'?(errno:?-1)建立一張表：create?table?email_status_bak???#和原表結構一樣，只是把INNODB改成了MYISAM。把數據導進去insert?into?email_status_bak?select?*?from?email_status;

刪除掉原表：

drop?table?email_status;

注釋掉innodb_force_recovery?之后，重啟。

重命名：

rename?table?edm_email_status_bak?to?email_status;

最后該回存儲引擎

alter?table?edm_email_status?engine?=?innodb

總結：

這里的一個重要知識點就是

對?innodb_force_recovery?參數的理解了，要是遇到數據損壞甚至是其他的損壞。可能上面的方法不行了，需要嘗試另一個方法：insert

into tb select * from ta limit X；甚至是dump出去，再load回來。

總結

以上是生活随笔為你收集整理的mysql断电不受影响db引擎_一次服务器断电，造成innodb引擎表（日志表）损坏的解决办法...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。