怎么解決mysql服務(wù)無法啟動(dòng)的問題

1、情況一：MySQL的錯(cuò)誤日志文件（安裝目錄\MYOA\data5\機(jī)器名.err）會(huì)記錄如下內(nèi)容：

創(chuàng)新互聯(lián)公司主要從事網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)太原,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

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

InnoDB: Error: trying to add tablespace 460 of name '.\td_oa\flow_data_35.ibd'

InnoDB: to the tablespace memory cache, but tablespace

InnoDB: 460 of name '.\td_oa\exam_data.ibd' already exists in the tablespace

解決方法：

1）剪切出安裝目錄\MYOA\data5\TD_OA的flow_data_35.ibd和flow_data_35.frm兩個(gè)文件；

2）啟動(dòng)MySQL5_OA服務(wù)，使用備份的flow_data_35.sql導(dǎo)入到TD_OA庫中。如果提示flow_data_35表已經(jīng)存在不能導(dǎo)入，則繼續(xù)按后續(xù)步驟執(zhí)行；

3）在data5下手動(dòng)建立tmp目錄；

4）使用MySQL管理工具或MySQL命令行程序在tmp下建立名稱為flow_data_35的表（包含一個(gè)字段即可）；

5）將tmp下的flow_data_35.frm和flow_data_35.ibd拷貝到安裝目錄\MYOA\data5\TD_OA目錄下；

6）在MySQL管理工具或MySQL命令行程序中，進(jìn)入TD_OA庫，使用“drop table flow_data_35;”命令清除公共表空間中殘留的flow_data_35表的相關(guān)信息；

7）進(jìn)入tmp庫，刪掉flow_data_35表；

8）使用備份的flow_data_35.sql導(dǎo)入到TD_OA庫中；

9）如果還有其他表存在該問題，可重復(fù)執(zhí)行4至8步驟。

2、情況二：MySQL的錯(cuò)誤日志文件（安裝目錄\MYOA\data5\機(jī)器名.err）會(huì)記錄如下內(nèi)容：

130409 15:54:31 [Note] Plugin 'FEDERATED' is disabled.

130409 15:54:31 InnoDB: The InnoDB memory heap is disabled

130409 15:54:31 InnoDB: Mutexes and rw_locks use Windows interlocked functions

130409 15:54:31 InnoDB: Compressed tables use zlib 1.2.3

130409 15:54:32 InnoDB: Initializing buffer pool, size = 1023.0M

InnoDB: VirtualAlloc(1086849024 bytes) failed; Windows error 8

130409 15:54:32 InnoDB: Completed initialization of buffer pool

130409 15:54:32 InnoDB: Fatal error: cannot allocate memory for the buffer pool

130409 15:54:32 [ERROR] Plugin 'InnoDB' init function returned error.

130409 15:54:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

130409 15:54:32 [ERROR] Unknown/unsupported storage engine: Innodb

130409 15:54:32 [ERROR] Aborting

解決方法：

此情況出現(xiàn)的原因是myoa\mysql5\my.ini中innodb_buffer_pool_size的值太大，OA服務(wù)器操作系統(tǒng)不支持所致。改小后再啟動(dòng)mysql5_OA服務(wù)即可，一般保持和數(shù)據(jù)庫大小一致。數(shù)據(jù)庫大小即是myoa/data5的大小。

3、情況三：mysql服務(wù)啟動(dòng)不了，事件查看器中顯示：The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.

解決方法：安裝目錄\MYOA\data5下的ibdata1、ib_logfile0、ib_logfile1文件屬性被設(shè)置為只讀導(dǎo)致，取消只讀控制，重啟mysql5_OA服務(wù)即可。

4、情況四：MySQL的錯(cuò)誤日志文件（data5\機(jī)器名.err）會(huì)記錄如下內(nèi)容：InnoDB: No valid checkpoint found.

解決方法：此問題找不到檢查點(diǎn)，數(shù)據(jù)庫是無效的，此種情況，只能用熱備份數(shù)據(jù)恢復(fù)。

5、以上四種情況，是2013版OA系統(tǒng)目前比較常見的mysql服務(wù)啟動(dòng)不了的現(xiàn)象和解決辦法，大家可作參考，其他情況的話，再具體分析處理。

6、分析思路總結(jié)：遇到mysql5_OA服務(wù)啟動(dòng)不了的情況，首先查看myoa\data5下的錯(cuò)誤日志文件，根據(jù)日志中的具體內(nèi)容進(jìn)行具體分析。

7、2013版MYSQL服務(wù)啟動(dòng)不了（可以嘗試強(qiáng)制啟動(dòng)mysql服務(wù)）方法如下：

1)打開\MYOA\mysql5\my.ini，去掉innodb_force_recovery=1前邊的注釋。

