記一次MySQL生產環境故障處理

2021-10-06 04:18:38 字數 2734 閱讀 1144

在2023年5月15日 凌晨三點,某台生產環境的mysql程序異常,無法連線到資料庫。早上上班開始排查問題並解決。

伺服器是windows環境,設定每2天凌晨自動重啟主機,mysql以及其他應用都設定了自動啟動。

注:以下所有步驟需要先關閉使用到資料庫的應用程式。

檢視系統的計畫任務,發現剛好15日凌晨3點執行了啟動任務。上次執行結果這一欄顯示0x40010004

在cn.bing.com上搜尋「windows 0x400100004」找到一篇文章

文章是這樣回答的

【文章大意是說這個錯誤很可能是在windows系統重啟的時候發生。當windows系統要重啟時,它會嘗試以一種很友好的方式關閉正在執行中的程式,如果某個程式拒絕被關閉則會返回乙個錯誤碼0x40010004。】

d:

\company\software\mysql

d:\company\software\mysql\connector.c++

1.1d:

\company\software\mysql\connector.j 5.1

d:\company\software\mysql\connector.net 6.9

d:\company\software\mysql\connector.odbc 5.3

d:\company\software\mysql\mysql connector.c 6.1

d:\company\software\mysql\mysql documentation 5.7

d:\company\software\mysql\mysql notifier 1.1

d:\company\software\mysql\mysql router 2.1

d:\company\software\mysql\mysql server 5.7

d:\company\software\mysql\mysql utilities 1.6

d:\company\software\mysql\mysql workbench 6.3 ce

d:\company\software\mysql\samples and examples 5.7

外部資料目錄:

d:\nannar\database\mysql_data\my.ini

d:\nannar\database\mysql_data\data

這裡就很奇怪了:

1、系統重啟前mysql的執行一直是正常的。

2、此前mysql一直是從d:\nannar\database\mysql_data\my.ini讀取執行配置,從d:\nannar\database\mysql_data\data讀取資料檔案。

3、故障出錯時提示mysql從d:\company\software\mysql\mysql server 5.7\data下面讀取資料檔案。

由於對mysql底層不夠了解,此處果斷解除安裝mysql改用解壓免安裝的版本。

解除安裝後,將d:\nannar\database\mysql_data更名為d:\nannar\database\mysql_data-back

mysql重灌後目錄結構如下:

免安裝解壓目錄

d:\company\software\mysql-5.7.18-winx64

my.ini位置

d:\company\software\mysql-5.7.18-winx64\my.ini

資料庫目錄(在my.ini中配置)

d:\company\database\mysql_data

環境變數

mysql_home指向d:\company\software\mysql-5.7.18-winx64

%mysql_home%\bin;追加到path中。

重新建立資料庫 (不需要建表)

關閉資料庫net stop mysql57

從舊的資料目錄中拷貝資料檔案到新的資料目錄中。

例如庫名是monitor

d:\company\database\mysql_data-back\data\monitor

拷貝到d:\company\database\mysql_data\monitor

啟動資料庫net start mysql57

重新啟動資料庫net start mysql57,**發現又出現了「mysql57 服務無法啟動,服務沒有報告任何錯誤。」**
資料庫是修復了,但是我刪除的是系統重做日誌呀,乙個天大的問題是:我的資料到底有沒有丟失?

於是趕緊用客戶端連線伺服器,然後查詢業務表的資料,檢視最新的資料時間。資料時間戳停留在2020-05-14 23:57.00.000 。根據業務性質判斷,我的資料是物聯網感測器資料,這個時間點已經接近裝置下線時間。因此即使從這個時間段往後有業務資料,這些業務資料即使丟失也是不會有影響的。

此次故障能及時發現得益於系統監控及釘釘機械人訊息推送。

由於缺乏對資料庫的深度理解,最終只能採取放棄部分資料的方式使生產環境的應用能夠盡快恢復使用。

本次生產故障處理是否有丟失資料?丟失了多少筆資料?如何從redo檔案中提取資料?這是一系列需要思考和研究的問題!

記一次Docker生產環境搭建

伺服器使用的是阿里雲ecs標準型,普通的centos7和docker環境映象。docker映象源在docker.io在國外速度很慢,所以配置下加速,daocloud加速位址 選擇linux加速配置命令,複製貼上執行,直接執行可能有個逗號錯誤,我是碰到了。解決方法是修改daemon.json檔案 cd...

記一次生產故障,nginx503

問題概述 web頁面進行login操作,控制台報503 系統版本 centos 6.8 服務架構 前端兩個nginx 伺服器,可外網,中間兩台業務伺服器,使用docker起兩組服務 後端3臺redis 哨兵 和三颱mongo 問題分析 由控制台報503可知是伺服器內部原因,可能是網路或者服務方面。解...

記一次manila故障

排查過程 1.檢視manila的日誌,api.log scheduler.log share.log,排程日誌最具參考性,但是顯示建立成功 實際狀態為creating 排到share時出現大量報錯 get all share usage failed 2.檢查後端儲存,節點均正常 排查過程 1.關閉...