呂 劍

（揚州廣播電視傳媒集團（總臺），江蘇 揚州 225000）

1 媒資系統(tǒng)現(xiàn)狀

揚州廣播電視總臺（以下簡稱總臺）老媒資系統(tǒng)于2013 年建成，離近線存儲采用昆騰i6000 磁帶庫，使用至今共計有1 000 余盤LTO6 數(shù)據(jù)流磁帶，另有集群網(wǎng)絡(luò)附屬存儲（Network Attached Storage，NAS）在線存儲約130 TB，共存儲約11 萬多條視音頻片段，23 萬多條編目片段子類信息。2022 年初，總臺投資建設(shè)了新智慧標簽式媒資系統(tǒng)，投入使用至今已超過半年。新媒資系統(tǒng)離近線存儲采用了ODS-L30M 專業(yè)藍光盤存儲柜，可容納近線光盤30 盤，單光盤容量為5.5 TB，同時更換了近線集群NAS 存儲，轉(zhuǎn)而使用總臺私有云存儲池中的劃定空間，容量和性能都得到了有效提升。數(shù)據(jù)庫系統(tǒng)由原來的Oracle 更新為MySQL，部署于微服務架構(gòu)的虛擬服務器上。新舊媒資系統(tǒng)之間建有數(shù)據(jù)接口，可自動將原素材和相應元數(shù)據(jù)遷移入新媒資系統(tǒng)，部分新媒資素材在下載到非編的時候在可擴展標記語言（Extensible Markup Language，XML）文件交互步驟報錯，導致下載流程失敗。經(jīng)過分析測試，發(fā)現(xiàn)部分元數(shù)據(jù)信息里包含特殊字符，是新舊兩家廠商對這些特殊字符不同認定導致，經(jīng)過修改后可正常遷移入庫。

2 故障現(xiàn)象

新媒資系統(tǒng)運行半年以來一直較為穩(wěn)定，但從2023 年5 月起會偶發(fā)回遷任務緩慢、大量任務卡死現(xiàn)象，系統(tǒng)提示所需素材沒做過歸檔，無法調(diào)用帶庫回遷系統(tǒng)，有時還會出現(xiàn)媒資系統(tǒng)登錄異常，提示系統(tǒng)內(nèi)部錯誤，如圖1 所示。技術(shù)人員現(xiàn)場重啟數(shù)據(jù)庫有時可以恢復業(yè)務，但系統(tǒng)仍不穩(wěn)定。2023年6 月，系統(tǒng)又出現(xiàn)回遷失敗現(xiàn)象，于是總臺要求集成廠商遠程技術(shù)支持。技術(shù)人員訪問數(shù)據(jù)庫里的藍光盤庫設(shè)備信息表時發(fā)現(xiàn)表為空，沒有數(shù)據(jù)，只能從2023 年5 月17 日的數(shù)據(jù)備份里將設(shè)備信息表與藍光盤匣信息表數(shù)據(jù)進行還原。完成后系統(tǒng)暫時恢復正常。技術(shù)人員將一些回遷不了的素材反饋給集成公司，進行藍光盤匣掃描、工具修復與相關(guān)數(shù)據(jù)完善，期間再次發(fā)現(xiàn)藍光盤匣數(shù)據(jù)丟失，集中在編號12741 等5 盤藍光盤。次日下午14:30 左右，現(xiàn)場媒資再次出現(xiàn)訪問異常，同時發(fā)現(xiàn)MySQL 數(shù)據(jù)庫服務器節(jié)點1 異常，重啟后恢復使用，但后續(xù)幾天又陸續(xù)出現(xiàn)部分回遷任務失敗現(xiàn)象，問題仍未根本解決。

圖1 系統(tǒng)回遷失敗素材定位

3 故障處理和成因分析

技術(shù)人員懷疑系統(tǒng)數(shù)據(jù)庫仍存在問題，于是仔細分析數(shù)據(jù)庫日志，查詢MySQL 日志和應用日志發(fā)現(xiàn)MySQL 連接查詢數(shù)據(jù)返回異常，使用連接工具查看數(shù)據(jù)庫表，發(fā)現(xiàn)存在多個表返回數(shù)據(jù)異常，但這些表未全部使用5 月17 日備份數(shù)據(jù)進行恢復數(shù)據(jù)后自行恢復數(shù)據(jù)，說明只是當時MySQL 數(shù)據(jù)庫返回數(shù)據(jù)異常，并不代表出現(xiàn)丟失數(shù)據(jù)。圖2 的業(yè)務日志截圖顯示查詢表數(shù)據(jù)出現(xiàn)信息返回報錯，導致服務運行異常。

