蓝光盘库媒资系统一例典型故障分析与思考

吕 剑

（扬州广播电视传媒集团（总台），江苏 扬州 225000）

1 媒资系统现状

扬州广播电视总台（以下简称总台）老媒资系统于2013 年建成，离近线存储采用昆腾i6000 磁带库，使用至今共计有1 000 余盘LTO6 数据流磁带，另有集群网络附属存储（Network Attached Storage，NAS）在线存储约130 TB，共存储约11 万多条视音频片段，23 万多条编目片段子类信息。2022 年初，总台投资建设了新智慧标签式媒资系统，投入使用至今已超过半年。新媒资系统离近线存储采用了ODS-L30M 专业蓝光盘存储柜，可容纳近线光盘30 盘，单光盘容量为5.5 TB，同时更换了近线集群NAS 存储，转而使用总台私有云存储池中的划定空间，容量和性能都得到了有效提升。数据库系统由原来的Oracle 更新为MySQL，部署于微服务架构的虚拟服务器上。新旧媒资系统之间建有数据接口，可自动将原素材和相应元数据迁移入新媒资系统，部分新媒资素材在下载到非编的时候在可扩展标记语言（Extensible Markup Language，XML）文件交互步骤报错，导致下载流程失败。经过分析测试，发现部分元数据信息里包含特殊字符，是新旧两家厂商对这些特殊字符不同认定导致，经过修改后可正常迁移入库。

2 故障现象

新媒资系统运行半年以来一直较为稳定，但从2023 年5 月起会偶发回迁任务缓慢、大量任务卡死现象，系统提示所需素材没做过归档，无法调用带库回迁系统，有时还会出现媒资系统登录异常，提示系统内部错误，如图1 所示。技术人员现场重启数据库有时可以恢复业务，但系统仍不稳定。2023年6 月，系统又出现回迁失败现象，于是总台要求集成厂商远程技术支持。技术人员访问数据库里的蓝光盘库设备信息表时发现表为空，没有数据，只能从2023 年5 月17 日的数据备份里将设备信息表与蓝光盘匣信息表数据进行还原。完成后系统暂时恢复正常。技术人员将一些回迁不了的素材反馈给集成公司，进行蓝光盘匣扫描、工具修复与相关数据完善，期间再次发现蓝光盘匣数据丢失，集中在编号12741 等5 盘蓝光盘。次日下午14:30 左右，现场媒资再次出现访问异常，同时发现MySQL 数据库服务器节点1 异常，重启后恢复使用，但后续几天又陆续出现部分回迁任务失败现象，问题仍未根本解决。

图1 系统回迁失败素材定位

3 故障处理和成因分析

技术人员怀疑系统数据库仍存在问题，于是仔细分析数据库日志，查询MySQL 日志和应用日志发现MySQL 连接查询数据返回异常，使用连接工具查看数据库表，发现存在多个表返回数据异常，但这些表未全部使用5 月17 日备份数据进行恢复数据后自行恢复数据，说明只是当时MySQL 数据库返回数据异常，并不代表出现丢失数据。图2 的业务日志截图显示查询表数据出现信息返回报错，导致服务运行异常。

查看业务日志和MySQL 日志，发现之前还有多次报错，验证失败只是MySQL 返回数据异常，而非数据库丢失数据现象，当时直接采用了重启Hive 集群服务和数据库服务器的方式进行验证，重启之后业务恢复正常。技术人员更加确定MySQL 数据库本身无丢失数据现象，只是客户端连接之后MySQL返回数据异常。图3 的业务日志截图显示媒资核心Hive 连接MySQL 数据库返回数据失败。

图3 Hive 连接MySQL 数据库失败

技术人员查看MySQL 日志，发现MySQL 一节点压力过大引起阻塞，重启一节点MySQL 服务，短期内业务可恢复正常，但一段时间后，该现象仍会复现。图4 的MySQL 日志截图显示读取数据库信息超时，造成阻塞。

图4 读取数据库信息超时

后经排查系统结构发现，数据库访问缓慢且偶尔出现拥堵现象是因为该项目在实施部署时方案不合理，将操作系统、业务服务和数据库服务部署在一组raid1 串行SCSI（Serial Attached SCSI，SAS）磁盘上。系统压力不大时，这个弊端并不明显。但系统运行了近一年后，业务系统和数据库数据越来越多，SAS 盘吞吐数据出现响应瓶颈，从而引起近段时间数据访问异常情况[1-2]。按照高性能数据库服务要求，需将操作系统、业务服务、数据库服务进行分离磁盘部署，系统盘采用SAS 盘，业务服务和数据库服务采用固态硬盘（Solid State Disk，SSD）盘更为合理[3-4]。