2)啟動(dòng)MySQL5_OA服務(wù)，此時(shí)MySQL處于只讀狀態(tài)，可以導(dǎo)出，不可寫入。如果仍不能啟動(dòng)，可以嘗試將innodb_force_recovery修改為2、3、4、5、6等，直到可以啟動(dòng)為止。

3)使用MySQL管理工具，將TD_OA等相關(guān)的數(shù)據(jù)庫導(dǎo)出為SQL文件。

4)停止MySQL5_OA服務(wù)，刪除TD_OA下的所有文件、ibdata1、ib_logfile0、ib_logfile1等文件。

5）打開\MYOA\mysql5\my.ini，在innodb_force_recovery=1前邊加上#號(hào)，將該項(xiàng)注釋掉。

6)啟動(dòng)MySQL5_OA服務(wù)，然后導(dǎo)入此前備份的SQL文件。

7)檢查數(shù)據(jù)庫，將無法通過該方法恢復(fù)的數(shù)據(jù)表，通過之前自動(dòng)備份的SQL文件進(jìn)行恢復(fù)。

MySQL之MGR成員故障導(dǎo)致整個(gè)集群不可用的問題排查分析

2020-08-14

集群有三個(gè)成員memberA、B、C成，其中memberB意外故障停掉了，然后memberA 執(zhí)行stop group_replication退去集群.此時(shí)整個(gè)集群不可用了（不能更新數(shù)據(jù)）。

集群中唯一剩余的成員memberC上看到的成員狀態(tài)為：

但是memberA看到的狀態(tài)為：

查看最后的存活的memberC的錯(cuò)誤日志發(fā)現(xiàn)：

"Plugin group_replication reported: 'This server is not able to reach a majority of members in the group. This server will now block all updates. The server will remain blocked until contact with the majority is restored. It is possible to use group_replication_force_members to force a new group membership.' "

大概意思是當(dāng)前的服務(wù)沒法獲取到成員的投票數(shù)，當(dāng)前服務(wù)將會(huì)阻塞所有的更新，直到能夠獲取到投票數(shù)。可以使用group_replication_force_members 來強(qiáng)制組成一個(gè)新的組。

開始認(rèn)為這是MGR功能的一個(gè)bug，不過后來想想這樣的設(shè)定也是合理的，因?yàn)槿绻钱?dāng)前的服務(wù)成員自身網(wǎng)絡(luò)或其他問題導(dǎo)致的無法與其他成員的通信成功，那么這樣的情況下這種設(shè)定也是合理的，因?yàn)椴荒茏屗詣?dòng)重新組成一個(gè)組，否則就會(huì)可能出現(xiàn)多個(gè)重復(fù)的組。對(duì)于為什么組成員A執(zhí)行stop group_replication后，剩余的memberC的視圖中memberA還是online狀態(tài)，可能是因?yàn)閙emberB已經(jīng)unreachable,所以memberC去請(qǐng)求是否同意memberA退去時(shí)沒有得到結(jié)果，一直阻塞等待造成的。此時(shí)，memberA的退出結(jié)果應(yīng)該是無法多數(shù)投票通過的，因此memberA的退出結(jié)果應(yīng)該是失敗的。查看memberA的error日志，結(jié)果確實(shí)如此：

解決的方法是memberC也執(zhí)行stop group_replication停掉這個(gè)組，再重新組成一個(gè)新的組。

此時(shí)memberA再重新加入就成功了：

結(jié)果：

以此類推，當(dāng)有多個(gè)server組成的group而有多數(shù)成員已經(jīng)意外故障時(shí)，導(dǎo)致整個(gè)組的停止更新，目前想到的解決的方法就是停掉現(xiàn)在的組，重新組成新的組。

ps:

增加Group Replication System Variables中g(shù)roup_replication_member_expel_timeout的大小，可以避免網(wǎng)絡(luò)問題或執(zhí)行事務(wù)慢造成的錯(cuò)誤驅(qū)逐。

技術(shù)分享 | MySQL 啟動(dòng)失敗的常見原因

MySQL 啟動(dòng)失敗的最常見的原因有兩類，分別是無法訪問系統(tǒng)資源和參數(shù)設(shè)置錯(cuò)誤造成的，下面分別分析如下。

MySQL 不能訪問啟動(dòng)需要的資源是造成而 MySQL 無法啟動(dòng)的一個(gè)常見原因，如：文件，端口等。由于 linux 中用于啟動(dòng) mysqld 進(jìn)程的 mysql 用戶通常是不能登陸的，可以使用類似下面的命令檢查文件的訪問權(quán)限。

找出問題后，修改對(duì)應(yīng)文件或目錄的權(quán)限或?qū)僦骱笸ǔ？梢越鉀Q問題。但有時(shí) mysql 用戶有訪問文件和目錄的權(quán)限，但仍然會(huì)被拒絕訪問，例如下面這個(gè)例子：