查看業(yè)務日志和MySQL 日志，發(fā)現(xiàn)之前還有多次報錯，驗證失敗只是MySQL 返回數(shù)據(jù)異常，而非數(shù)據(jù)庫丟失數(shù)據(jù)現(xiàn)象，當時直接采用了重啟Hive 集群服務和數(shù)據(jù)庫服務器的方式進行驗證，重啟之后業(yè)務恢復正常。技術(shù)人員更加確定MySQL 數(shù)據(jù)庫本身無丟失數(shù)據(jù)現(xiàn)象，只是客戶端連接之后MySQL返回數(shù)據(jù)異常。圖3 的業(yè)務日志截圖顯示媒資核心Hive 連接MySQL 數(shù)據(jù)庫返回數(shù)據(jù)失敗。

圖3 Hive 連接MySQL 數(shù)據(jù)庫失敗

技術(shù)人員查看MySQL 日志，發(fā)現(xiàn)MySQL 一節(jié)點壓力過大引起阻塞，重啟一節(jié)點MySQL 服務，短期內(nèi)業(yè)務可恢復正常，但一段時間后，該現(xiàn)象仍會復現(xiàn)。圖4 的MySQL 日志截圖顯示讀取數(shù)據(jù)庫信息超時，造成阻塞。

圖4 讀取數(shù)據(jù)庫信息超時

后經(jīng)排查系統(tǒng)結(jié)構(gòu)發(fā)現(xiàn)，數(shù)據(jù)庫訪問緩慢且偶爾出現(xiàn)擁堵現(xiàn)象是因為該項目在實施部署時方案不合理，將操作系統(tǒng)、業(yè)務服務和數(shù)據(jù)庫服務部署在一組raid1 串行SCSI（Serial Attached SCSI，SAS）磁盤上。系統(tǒng)壓力不大時，這個弊端并不明顯。但系統(tǒng)運行了近一年后，業(yè)務系統(tǒng)和數(shù)據(jù)庫數(shù)據(jù)越來越多，SAS 盤吞吐數(shù)據(jù)出現(xiàn)響應瓶頸，從而引起近段時間數(shù)據(jù)訪問異常情況[1-2]。按照高性能數(shù)據(jù)庫服務要求，需將操作系統(tǒng)、業(yè)務服務、數(shù)據(jù)庫服務進行分離磁盤部署，系統(tǒng)盤采用SAS 盤，業(yè)務服務和數(shù)據(jù)庫服務采用固態(tài)硬盤（Solid State Disk，SSD）盤更為合理[3-4]。

另排查到，MySQL允許數(shù)據(jù)包大?。╩ax_allowed_packet）值過小，當時設(shè)置為4 MB，而在實際使用中，當出現(xiàn)存儲數(shù)據(jù)包含圖片或地址過長時據(jù)太大，就會導致存入數(shù)據(jù)被限制掉，系統(tǒng)報max_allowed_packet錯誤。對此，應將該值從4 MB 增加到256 MB，如圖5 所示。

圖5 max_allowed_packet 值修改截圖

本次故障處理采用5 月17 日備份的藍光盤匣信息數(shù)據(jù)進行恢復數(shù)據(jù)。此過程中恢復的表包含藍光盤庫系統(tǒng)信息表、遷移驅(qū)動器信息表及磁帶信息表等3 張表數(shù)據(jù)?，F(xiàn)場搶修工程師主觀認為該3 張表記錄了藍光盤柜和藍光盤匣的基礎(chǔ)信息，系統(tǒng)投入運行后這些信息就不再更新。實際上還原數(shù)據(jù)中有5 盒藍光盤匣信息與實際情況不符，所以恢復過程完成之后，這5 盒藍光盤匣被重置為空白盤。實際上這5 盒藍光盤中有大量數(shù)據(jù)，后續(xù)又出現(xiàn)用戶想回遷數(shù)據(jù)時部分任務失敗，因為恰好讀取到這5 盒藍光盤匣。更嚴重的是，后續(xù)幾天，新的數(shù)據(jù)又被寫入這5 盤藍光盤，導致原有的媒資歸檔數(shù)據(jù)被覆蓋。

4 解決方案

4.1 媒資主數(shù)據(jù)庫與業(yè)務分離方案

為解決當前故障，需要把操作系統(tǒng)和業(yè)務、數(shù)據(jù)庫服務進行分離。操作系統(tǒng)保持在雙SAS 盤組成的RAID1 上，業(yè)務與數(shù)據(jù)庫服務以及對應的數(shù)據(jù)遷移至數(shù)據(jù)盤[5-6]。為保證數(shù)據(jù)安全性，加快數(shù)據(jù)訪問的響應速度，需再配置兩塊SSD 盤組成RAID1作為數(shù)據(jù)盤使用，如圖6 所示。具體步驟如下。

圖6 媒資主數(shù)據(jù)庫與業(yè)務分離配置截圖

