摘要:MySQL服務不斷的在crash,並且備機與主機的現象一樣,打印如下日誌:。5、通過history命令分析root用戶操作記錄,發現用戶使用fio命令對/dev/vdb磁盤(/data卷所在的磁盤)直接進行壓測,壓測有隨機寫、順序寫,而不是寫/data目錄:。

在雲主機的日常運維工作中,我們的工程師經常會遇到用戶上報的文件丟失類問題,原因多種多樣,這些問題對用戶造成了或大或小的困擾。現將其中較典型的場景梳理出來,希望能夠幫助大家規避掉這些風險,防止重複踩坑。

場景一:雲主機重啓後文件丟失

  • 現象:

    用戶上報:我的雲主機重啓後,上面存放的數據怎麼沒了,是不是雲主機有問題啊?!

  • 分析:

    與用戶溝通後確認,是用戶存儲在/dev目錄下面的文件不見了。很明顯,用戶數據存儲在文件系統類型爲tmpfs的/dev目錄,tmpfs文件系統默認存儲在內存中而非持久化的磁盤,所以重啓主機後數據丟失。

  • 解析:

    1、何爲tmpfs?

    tmpfs是一種基於內存的臨時文件系統,數據存儲在ram中,性能非常好。

    2、Linux系統有哪些tmpfs?

    /dev、/dev/shm、/sys/fs/cgroup、/run/user/0等,tmpfs文件系統默認爲內存總大小的一半。通過df 命令可以看到哪些卷是tmpfs文件系統(Filesystem列顯示爲tmpfs):

  • 建議:
    1、tmpfs只用於程序/應用的緩存;
    2、不建議將數據放在tmpfs中(除非可承受數據丟失的風險)。

