今天用navicat鏈接數(shù)據(jù)庫發(fā)現(xiàn)總是提示：2003 -can`t connect to mysql server on "localhost"(10061 :Unknown error")錯(cuò)誤，無法連接到本地?cái)?shù)據(jù)庫。

難道navicat故障了么，果斷開啟cmd窗口用命令行執(zhí)行MySQL登錄命令來登錄（mysql -u root -p）來登錄。結(jié)果也出現(xiàn)錯(cuò)誤提示應(yīng)用程序無法正常啟動(dòng)0xc00007b，這個(gè)錯(cuò)誤告訴我們系統(tǒng)運(yùn)行庫文件丟失或損壞了。

? 既然是文件損壞那我們就來修復(fù)，我們不知道是什么文件受損了，所以這里我們用DirectX來修復(fù)（DirectX是一款專用于修復(fù)系統(tǒng)異常的工具，可自動(dòng)更新C++組件且完美修復(fù)0xc000007b問題異常）。DirectX提示c++元件異常，根據(jù)圖中提示拓展至增強(qiáng)版進(jìn)行修復(fù)試試。

? 修復(fù)之后重啟電腦即可修復(fù)0xc000007b問題，再次使用cmd窗口嘗試登錄MySQL還是提示無法鏈接localhost（忘了截圖...）。于是我刪了mysql-8.0.15-winx64目錄下的data文件夾，重新執(zhí)行初始化命令：mysqld --initialize --console然后再重啟MySQL服務(wù)（重啟命令：net start mysql）。

?重新初始化之后會(huì)重新生成隨機(jī)密碼，別忘了拷貝下來。登錄之后記得馬上修改登錄密碼，修改密碼可以參考文章：MySQL實(shí)戰(zhàn)001：Windows安裝配置MySQL8.0圖解及問題解決。終于搞定了，navicat可以正常登錄了！

?總結(jié)：

使用過程中難免會(huì)遇到一些問題，記錄下來下次就可以快速的解決了。以上內(nèi)容是小編給大家分享的【MySQL實(shí)戰(zhàn)002：Windows系統(tǒng)下解決mysql無法啟動(dòng)的問題】，希望對(duì)大家有所幫助，如果大家有任何疑問請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。

啟動(dòng)運(yùn)行于linux環(huán)境上的mysql數(shù)據(jù)庫失敗，導(dǎo)致業(yè)務(wù)無法正常進(jìn)行。對(duì)此問題進(jìn)行排查，手動(dòng)去啟動(dòng)mysql數(shù)據(jù)庫。啟動(dòng)過程如下：

1.進(jìn)入mysql數(shù)據(jù)庫所在的linux用戶

su - ebaserdb

2.使用tailf查看mysql數(shù)據(jù)庫啟動(dòng)過程中的日志

tailf /home/ebaserdb/log/mysqld1.log

3.使用啟動(dòng)命令來執(zhí)行mysql數(shù)據(jù)庫的啟動(dòng)

mysql.server start

然后觀察數(shù)據(jù)庫日志在啟動(dòng)過程中的數(shù)據(jù)：

2018-12-04T06:27:41.500719Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.
2018-12-04T06:27:41.500828Z 0 [Note] /home/ebaserdb/bin/xpecd (mysqld 5.7.21) starting as process 34409 ...
2018-12-04T06:27:41.561369Z 0 [Note] InnoDB: PUNCH HOLE support not available
2018-12-04T06:27:41.561439Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-12-04T06:27:41.561451Z 0 [Note] InnoDB: Uses event mutexes
2018-12-04T06:27:41.561461Z 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
2018-12-04T06:27:41.561469Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-12-04T06:27:41.562166Z 0 [Note] InnoDB: Number of pools: 1
2018-12-04T06:27:41.562310Z 0 [Note] InnoDB: Using CPU crc32 instructions
2018-12-04T06:27:41.570436Z 0 [Note] InnoDB: Initializing buffer pool, total size = 640M, instances = 1, chunk size = 128M
2018-12-04T06:27:41.620035Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-12-04T06:27:41.627187Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-12-04T06:27:41.651735Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2018-12-04T06:27:41.655370Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 6780558137 and the end 6780557824.
2018-12-04T06:27:41.655408Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2018-12-04T06:27:41.955745Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2018-12-04T06:27:41.955783Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-12-04T06:27:41.955793Z 0 [ERROR] Failed to initialize builtin plugins.
2018-12-04T06:27:41.955798Z 0 [ERROR] Aborting
2018-12-04T06:27:41.955813Z 0 [Note] Binlog end
2018-12-04T06:27:41.955873Z 0 [Note] Shutting down plugin 'MyISAM'
2018-12-04T06:27:41.955895Z 0 [Note] Shutting down plugin 'CSV'
2018-12-04T06:27:41.956982Z 0 [Note] /home/ebaserdb/bin/xpecd: Shutdown complete

可以看到ERROR的報(bào)錯(cuò)

這種報(bào)錯(cuò)多是因?yàn)闄C(jī)器異常斷點(diǎn)導(dǎo)致InnoDB的事務(wù)日志文件ib_logfile0、ib_logfile1出現(xiàn)問題，在該日志比較大（比數(shù)據(jù)文件大）的時(shí)候可以用來恢復(fù)數(shù)據(jù)（成功率沒保證）。

因此本問題的處理方式是將這兩個(gè)日志文件重命名或者移到其他目錄中：

mv /home/ebaserdb/data/redo/ib_logfile0 /home

mv /home/ebaserdb/data/redo/ib_logfile1 /home

然后重新啟動(dòng)數(shù)據(jù)庫，就不會(huì)出現(xiàn)報(bào)錯(cuò)。

注意：

如果可能需要數(shù)據(jù)恢復(fù)，那么只需要保留原始的InnoDB日志文件以便后面需要的恢復(fù)操作。 如果MySQL服務(wù)器在上述過程之后成功啟動(dòng)，并且所有數(shù)據(jù)都完好無損，則可以丟棄原始的InnoDB日志文件，mysql成功啟動(dòng)之后會(huì)重新創(chuàng)建適當(dāng)大小的新InnoDB日志文件。