人大金倉KES高可用共享集群部署遇到文件系統(tǒng)損壞，該如何解決？

數(shù)據(jù)庫工程師在部署KingbaseES高可用共享集群過程時,有時候會遇到文件損壞,系統(tǒng)無法啟動的問題。作為金倉數(shù)據(jù)庫工程師的我在最近一次客戶現(xiàn)場支持過程中,也遇到了同樣的問題,經(jīng)過多輪排查,結(jié)合豐富的產(chǎn)品手冊,我最終找到了快速解決問題的路徑。在這里我將經(jīng)驗分享出來,以便更多金倉數(shù)據(jù)庫使用者查看。該客戶此前購買的國際巨頭Oracle的數(shù)據(jù)庫產(chǎn)品,現(xiàn)需要替換為金倉數(shù)據(jù)庫產(chǎn)品。根據(jù)現(xiàn)場需要,我前往項目所在地幫助客戶部署金倉KingbaseES高可用共享集群。

第一步:配置時鐘同步

時鐘同步可以采用ntpd同步,也可通過timesyncd;

采用timesyncd,需要修改

/etc/systemd/timesyncd.conf,配置時鐘同步客戶端,通過timedatectl管理;

查看命令如下:

timedatectl show-timesync;

第二步:配置共享磁盤

由于KingbaseES高可用共享集群使用多節(jié)點共享磁盤,因此需要采用DAS、NAS、SAN等存儲。本次采用FC磁盤陣列作為共享磁盤,FC磁盤整陣列就是光纖磁盤陣列;

共享磁盤客戶端制作多路徑綁定,可以提高磁盤的可用性,有效防止磁盤故障、網(wǎng)絡故障導致的數(shù)據(jù)丟失或損壞;

首先在配置安裝multipathd時,修改/etc/multipath.conf(具體配置參見其他文章,不是本文重點),systemctl restart multipathd啟動;

在FC磁盤整列服務端劃分磁盤,在磁盤客戶端(也就是數(shù)據(jù)庫服務端),執(zhí)行rescan-scsi-bus.sh后,在主機群可以找到新創(chuàng)建的盤;

這時候進行多路徑聚合multipath –v2;

查看多路徑綁定multipath –ll。

第三步:配置udev規(guī)則,固定磁盤名

01)udevadm info --query=all --name=/dev/dm-0

02)vim /etc/udev/rule.d/60-scsi.rules

03)ENV{ID_SERAIL}=="...",ENV{DM_WWN}=="..."RUN+="/bin/sh -c'mknod /dev/chmpatha b $major $minor; chmod 0644 /dev/chmpatha; rm -f /dev/block/$major:$minor; ln -s /dev/chmpatha /dev/block/$major:$ninor'"

第四步:業(yè)務系統(tǒng)測試

安裝完成后,需要進行簡單功能測試和可用性測試,以便將問題盡早解決掉。首先我和技服進行了down機、斷掉業(yè)務網(wǎng)和管理網(wǎng)、制造進程僵死等故障測試。

問題來了。在進行斷網(wǎng)的測試中,發(fā)現(xiàn)數(shù)據(jù)庫一直在不停地切換節(jié)點。查看日志,發(fā)現(xiàn)是文件系統(tǒng)損壞導致的數(shù)據(jù)庫無法啟動。

采用fsck的方法進行修復,fsck -a /dev/mapper/mpatha

但是未能修復!客戶表明2天內(nèi)必須解決。

再次梳理日志,KingbaseES集群組件在報文件系統(tǒng)異常前,沒有任何異常日志。在KingbaseES文件系統(tǒng)異常前,僅有kenel相關(guān)日志。根據(jù)一般經(jīng)驗,懷疑可能是雙掛導致的磁盤損壞。

第五步:問題排查

繼續(xù)分析集群各節(jié)點的掛載記錄,發(fā)現(xiàn)一些mpatha磁盤在系統(tǒng)重啟后,在另一節(jié)點莫名其妙的掛載上了,目前推斷可能是雙掛導致的文件系統(tǒng)損壞,但是無法繼續(xù)敲定重啟為何導致雙掛?

沒有辦法,只有將磁盤重新格式化,繼續(xù)進行復現(xiàn)測試,終于抓住了問題,在異常重啟后的機器上出現(xiàn)一條掛載記錄:

/dev/mappper/mpatha 1007G 146M 956G 1%/media/root/9g0oc559-2d0a-4e88-a1e7-1b1badc9a7

實際上磁盤在另外節(jié)點正在被數(shù)據(jù)庫管理進程使用,顯然是雙掛,那么這條掛載記錄怎么來的?

重新思考操作的每一步驟,最終發(fā)現(xiàn)了問題的根本原因:

第六步:問題根因

沒錯,是操作系統(tǒng)的自動掛載導致的雙掛問題。

于是我們將"自動掛載"選項去掉,同時為了保險起見,將數(shù)據(jù)庫服務端所在節(jié)點的圖形界面關(guān)掉,在圖形模式下使用如下命令可以切換到純命令行模式:

systemctl isolate multi-user.target

如果需要每次重啟都進入純命令行模式,可以使用如下命令:

systemctl set-default multi-user.target

徹夜鏖戰(zhàn),終于解決了文件系統(tǒng)損壞的問題,讓系統(tǒng)恢復了正常,獲得客戶高度認可,我內(nèi)心還是很高興的。

小結(jié)

如果服務器均部署在國產(chǎn)圖形化Linux操作系統(tǒng),在圖形化界面,會默認設置自動掛載。在自動掛載時數(shù)據(jù)庫實例盤雙掛,會導致文件系統(tǒng)損壞。之后,將服務器“自動掛載”取消,同時使用命令“systemctl set-default multi-user.target”設置默認為命令界面,防止誤操作。這樣就能快速恢復系統(tǒng)正常運行。

轉(zhuǎn)自：中國網(wǎng)

　　【版權(quán)及免責聲明】凡本網(wǎng)所屬版權(quán)作品，轉(zhuǎn)載時須獲得授權(quán)并注明來源“中國產(chǎn)業(yè)經(jīng)濟信息網(wǎng)”，違者本網(wǎng)將保留追究其相關(guān)法律責任的權(quán)力。凡轉(zhuǎn)載文章及企業(yè)宣傳資訊，僅代表作者個人觀點，不代表本網(wǎng)觀點和立場。版權(quán)事宜請聯(lián)系：010-65363056。

延伸閱讀