13518219792
Windows上安裝了XMAPP-controller之后間歇性出現(xiàn)MySQL無(wú)法啟動(dòng)，查看日之后發(fā)現(xiàn)是innodb的報(bào)錯(cuò)，報(bào)錯(cuò)信息如下：
創(chuàng)新互聯(lián)建站"三網(wǎng)合一"的企業(yè)建站思路。企業(yè)可建設(shè)擁有電腦版、微信版、手機(jī)版的企業(yè)網(wǎng)站。實(shí)現(xiàn)跨屏營(yíng)銷，產(chǎn)品發(fā)布一步更新，電腦網(wǎng)絡(luò)+移動(dòng)網(wǎng)絡(luò)一網(wǎng)打盡，滿足企業(yè)的營(yíng)銷需求！創(chuàng)新互聯(lián)建站具備承接各種類型的成都網(wǎng)站制作、網(wǎng)站建設(shè)項(xiàng)目的能力。經(jīng)過(guò)十余年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質(zhì)的服務(wù)，并獲得了客戶的一致好評(píng)。
度娘上各種答案無(wú)法解決，后來(lái)直接看官方文檔，直接上解決方案：
踩坑指南 - - 操作配置前需要做這些操作：
1、配置my.cnf 配置innodb_force_recovery = 1 到 6 試到正確為止，重啟MySQL
2、導(dǎo)出數(shù)據(jù)腳本 mysqldump -uroot -p123456 test test.sql 導(dǎo)出SQL腳本。或者用Navicat將所有數(shù)據(jù)庫(kù)/表導(dǎo)入到其他服務(wù)器的數(shù)據(jù)庫(kù)中。 注意：這里的數(shù)據(jù)一定要備份成功。然后刪除原數(shù)據(jù)庫(kù)中的數(shù)據(jù)。
3、刪除ib_logfile0、ib_logfile1、ibdata1 備份MySQL數(shù)據(jù)目錄下的ib_logfile0、ib_logfile1、ibdata1三個(gè)文件，然后將這三個(gè)文件刪除
4、配置my.cnf 將my.cnf中innodb_force_recovery 這行配置刪除或者配置為innodb_force_recovery = 0，重啟MySQL服務(wù)
5、將數(shù)據(jù)導(dǎo)入MySQL數(shù)據(jù)庫(kù) mysql -uroot -p123456 test test.sql;
或者用Navicat將備份的數(shù)據(jù)導(dǎo)入到數(shù)據(jù)庫(kù)中。 如果在導(dǎo)入數(shù)據(jù)過(guò)程中發(fā)生tablespace不存在的問(wèn)題，請(qǐng)刪除data目錄相應(yīng)database下的文件。
MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤 IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。
如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開 N 個(gè) ibd 文件了，只需要打開一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。
臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。
解決方法一：
打開“服務(wù)”項(xiàng)目，選擇mysql服務(wù)，在右鍵中選擇其“恢復(fù)”選項(xiàng)，它負(fù)責(zé)服務(wù)失敗時(shí)計(jì)算機(jī)的反應(yīng)。每一次失敗時(shí)，你可以選擇（1）不操作；（2）重新啟動(dòng)服務(wù)；（3）運(yùn)行一個(gè)程序；（4）重啟服務(wù)器。您可以在第一次和第二次失敗時(shí)選擇重新啟動(dòng)服務(wù)，第三次失敗就重啟服務(wù)器，這樣可以在無(wú)人值守的情況下達(dá)到自穩(wěn)。但遺憾的是windows的這項(xiàng)內(nèi)置服務(wù)工作時(shí)并不盡如人意。
解決方法二：
定期優(yōu)化MySQL，這可以通過(guò)Mysql administrator來(lái)執(zhí)行，也可以使用mysql的維護(hù)工具mysqlcheck，使用方法為：進(jìn)入Mysql的Bin目錄：C:\Program Files\MySQL\MySQL Server 4.1\bin 運(yùn)行：mysqlcheck -A -o -r -uroot -p123456(注意，將123456改成你自己的root用戶密碼， 如無(wú)請(qǐng)留空 )，有時(shí)可以起到一定的作用。
解決方法三：
建立一個(gè)php+mysql的簡(jiǎn)單網(wǎng)站，在服務(wù)器監(jiān)控王的網(wǎng)站監(jiān)視設(shè)置中，讓服務(wù)器監(jiān)控王軟件定期去訪問(wèn)這個(gè)網(wǎng)站（如60秒一次），如果不能訪問(wèn)，說(shuō)明數(shù)據(jù)庫(kù)存在問(wèn)題，將故障回報(bào)至您的郵箱或手機(jī)中，讓您在第一時(shí)間內(nèi)得知網(wǎng)站訪問(wèn)情況。如果連續(xù)幾次都不能訪問(wèn)，您可以選擇自動(dòng)重啟服務(wù)器，從而達(dá)到無(wú)人值守的狀態(tài)。
解決方法四：
設(shè)定服務(wù)器監(jiān)控王的SQL監(jiān)視，定期對(duì)mysql是否運(yùn)行進(jìn)行定期監(jiān)視，如有問(wèn)題立即重啟或回報(bào)。
解決方法五：
對(duì)于上面問(wèn)題中提到某臺(tái)服務(wù)器準(zhǔn)時(shí)在掛掉，如凌晨5點(diǎn)，產(chǎn)生這樣的原因分析可能與當(dāng)前流行的discuz論壇的自動(dòng)定時(shí)備份有關(guān)，因?yàn)楹芏嗫蛻舳〞r(shí)在凌晨時(shí)段自動(dòng)備份mysql數(shù)據(jù)庫(kù)，導(dǎo)致mysql工作忙碌（如有很多的mysql用戶），可以建立一個(gè)計(jì)劃任務(wù)，定時(shí)如早上6時(shí)將mysql重啟一下。
解決方法六：
更換為非windows主機(jī)，運(yùn)行更少的mysql+PHP網(wǎng)站，當(dāng)然對(duì)于從事虛擬主機(jī)業(yè)務(wù)的運(yùn)營(yíng)商來(lái)說(shuō)是一項(xiàng)損失。
MySQL 隨著版本不停迭代，崩潰的現(xiàn)象越來(lái)越少，也越來(lái)越隱蔽。
一旦遇到生產(chǎn)環(huán)境上的 MySQL 崩潰，就需要保留現(xiàn)場(chǎng)信息，供分析用。雖然 MySQL 的 error log 中會(huì)打印部分信息，但對(duì)于比較隱蔽的崩潰，往往顯得力不從心。
通過(guò)開啟操作系統(tǒng)級(jí)別、放開用戶限制、啟用 MySQL 參數(shù)三個(gè)步驟，我們啟用了 MySQL 的 coredump 功能，使得 MySQL 崩潰時(shí)留下了足夠的線索。
對(duì)于復(fù)雜崩潰的分析，還是需要將 coredump 交給專業(yè)的研發(fā)工程師手里，或者提交給 MySQL 開發(fā)團(tuán)隊(duì)。
不過(guò)不管是什么場(chǎng)景，能提供一份 coredump，所有技術(shù)人員都會(huì)感謝你的。
MySQL 隨著版本不停迭代，崩潰的現(xiàn)象越來(lái)越少，也越來(lái)越隱蔽。
一旦遇到生產(chǎn)環(huán)境上的 MySQL 崩潰，就需要保留現(xiàn)場(chǎng)信息，供分析用。雖然 MySQL 的 error log 中會(huì)打印部分信息，但對(duì)于比較隱蔽的崩潰，往往顯得力不從心。
通過(guò)開啟操作系統(tǒng)級(jí)別、放開用戶限制、啟用 MySQL 參數(shù)三個(gè)步驟，我們啟用了 MySQL 的 coredump 功能，使得 MySQL 崩潰時(shí)留下了足夠的線索。
對(duì)于復(fù)雜崩潰的分析，還是需要將 coredump 交給專業(yè)的研發(fā)工程師手里，或者提交給 MySQL 開發(fā)團(tuán)隊(duì)。
不過(guò)不管是什么場(chǎng)景，能提供一份 coredump，所有技術(shù)人員都會(huì)感謝你的。