首先，暫停媒資所有服務后，將3 套節(jié)點的工作目錄重命名，將掛載的Hive 節(jié)點重命名。

其次，將數(shù)據(jù)（App 安裝包、log 日志、date 數(shù)據(jù)文件）全部復制到另一塊數(shù)據(jù)盤上。

再次，將單機的MySQL 數(shù)據(jù)庫備份，集群的MySQL 數(shù)據(jù)庫備份，待各項指標正常后將單機的最新數(shù)據(jù)還原至集群的MySQL 里。

最后，開啟集群，驗證流程，并核實數(shù)據(jù)庫與集群節(jié)點的壓力情況。

4.2 AKDB 數(shù)據(jù)庫切回方案

AKDB 數(shù)據(jù)庫記錄藍光盤匣的相關(guān)信息，庫體文件和日志文件體積相對較小，備份和還原難度不大。具體步驟如下。

停止AKDB 數(shù)據(jù)庫服務，將掛載的Hive 節(jié)點與數(shù)據(jù)庫分離；將當前在用的AKDB 數(shù)據(jù)庫做一個完全備份，放在本地，以備回切失敗時回到現(xiàn)場；將判定可用的最近日期的AKDB 數(shù)據(jù)庫備份文件導入并還原；推起數(shù)據(jù)庫服務并掛載Hive 節(jié)點；找一些媒資庫中較新的素材，驗證是否能定位到正確的藍光盤匣，如果不行，則需要回到起始步驟并尋找更新的備份文件重新導入并驗證，直至成功。

4.3 被覆蓋的藍光盤匣數(shù)據(jù)恢復方案

經(jīng)過檢查，原來寫入這5 盒藍光盤匣的素材約2 610 條，包含電視劇、新聞、綜藝等。其中大部分素材可由老媒資系統(tǒng)或磁帶重新上載歸檔。部分較新件原始素材主要在非編系統(tǒng)中，早被用戶刪除，而媒資在線存儲使用的利舊存儲空間緊張，策略設(shè)置成3 天后刪除，目前已沒有辦法手動進行恢復。通過與藍光盤庫廠家技術(shù)工程師聯(lián)系，必須將5 盒藍光盤匣返廠進行數(shù)據(jù)修復，修復成本估計近4 萬元。

總臺將藍光盤寄回后，廠家反饋國內(nèi)維修站缺少相應設(shè)備，需將藍光盤匣寄回日本總部修復?？紤]需要修復的數(shù)據(jù)中有本地新聞等一些敏感素材，總臺要求光盤不能出國，必須在國內(nèi)尋找可信任的公司修復，且與總臺簽訂數(shù)據(jù)保密責任書，這無疑增加了數(shù)據(jù)恢復的難度。經(jīng)多方問詢國內(nèi)數(shù)據(jù)恢復公司暫無修復此類專業(yè)藍光盤匣的先例，數(shù)據(jù)恢復工作陷入困境。技術(shù)人員在與前期節(jié)目部門協(xié)商后采取應急方案，將丟失的那部分素材用存儲在媒資瀏覽發(fā)布區(qū)的中碼流素材頂替，先支撐起下載制作流程，但最終的成片畫質(zhì)會相對較差。經(jīng)過近半個月的尋找后，總臺與國內(nèi)一家數(shù)據(jù)恢復公司簽訂了保密維修協(xié)議，最終數(shù)據(jù)得以恢復。

5 結(jié)語

此次故障處理暴露出總臺在系統(tǒng)搭建和維護中的一些問題。首先，在方案設(shè)計和試運行時，未嚴格遵循數(shù)據(jù)庫服務設(shè)計規(guī)范，根據(jù)將來的數(shù)據(jù)庫服務壓力載荷做相應的軟、硬件配置，造成了上線之初可正常運行，隨著數(shù)據(jù)量和訪問壓力增大，系統(tǒng)出現(xiàn)緩慢、擁堵情況；其次，在維護搶修過程中，技術(shù)人員臨場判斷不準，對所還原數(shù)據(jù)庫信息不夠熟悉，造成藍光盤內(nèi)數(shù)據(jù)被覆蓋；最后，從系統(tǒng)層面看，系統(tǒng)缺乏完善的監(jiān)控機制，在出現(xiàn)訪問壓力過載時不能及時監(jiān)控報警，導致技術(shù)人員每次都要現(xiàn)場搶修，在緊張環(huán)境下難免會產(chǎn)生誤判，這也是其他技術(shù)系統(tǒng)可能共同存在的隱患。解決問題的關(guān)鍵在于發(fā)現(xiàn)和布設(shè)各類關(guān)鍵技術(shù)監(jiān)控指標，盡早發(fā)現(xiàn)，防范掉下數(shù)字懸崖。