數(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磁盤陣列作為共享磁盤，F(xiàn)C磁盤整陣列就是光纖磁盤陣列;

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

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

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

　　這時候進(jìn)行多路徑聚合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è)務(wù)系統(tǒng)測試

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

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

　　采用fsck的方法進(jìn)行修復(fù)，

　　fsck -a /dev/mapper/mpatha

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

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

　　第五步：問題排查

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

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

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

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

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

　　第六步：問題根因

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

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

　　systemctl isolate multi-user.target

　　如果需要每次重啟都進(jìn)入純命令行模式，可以使用如下命令：

　　systemctl set-default multi-user.target

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

　　小結(jié)

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

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）