測(cè)試說明 mysql 用戶有這個(gè)目錄的訪問權(quán)限，但創(chuàng)建文件還是失敗，這種情況讓很多人困惑，這個(gè)時(shí)候通常是 mysqld 進(jìn)程的訪問被 linux 的 selinux 或 apparmor 給阻止了，大家可以看到創(chuàng)建的表不是在 mysql 的默認(rèn)目錄下面，因此 selinux 或 apparmor 的 policy 里面沒有包含這個(gè)目錄的訪問權(quán)限，此時(shí)只要對(duì)應(yīng)的修改 policy 就行了，當(dāng)然把 selinux 或 apparmor 停了也行。

有時(shí)雖然對(duì)系統(tǒng)資源有訪問的權(quán)限，但系統(tǒng)資源已經(jīng)被占用：

這個(gè)故障產(chǎn)生的原因是另外一個(gè) mysqld 進(jìn)程已經(jīng)啟動(dòng)并占用了對(duì)應(yīng)的文件。

參數(shù)設(shè)置錯(cuò)誤造成 MySQL 無法啟動(dòng)的原因也非常常見，此時(shí)先要檢查 MySQL 啟動(dòng)時(shí)會(huì)調(diào)用的參數(shù)，下面的命令可以查詢 MySQL 啟動(dòng)時(shí)調(diào)用參數(shù)文件的順序：

知道了 MySQL 參數(shù)文件的調(diào)用順序，我們就可以檢查對(duì)應(yīng)的參數(shù)文件，找出其中的錯(cuò)誤，如果覺得參數(shù)文件的可讀性不強(qiáng)，可以使用下面的命令顯示 mysqld 程序?qū)⒁{(diào)用的參數(shù)：

注意這個(gè)命令顯示完參數(shù)后就退出，不會(huì)真正運(yùn)行 mysqld。這個(gè)命令和 my_print_defaults mysqld 完全是等價(jià)的，只不過后者的顯示方式是一行一個(gè)參數(shù)。

然后開始對(duì)可疑的參數(shù)進(jìn)行調(diào)試，我個(gè)人喜歡加的參數(shù)和順序如下：

看這個(gè)例子：

看這個(gè)例子，我們很容易知道是需要我們同時(shí)設(shè)置參數(shù) GTID_MODE 和 ENFORCE_GTID_CONSISTENCY 同時(shí)為 on 才行。

MAC OS 下坑爹的Mysql故障

準(zhǔn)備在本地搭建一個(gè)完整的平臺(tái)，在本地調(diào)試可能比較方便些，我可以做些定制化的修改。結(jié)果發(fā)現(xiàn)，本地搭建環(huán)境會(huì)有很多坑爹的問題，各種坑，一路需要摸索著來。

我抱著絕對(duì)順利的心，啟動(dòng)服務(wù)程序，結(jié)果發(fā)現(xiàn)，坑爹，根本啟動(dòng)不了，完全懵逼不清楚情況。

以前明明可以用，現(xiàn)在居然啟動(dòng)失敗了，我擦。二臉懵逼，咋整呢？想了兩個(gè)方案，一個(gè)是在vm虛擬機(jī)下面搭建一個(gè)新的環(huán)境，第二個(gè)是在本地重新裝mysql，這樣速度最快，我也可以省事，畢竟時(shí)間挺重要的。

對(duì)于一個(gè)對(duì)技術(shù)有執(zhí)著有想法的人，明顯這兩個(gè)方案都不靠譜，辣么，只有自己研究看怎么解決問題了。首先，我翻看了下mysql錯(cuò)誤日志，默認(rèn)情況下在:

當(dāng)然，這是我的默認(rèn)路徑，對(duì)于你們自己的我就不清楚了。翻看的時(shí)候發(fā)現(xiàn)有一些提示，具體如下：

抓住最后一個(gè)tips，去搜索下了，發(fā)現(xiàn)有很多說法，在gg上找到不少的結(jié)局方式，基本都不好使。諸如以下：

坑爹啊。。。后來朋友說了一句，會(huì)不會(huì)是權(quán)限??？我就納悶了，試了一下，居然狗日的成功了。。。

碰到問題不要先重裝，或許你這次重裝后，下次還會(huì)遇到類似的問題，到那個(gè)時(shí)候就真心悲劇了。最好的辦法就是手動(dòng)嘗試解決下，說不定會(huì)有更好的結(jié)果。

mysql數(shù)據(jù)庫崩潰的原因？

MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長。另外磁盤 IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開發(fā)庫的 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 遍。不過 MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過程。

如何跳過校驗(yàn)MySQL 5.7 下有方法可以跳過崩潰恢復(fù)時(shí)的表空間校驗(yàn)過程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過壞頁，就可以跳過校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開 N 個(gè) ibd 文件了，只需要打開一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽了姜老師講過使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。

臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過臨時(shí)修改 validate 變量值讓 MySQL 跳過表空間驗(yàn)證過程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過表空間驗(yàn)證過程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長。而以非 debug 模式運(yùn)行，則無法修改 validate 變量，想法破滅。