另排查到，MySQL允许数据包大小（max_allowed_packet）值过小，当时设置为4 MB，而在实际使用中，当出现存储数据包含图片或地址过长时据太大，就会导致存入数据被限制掉，系统报max_allowed_packet错误。对此，应将该值从4 MB 增加到256 MB，如图5 所示。

图5 max_allowed_packet 值修改截图

本次故障处理采用5 月17 日备份的蓝光盘匣信息数据进行恢复数据。此过程中恢复的表包含蓝光盘库系统信息表、迁移驱动器信息表及磁带信息表等3 张表数据。现场抢修工程师主观认为该3 张表记录了蓝光盘柜和蓝光盘匣的基础信息，系统投入运行后这些信息就不再更新。实际上还原数据中有5 盒蓝光盘匣信息与实际情况不符，所以恢复过程完成之后，这5 盒蓝光盘匣被重置为空白盘。实际上这5 盒蓝光盘中有大量数据，后续又出现用户想回迁数据时部分任务失败，因为恰好读取到这5 盒蓝光盘匣。更严重的是，后续几天，新的数据又被写入这5 盘蓝光盘，导致原有的媒资归档数据被覆盖。

4 解决方案

4.1 媒资主数据库与业务分离方案

为解决当前故障，需要把操作系统和业务、数据库服务进行分离。操作系统保持在双SAS 盘组成的RAID1 上，业务与数据库服务以及对应的数据迁移至数据盘[5-6]。为保证数据安全性，加快数据访问的响应速度，需再配置两块SSD 盘组成RAID1作为数据盘使用，如图6 所示。具体步骤如下。

图6 媒资主数据库与业务分离配置截图

首先，暂停媒资所有服务后，将3 套节点的工作目录重命名，将挂载的Hive 节点重命名。

其次，将数据（App 安装包、log 日志、date 数据文件）全部复制到另一块数据盘上。

再次，将单机的MySQL 数据库备份，集群的MySQL 数据库备份，待各项指标正常后将单机的最新数据还原至集群的MySQL 里。

最后，开启集群，验证流程，并核实数据库与集群节点的压力情况。

4.2 AKDB 数据库切回方案

AKDB 数据库记录蓝光盘匣的相关信息，库体文件和日志文件体积相对较小，备份和还原难度不大。具体步骤如下。

停止AKDB 数据库服务，将挂载的Hive 节点与数据库分离；将当前在用的AKDB 数据库做一个完全备份，放在本地，以备回切失败时回到现场；将判定可用的最近日期的AKDB 数据库备份文件导入并还原；推起数据库服务并挂载Hive 节点；找一些媒资库中较新的素材，验证是否能定位到正确的蓝光盘匣，如果不行，则需要回到起始步骤并寻找更新的备份文件重新导入并验证，直至成功。

4.3 被覆盖的蓝光盘匣数据恢复方案

经过检查，原来写入这5 盒蓝光盘匣的素材约2 610 条，包含电视剧、新闻、综艺等。其中大部分素材可由老媒资系统或磁带重新上载归档。部分较新件原始素材主要在非编系统中，早被用户删除，而媒资在线存储使用的利旧存储空间紧张，策略设置成3 天后删除，目前已没有办法手动进行恢复。通过与蓝光盘库厂家技术工程师联系，必须将5 盒蓝光盘匣返厂进行数据修复，修复成本估计近4 万元。

总台将蓝光盘寄回后，厂家反馈国内维修站缺少相应设备，需将蓝光盘匣寄回日本总部修复。考虑需要修复的数据中有本地新闻等一些敏感素材，总台要求光盘不能出国，必须在国内寻找可信任的公司修复，且与总台签订数据保密责任书，这无疑增加了数据恢复的难度。经多方问询国内数据恢复公司暂无修复此类专业蓝光盘匣的先例，数据恢复工作陷入困境。技术人员在与前期节目部门协商后采取应急方案，将丢失的那部分素材用存储在媒资浏览发布区的中码流素材顶替，先支撑起下载制作流程，但最终的成片画质会相对较差。经过近半个月的寻找后，总台与国内一家数据恢复公司签订了保密维修协议，最终数据得以恢复。

5 结语

此次故障处理暴露出总台在系统搭建和维护中的一些问题。首先，在方案设计和试运行时，未严格遵循数据库服务设计规范，根据将来的数据库服务压力载荷做相应的软、硬件配置，造成了上线之初可正常运行，随着数据量和访问压力增大，系统出现缓慢、拥堵情况；其次，在维护抢修过程中，技术人员临场判断不准，对所还原数据库信息不够熟悉，造成蓝光盘内数据被覆盖；最后，从系统层面看，系统缺乏完善的监控机制，在出现访问压力过载时不能及时监控报警，导致技术人员每次都要现场抢修，在紧张环境下难免会产生误判，这也是其他技术系统可能共同存在的隐患。解决问题的关键在于发现和布设各类关键技术监控指标，尽早发现，防范掉下数字悬崖。