首先要找到問題的原因所在，然后一項一項排除。
定制設(shè)計可以根據(jù)自己的需求進(jìn)行定制，網(wǎng)站制作、成都做網(wǎng)站構(gòu)思過程中功能建設(shè)理應(yīng)排到主要部位公司網(wǎng)站制作、成都做網(wǎng)站的運用實際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實際意義
最簡單省事的就是直接換一個版本的mysql，看看還掛不掛。不掛就OK了。
如果還是掛，你就一個數(shù)據(jù)庫一個數(shù)據(jù)庫的增加，增加到哪個數(shù)據(jù)庫后開始掛了，說明是這個數(shù)據(jù)庫或者訪問這個數(shù)據(jù)庫的程序的問題。
如果和數(shù)據(jù)庫沒關(guān)系，請嘗試換一個電腦安裝mysql，可以排除是否是當(dāng)前電腦的環(huán)境有問題（比如軟件、硬件、病毒、內(nèi)存）等。
如果還有問題，請嘗試設(shè)置mysql的參數(shù)，比如占用內(nèi)存大小，連接數(shù)量最大值，數(shù)據(jù)庫引擎等。
有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數(shù)據(jù)檢測恢復(fù)工具。前者使用起來比較簡便。推薦使用。
1. check table 和 repair table
登陸mysql 終端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出現(xiàn)的結(jié)果說Status是OK，則不用修復(fù)，如果有Error，可以用：
repair table tabTest;
進(jìn)行修復(fù)，修復(fù)之后可以在用check table命令來進(jìn)行檢查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk適用于MYISAM類型的數(shù)據(jù)表，而isamchk適用于ISAM類型的數(shù)據(jù)表。這兩條命令的主要參數(shù)相同，一般新的系統(tǒng)都使用MYISAM作為缺省的數(shù)據(jù)表類型，這里以myisamchk為例子進(jìn)行說明。當(dāng)發(fā)現(xiàn)某個數(shù)據(jù)表出現(xiàn)問題時可以使用：
myisamchk tablename.MYI
進(jìn)行檢測，如果需要修復(fù)的話，可以使用：
myisamchk -of tablename.MYI
關(guān)于myisamchk的詳細(xì)參數(shù)說明，可以參見它的使用幫助。需要注意的時在進(jìn)行修改時必須確保MySQL服務(wù)器沒有訪問這個數(shù)據(jù)表，保險的情況下是最好在進(jìn)行檢測時把MySQL服務(wù)器Shutdown掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外可以把下面的命令放在你的rc.local里面啟動MySQL服務(wù)器前：
[ -x /tmp/mysql.sock ] /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL監(jiān)聽的Sock文件位置，對于使用RPM安裝的用戶應(yīng)該是/var/lib/mysql/mysql.sock，對于使用源碼安裝則是/tmp/mysql.sock可以根據(jù)自己的實際情況進(jìn)行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL數(shù)據(jù)庫存放的位置。
需要注意的時，如果你打算把這條命令放在你的rc.local里面，必須確認(rèn)在執(zhí)行這條指令時MySQL服務(wù)器必須沒有啟動！檢測修復(fù)所有數(shù)據(jù)庫(表)
MySQL 在崩潰恢復(fù)時，會遍歷打開所有 ibd 文件的 header page 驗證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復(fù)確實和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時間越長。另外磁盤 IOPS 也會影響崩潰恢復(fù)時間，像這里開發(fā)庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發(fā)現(xiàn)，MySQL 8 下正常啟用時居然也會進(jìn)行表空間校驗，而故障恢復(fù)時則會額外再進(jìn)行一次表空間校驗，等于校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數(shù)量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復(fù)時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過表空間校驗。實際測試的時候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過壞頁，就可以跳過校驗，然后重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復(fù)后非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節(jié)省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理后，感覺共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢。
臨時冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然后讓 MySQL 正常關(guān)閉，重新啟動就可以正常啟動了。但是實際測試發(fā)現(xiàn)，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
一、背景
近期，公司RDS云產(chǎn)品的MySQL Server版本進(jìn)行升級，由目前使用的5.7.26版本升級到最新版本5.7.31；升級后測試同學(xué)發(fā)現(xiàn)：在MySQL創(chuàng)建用戶后，5.7.31版本重新啟動集群會出現(xiàn)啟動失敗的現(xiàn)象；而5.7.26版本在相同測試場景下是正常啟動的。這到底是為什么呢?
二、問題復(fù)現(xiàn)
2.1 實驗環(huán)境
2.2 操作步驟
按照測試同學(xué)的測試步驟，首先創(chuàng)建一個用戶：
然后關(guān)閉mysqld；這里需要介紹一下，我們集群的關(guān)閉方式是如下方式：
這種方式的內(nèi)部實現(xiàn)類似于kill -9模式。所以我在線下環(huán)境使用kill -9的方式來復(fù)現(xiàn)，操作如下：
然后重啟mysqld，操作如下：
此時問題復(fù)現(xiàn)了，mysqld啟動失敗，我們查看了下error日志，信息如下：
根據(jù)報錯信息可以看出:MySQL的權(quán)限系統(tǒng)表發(fā)生了損壞，導(dǎo)致了mysqld啟動失?。挥捎谠贛ySQL 5.7及其之前版本該表是MyISAM引擎，且該引擎不支持事務(wù)，所以在mysqld異常崩潰會導(dǎo)致該類型引擎表的損壞;但在mysqld啟動時是有參數(shù)控制MyISAM引擎的恢復(fù)模式，且該參數(shù)在我們產(chǎn)品中也配置到了my.cnf中，如下所示：
2.3 參數(shù)解析
對于該參數(shù)的官方文檔的解釋如下：
設(shè)置MyISAM存儲引擎恢復(fù)模式。選項值是OFF、DEFAULT、BACKUP、FORCE或QUICK的值的任意組合。如果指定多個值，請用逗號分隔。指定不帶參數(shù)的選項與指定DEFAULT相同，指定顯式值" "將禁用恢復(fù)(與OFF值相同)。如果啟用了恢復(fù)，則mysqld每次打開MyISAM表時，都會檢查該表是否標(biāo)記為已崩潰或未正確關(guān)閉。(只有在禁用外部鎖定的情況下運行，最后一個選項才起作用。)在這種情況下，mysqld在表上運行檢查。如果表已損壞，mysqld將嘗試對其進(jìn)行修復(fù)。
服務(wù)器自動修復(fù)表之前，它將有關(guān)修復(fù)的注釋寫到錯誤日志中。如果您希望能夠在無需用戶干預(yù)的情況下從大多數(shù)問題中恢復(fù)，則應(yīng)使用選項BACKUP，F(xiàn)ORCE。即使某些行將被刪除，這也會強(qiáng)制修復(fù)表，但是它將舊的數(shù)據(jù)文件保留為備份，以便您以后可以檢查發(fā)生了什么。
全局變量，只讀變量，默認(rèn)為OFF。
三、問題修復(fù)
這類MySQL用戶表損耗的問題解決方式也是有多種，我這里列舉其中一種：
（1）my.cnf中的[mysqld]標(biāo)簽下添加skip_grant_tables，啟動時跳過加載系統(tǒng)字典。
（2）重啟mysqld，然后修復(fù)mysql schema下的所有表。
（3）在[mysqld]標(biāo)簽下注釋或刪除掉skip_grant_tables，然后重啟mysqld。
此時mysqld是可以正常啟動的，無異常。
四、深入排查
在產(chǎn)品化中，以上修復(fù)方式很不優(yōu)雅，只是作為臨時的解決方案;并且也存在一些令人疑惑的點：
帶著這些疑問，我們繼續(xù)排查出現(xiàn)該現(xiàn)象的原因；此時Google也沒有找到一些有效的信息，那么只能通過MySQL源代碼來尋找一些答案。
首先需要下載mysql 5.7.31版本的源代碼，并搭建mysql debug環(huán)境；具體步驟可以自動Google搜索一下，本文就不再贅述了。
在源代碼中搜索一下關(guān)鍵詞，用于打斷點的位置，然后進(jìn)行調(diào)試：
定位到相關(guān)代碼，大概是sql/mysqld.cc的4958行，且存在if條件判斷，此時我們開始調(diào)試：
通過以上調(diào)試信息，可以判斷出acl_init函數(shù)返回的值為真;此時我們查看該函數(shù)的代碼 (sql/auth/sql_auth_cache.cc:1365)：
根據(jù)該函數(shù)的注釋發(fā)現(xiàn)：該函數(shù)是初始化負(fù)責(zé)用戶/數(shù)據(jù)庫級特權(quán)檢查的結(jié)構(gòu)，并從mysql schema中的表中為其加載特權(quán)信息；且return值為1代表的是初始化權(quán)限失敗。
此后開始逐步調(diào)試，觀察return相關(guān)信息，當(dāng)調(diào)試到lock_table_names函數(shù)時，我們發(fā)現(xiàn)在Phase 3時return值為true，且根據(jù)代碼注釋發(fā)現(xiàn)true代表是Failure；具體代碼如下(sql/sql_base.cc:5549)：
調(diào)試信息如下：
可以看到flags的值為0，而MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK為宏定義值0x1000，與flags的值 做按位與操作，結(jié)果自然也是0，當(dāng)然MYSQL_LOCK_IGNORE_GLOBAL_READ_ONLY也是如此;need_global_read_lock_protection是bool類型值，代表是否需要全局讀鎖的保護(hù)，這個值是在table- mdl_request.type不為MDL_SHARED_READ_ONLY發(fā)生改變;check_readonly函數(shù)相關(guān)信息 下面概述。
此時也查看了下MySQL 5.7.26版本代碼作為對比，發(fā)現(xiàn)lock_table_names函數(shù)下的Phase 3后的部分代 碼是在5.7.29版本后新增的。如果是git clone的MySQL代碼可以用git blame命令查詢文件變化的信息：
上述展示的信息中，最左側(cè)的列值為commit id為05824063和0405ebee，有興趣的同學(xué)可以詳細(xì)看下。
此功能解決的問題是 BUG#28438114: SET READ_ONLY=1 SOMETIMES DOESN'T BLOCK CONCURRENT DDL.；當(dāng)然這個代碼的變更功能也在5.7 Release Notes中有所體現(xiàn)，如下所示( m/doc/relnotes/mysql/5.7/en/news-5-7-29.html )：
最后我們再查看下check_readonly函數(shù)，該函數(shù)是基于read_only和super_read_only狀態(tài)執(zhí)行標(biāo)準(zhǔn)化檢查，是禁止(TRUE)還是允許(FALSE)操作。代碼如下(sql/auth/sql_authorization.cc:489)：
此時第一反應(yīng)就是去檢查my.cnf中是否包含read_only相關(guān)參數(shù)，檢查之后發(fā)現(xiàn)確實是使用了該參數(shù)， 如下：
此時注釋掉該參數(shù)，然后再次啟動mysqld，發(fā)現(xiàn)MyISAM表可以自動修復(fù)，且正常啟動；error log信息如下：
由于docker一些限制，我們在mysqld啟動會涉及兩次;所以解決該問題的方式為：第一次mysqld的啟動時先關(guān)閉read_only參數(shù)，第二次啟動時開啟read_only參數(shù)。之所以選擇默認(rèn)開啟read_only參數(shù)， 是為了避免在mysqld啟動后，選主邏輯未完成時的保護(hù)措施；當(dāng)然選主完成后，會自動對master執(zhí)行 set global read_only=0 操作。
五、總結(jié)
六、附錄
調(diào)試的棧幀信息如下，有興趣的小伙伴可以研究下：
熟悉MySQL體系結(jié)構(gòu)和innodb存儲引擎工作原理；以及MySQL備份恢復(fù)、復(fù)制、數(shù)據(jù)遷移等技術(shù)；專注于MySQL、MariaDB開源數(shù)據(jù)庫，喜好開源技術(shù)。
原文鏈接：
MySQL 在崩潰恢復(fù)時，會遍歷打開所有 ibd 文件的 header page 驗證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復(fù)確實和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時間越長。另外磁盤 IOPS 也會影響崩潰恢復(fù)時間，像這里開發(fā)庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發(fā)現(xiàn)，MySQL 8 下正常啟用時居然也會進(jìn)行表空間校驗，而故障恢復(fù)時則會額外再進(jìn)行一次表空間校驗，等于校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數(shù)量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復(fù)時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過表空間校驗。實際測試的時候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過壞頁，就可以跳過校驗，然后重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復(fù)后非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節(jié)省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理后，感覺共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢。
臨時冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然后讓 MySQL 正常關(guān)閉，重新啟動就可以正常啟動了。但是實際測試發(fā)現(xiàn)，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
MySQL 隨著版本不停迭代，崩潰的現(xiàn)象越來越少，也越來越隱蔽。
一旦遇到生產(chǎn)環(huán)境上的 MySQL 崩潰，就需要保留現(xiàn)場信息，供分析用。雖然 MySQL 的 error log 中會打印部分信息，但對于比較隱蔽的崩潰，往往顯得力不從心。
通過開啟操作系統(tǒng)級別、放開用戶限制、啟用 MySQL 參數(shù)三個步驟，我們啟用了 MySQL 的 coredump 功能，使得 MySQL 崩潰時留下了足夠的線索。
對于復(fù)雜崩潰的分析，還是需要將 coredump 交給專業(yè)的研發(fā)工程師手里，或者提交給 MySQL 開發(fā)團(tuán)隊。
不過不管是什么場景，能提供一份 coredump，所有技術(shù)人員都會感謝你的。
重慶分公司
重慶分公司