場景二:誤執行rm命令

  • 現象:

    用戶上報:雲主機重啓後ping不通,或者系統一些服務啓動不了,系統關鍵文件丟失等等。

  • 分析:
    1、通過虛擬化的控制檯看到,OS卡在開機界面並且報大量的命令不存在;
    2、掛載鏡像進入系統後,通過less /root/.bash_history查看用戶的操作記錄,可能看到rm -rf / 、rm -rf 、rm -rf . /*(點號與斜槓之間有空格)、rm -rf ./ 等之類的命令,導致大量的系統目錄及文件被刪除掉;
    3、執行rpm -Va |grep miss 命令校驗丟失的系統文件(對於不是通過rpm包安裝的文件無法校驗)。

  • 建議:

    1、慎重使用rm命令,尤其時帶上-r 及-f 參數時; 可以加上-i參數進行刪除確認;

    2、出現誤操作時,要第一次時間停掉磁盤的寫入,再想辦法恢復,避免被刪除文件的磁盤空間被覆蓋;

    3、對於刪除的系統文件,可以從其他正常的系統通過拷貝的方式還原;

    4、對於一些系統文件或配置文件,還可以通過yum reinstall 包名/yum update 包名 命令重新安裝/升級安裝來還原。

場景三:文件系統損壞(FIO)

  • 現象:

    用戶上報:

    在雲主機上運行的 MySQL數據庫異常。
  • 分析:
    1、通過監控看到雲主機的IOWAIT比較高,懷疑和IO限制有關:

2、放開雲主機磁盤限制後,仍然出現異常;MySQL服務不斷的在crash,並且備機與主機的現象一樣,打印如下日誌:

3、DBA定位,反饋 MySQL的數據文件有問題。
4、在備機上發現,mysql 數據文件所在卷的文件系統有異常並且異常比較嚴重,在該捲上創建創建文件也會失敗:

5、通過history命令分析root用戶操作記錄,發現用戶使用fio命令對/dev/vdb磁盤(/data卷所在的磁盤)直接進行壓測,壓測有隨機寫、順序寫,而不是寫/data目錄:

6、MySQL主節點也有執行相同的 fio 操作,由於fio是繞過文件系統層直接對塊設備進行操作,磁盤的真實數據已經被覆蓋,導致文件已經嚴重破壞,MySQL數據庫無法解析錯誤的數據文件,從而crash。

7、2臺MySQL主機的/data卷數據已經不可靠,需要重新格式化/data卷,並通過備份節點進行恢復數據。

  • 建議:
    1、生產環境要慎用 fio 工具,應該在上線前進行壓測;

    2、使用 fio 命令時,—filename 參數一定不要直接指定塊設備(如/dev/sda、/dev/vdb等),而要指定一個普通文件,可以先touch一個空文件,再指定這個文件名。

測試完成後,再刪除該文件即可,不然會佔用 -size 參數所指定的空間。

場景四:文件系統損壞(DD)

  • 現象:
    用戶上報:雲主機文件訪問異常。

  • 分析:
    1、雲主機數據捲上的文件無訪問,並且ls也異常,報【Structure needs cleaning】錯誤:

2、通過dmesg及 /var/log/messages日誌文件看到有大量xfs文件系統的報錯:

3、通過history命令分析root用戶操作記錄,發現root用戶有使用dd 命令對 /dev/vdb 磁盤(/data卷所在的磁盤)直接進行壓測,對/dev/vdb磁盤寫零:

  • 建議:
    1、生產環境要慎用 dd 工具,應該在上線前進行壓測;

    2、使用 dd 命令時 of 參數一定不要直接指定塊設備(如/dev/sda、/dev/vdb等)要指定一個普通文件。

    如下:

場景五:數據盤被誤刪除

  • 現象:
    用戶上報:雲磁盤被誤刪除。

  • 分析:
    1、登錄雲門戶查看雲磁盤的刪除時間,由於雲資源是延遲一段時間再刪除的,短時間內還可以找回被刪除的資源:

2、在虛擬化控制檯,確認磁盤是否已經刪除(State狀態要爲Ready):

3、如果尚未刪除,可以將雲磁盤重新attach到主機;
4、在雲門戶同步雲磁盤信息。

  • 建議:

    1、雲磁盤的刪除操作請謹慎,誤刪後數據真得無法恢復;

    2、刪除操作前先確認:

    A. 在主機上通過lsof -n、df  -h、lvs/pvs/vgs、lsblk等工具確認磁盤是否在使用、是否用於擴容的卷;

    B. 對於非用於擴容的卷,確認後,先umount卷、並且清除/etc/fstab中掛載點的信息;

    C. 用於擴容的卷無法直接刪除,刪除會導致原卷出現異常;

    3、出現誤操作時,要第一時間聯繫恢復,否則磁盤會被物理清理。

本文作者:
姚琦:平安科技系統運營部平安雲運營組,經理,領導團隊負責平安雲應用主機的運維工作。
馮明:平安科技系統運營部平安雲運營組,雲計算運維專家,擅長解決Linux OS及計算虛擬化問題。

本文轉自公衆號平安智能運營 WiseOPX。

關於平安智能運營WiseOPX: 平安智能運營WiseOPX是平安集團雲上應用全生命週期運維管理解決方案及平臺,它以數字化經營爲本,融合了平安多年豐富的運營管理思想及最佳實踐,實現多雲管理、雲上應用的高效交付、日常全棧運維、安全合規、業務運營統一管理。

在智能化運維發展的浪潮下,平安運維人積極推行運維全棧線上化、自動化、智能化探索,WiseOPX作爲其豐富實戰經驗的智慧結晶,爲金融業務IT運營提供可快速複製、高效落地的解決方案。

傳統運維已死?運維的出路在哪裏?來 GNSEC 2020 線上峯會看看大廠是怎麼做的。

近期好文:

運維工程師的“打怪升級”,你需要這份 GTD 全面指南

運維平均月薪竟不足1W?公有云市場份額:阿里、騰訊、電信佔前三;華爲關閉私有云意欲何爲?| 一週IT資訊

助力企業轉型,您需要這份調查問卷 | 有獎大調查

“高效運維”公衆號誠邀廣大技術人員投稿,

投稿郵箱:[email protected],或添加聯繫人微信:greatops1118.

點擊閱讀原文,立即報名 GNSEC 2020 線上峯會

點個“在看”,一年不宕機

相關文章