服务热线
189-2347-0832

中兴S385 您当前所处位置: 首页 > 新闻资讯 > 行业技术

版本问题导致Metro1000掉电后配置丢失

发布时间:2018-04-19

问题描述

B市电信一基站用Metro1000设备,在频繁掉电后网元配置丢失。


告警信息

本站无告警,对端站点有hp-uneq告警。另外,在该网元发生故障当天,对端站点发生了90余次R_LOS告警,可以判断该网元当时电源环境非常恶劣。


处理过程

将该网元的配置通过网管重新下载后,恢复正常。


根因

从黑匣子bb0.log(见附件)中可以看出该网元是在22点刚过丢的配置(网元时区为北京时区,所以bb0记录的时间为网元时间+8),(22:00加8小时=凌晨06:00)配置就已经丢失,板位信息只剩下主控上自动创建的四个板位,需从数据库中恢复的板位全部丢失。


什么会在这个时间点出现配置丢失呢?在网元时间22点时网元会做的一个动作就是数据库自动备份(M1000V3网元默认会在每天的22点时进行数据库自动备份操作)。OSP平台专家分析的结论如下:从重现出来的故障来看,并非所有数据库配置都丢失,只有产品数据库(包括逻辑板位、交叉等配置数据库)丢失了,而平台的数据库并未丢失;这是由于网元掉电起来,刚好碰到网元自动备份时间22:00,触发OSP平台对所有数据库进行自动备份,备份的流程是mdb -> drdb -> tdrdb -> fdb,网元启动时,OSP备份任务(优先级150)先进行,做 mdb -> drdb -> tdrdb ,空数据备份到 tdrdb,此时产品任务开始创建产品数据库(优先级130,优先级比OSP备份任务高,因此会抢占OSP备份任务),此时fdb还有数据,产品创建数据库从fdb中恢复出配置,然后会即时备份到drdb,因此drdb有数据;最后OSP备份任务继续执行,将空配置的tdrdb备份到fdb中,因此fdb数据丢失,并且仅仅是产品数据库丢失。


建议与总结

1、保持机房电源稳定,避免设备频繁掉电;

2、研发修改版本,修改产品软件中创建数据库的时机,不要在任务中创建,将其前移至assemble里完成。(OSP数据库备份任务是要等assemble完成以后才会开始运行,此时保证所有数据库都已创建恢复完成,这样就可以彻底解决此问题) 解决问题的软件版本预计在2011年12月前发布。