记ARDB频繁崩溃错误

背景:在业务规模对db没有高需求的情况下使用redis存储其实是有些浪费的,毕竟内存要比磁盘贵很多。这也就是我们要把部分db从redis迁移到ardb的原因,虽然在上线之前已经做了内网测试以及线上部分db替换测试,但是并未触发ardb的这个bug,其中线上测试了30d,现在分析看来,应该是因为线上替换的这个db压力不高,用户基数小。记录一下,关于ardb可以看这里

从崩溃到崩溃

  • 现象:
    直接dwon掉,ardb的log没有记录
  • 系统日志:
    在/var/log/message中有如下日志

    kernel: [20758288.642227] rocksdb:bg7[25004]: segfault at 7f370d206e7e ip 0000000000578f46 sp 00007f370fbfde90 error 6 in ardb-server[400000+423000]

  • addr2排查:

    1
    2
    [root@ip-10-33-4-xx ardb-0.9.4]# addr2line -e ./src/ardb-server 0000000000578f46
    /opt/ardb/ardb-0.9.4/src/db/rocksdb/rocksdb_engine.cpp:222
  • 撸源码报错段

    1
    2
    3
    4
    5
    if (n > 0 && NULL != buffer)
    {
    buffer[n] = 0;
    LOG_WITH_LEVEL(level, "[RocksDB]%s", buffer);
    }
  • 撸代码修改为(rocksdb_engine.cpp:222修改源代码中这个文件的222行)
    说明:这个代码经经沟通是一个临界问题,在win下和Linux下表现是不一样的,截取字符串存在问题,下面给出的是修复代码。因我并不懂C++所以理解有限,欢迎更正补充。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    if (n > 0)
    {
    if (n >= buf_len)
    {
    buffer[buf_len-1] = 0;
    LOG_WITH_LEVEL(level, "[RocksDB]%s", buffer);
    }
    else {
    buffer[n] = 0;
    LOG_WITH_LEVEL(level, "[RocksDB]%s", buffer);
    }
    }
  • 总结
    这里我个人说三点对于更换DB的注意事项

    1.数据备份,并需考虑备份数据对于前后DB的可用性,如Redis的备份数据ARDB是否可用,是否备份还原策略可以准确顺利
    2.对新DB的调研一定要充分。如系统平台、程序版本、底层依赖、bug反馈修复速率
    3.新DB是否有大量的成功企业实践,实践企业反馈
    4.回滚至原有DB方案制定、可行性实践及分析
    5.新DB备份策略

排查手段

这里介绍一下Linux下的core dump机制

1.什么是core dump
当程序运行的过程中异常终止或崩溃,操作系统会将程序当时的内存状态记录下来,保存在一个文件中,这种行为就叫做Core Dump(中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”,但实际上,除了内存信息之外,还有些关键的程序运行状态也会同时 dump 下来,例如寄存器信息(包括程序指针、栈指针等)、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的,因为对于有些程序错误是很难重现的,例如指针异常,而 core dump 文件可以再现程序出错时的情景。
2.如何产生core dump
参考这个吧http://www.cnblogs.com/hazir/p/linxu_core_dump.html
这个链接包含了详细信息,不过为了方便我还是在下面啰嗦一下

  • 如何开启core dump

    1
    2
    3
    4
    5
    #立即开启,重启后失效
    ulimit -c unlimited
    #修改配置,重启后生效
    vim /etc/security/limits.conf #添加如下行
    * soft core unlimited
  • 如何查看调试core文件

    1
    gdb core_demo core_demo.core.24816

以上,换DB事情蛮大的,还是要慎重再慎重,表示线上频繁崩溃很绝望,记录一下引以为戒。