日本好好热aⅴ|国产99视频精品免费观看|日本成人aV在线|久热香蕉国产在线

  • <cite id="ikgdy"><table id="ikgdy"></table></cite>
    1. 西西軟件園多重安全檢測(cè)下載網(wǎng)站、值得信賴的軟件下載站!
      軟件
      軟件
      文章
      搜索

      首頁(yè)西西教程數(shù)據(jù)庫(kù)教程 → MySQL數(shù)據(jù)庫(kù)INNODB 表?yè)p壞修復(fù)處理過(guò)程

      MySQL數(shù)據(jù)庫(kù)INNODB 表?yè)p壞修復(fù)處理過(guò)程

      相關(guān)軟件相關(guān)文章發(fā)表評(píng)論 來(lái)源:西西整理時(shí)間:2013/5/10 14:03:36字體大。A-A+

      作者:西西點(diǎn)擊:425次評(píng)論:0次標(biāo)簽: MySQL

      • 類型:數(shù)據(jù)庫(kù)類大小:1.7M語(yǔ)言:英文 評(píng)分:6.6
      • 標(biāo)簽:
      立即下載

      突然收到MySQL報(bào)警,從庫(kù)的數(shù)據(jù)庫(kù)掛了,一直在不停的重啟,打開(kāi)錯(cuò)誤日志,發(fā)現(xiàn)有張表壞了。innodb表?yè)p壞不能通過(guò)repair table 等修復(fù)myisam的命令操作。現(xiàn)在記錄下解決過(guò)程,下次遇到就不會(huì)這么手忙腳亂了。

      處理過(guò)程:
       一遇到報(bào)警之后,直接打開(kāi)錯(cuò)誤日志,里面的信息:

      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):
      ##很多十六進(jìn)制的代碼
      ……
      ……
      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'

      從錯(cuò)誤日志里面很清楚的知道哪里出現(xiàn)了問(wèn)題,該怎么處理。這時(shí)候數(shù)據(jù)庫(kù)隔幾s就重啟,所以差不多可以說(shuō)你是訪問(wèn)不了數(shù)據(jù)庫(kù)的。所以馬上想到要修復(fù)innodb表了。
      以前在Performance的blog上看過(guò)類似文章。

      當(dāng)時(shí)想到的是在修復(fù)之前保證數(shù)據(jù)庫(kù)正常,不是這么異常的無(wú)休止的重啟。所以就修改了配置文件的一個(gè)參數(shù):innodb_force_recovery

      innodb_force_recovery影響整個(gè)InnoDB存儲(chǔ)引擎的恢復(fù)狀況。默認(rèn)為0,表示當(dāng)需要恢復(fù)時(shí)執(zhí)行所有的
      
      innodb_force_recovery可以設(shè)置為1-6,大的數(shù)字包含前面所有數(shù)字的影響。當(dāng)設(shè)置參數(shù)值大于0后,可以對(duì)表進(jìn)行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
      
      1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁(yè)。
      2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運(yùn)行,如主線程需要執(zhí)行full purge操作,會(huì)導(dǎo)致crash。
      3(SRV_FORCE_NO_TRX_UNDO):不執(zhí)行事務(wù)回滾操作。
      4(SRV_FORCE_NO_IBUF_MERGE):不執(zhí)行插入緩沖的合并操作。
      5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存儲(chǔ)引擎會(huì)將未提交的事務(wù)視為已提交。
      6(SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作。

      因?yàn)殄e(cuò)誤日志里面提示出現(xiàn)了壞頁(yè),導(dǎo)致數(shù)據(jù)庫(kù)崩潰,所以這里把innodb_force_recovery 設(shè)置為1,忽略檢查到的壞頁(yè)。重啟數(shù)據(jù)庫(kù)之后,正常了,沒(méi)有出現(xiàn)上面的錯(cuò)誤信息。找到錯(cuò)誤信息出現(xiàn)的表:
      (index "PRIMARY" of table "maitem"."email_status")

      數(shù)據(jù)頁(yè)面的主鍵索引(clustered key index)被損壞。這種情況和數(shù)據(jù)的二級(jí)索引(secondary indexes)被損壞相比要糟很多,因?yàn)楹笳呖梢酝ㄟ^(guò)使用OPTIMIZE TABLE命令來(lái)修復(fù),但這和更難以恢復(fù)的表格目錄(table dictionary)被破壞的情況來(lái)說(shuō)要好一些。

      操作步驟:
      因?yàn)楸黄茐牡牡胤街辉谒饕牟糠,所以?dāng)使用innodb_force_recovery = 1運(yùn)行InnoDB時(shí),操作如下:

      執(zhí)行check,repair table 都無(wú)效
      alter table email_status engine =myisam;  #也報(bào)錯(cuò)了,因?yàn)槟J绞莍nnodb_force_recovery =1。
      ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)
      
      建立一張表:
      create table email_status_bak   #和原表結(jié)構(gòu)一樣,只是把INNODB改成了MYISAM。
      
      把數(shù)據(jù)導(dǎo)進(jìn)去
      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;
      
      最后該回存儲(chǔ)引擎
      alter table edm_email_status engine = innodb

      總結(jié):
      這里的一個(gè)重要知識(shí)點(diǎn)就是 對(duì) innodb_force_recovery 參數(shù)的理解了,要是遇到數(shù)據(jù)損壞甚至是其他的損壞?赡苌厦娴姆椒ú恍辛,需要嘗試另一個(gè)方法:insert into tb select * from ta limit X;甚至是dump出去,再load回來(lái)。

        相關(guān)評(píng)論

        閱讀本文后您有什么感想? 已有人給出評(píng)價(jià)!

        • 8 喜歡喜歡
        • 3 頂
        • 1 難過(guò)難過(guò)
        • 5 囧
        • 3 圍觀圍觀
        • 2 無(wú)聊無(wú)聊

        熱門(mén)評(píng)論

        最新評(píng)論

        發(fā)表評(píng)論 查看所有評(píng)論(0)

        昵稱:
        表情: 高興 可 汗 我不要 害羞 好 下下下 送花 屎 親親
        字?jǐn)?shù): 0/500 (您的評(píng)論需要經(jīng)過(guò)審核才能顯示)