记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事情蛮大的，还是要慎重再慎重，表示线上频繁崩溃很绝望，记录一下引以为戒。

文章目录

从崩溃到崩溃

排查手段