OceanBase几个常见问题及排查思路

第一种情况：某一台observer挂掉，数据库异常

OceanBase采用的的是多副本集群模式，在不同的zone里面有不同的server，每个zone里面的server是互相备份的。上层是通过slb来分发所以，当其中一台server挂掉的时候，会对业务产生什么影响呢？

制造现象：50用户并发某查询交易时，kill掉某一台（业务所在的observer跟业务不再的observer）observer。

登录到业务所在的ob服务器执行以下命令：

预期影响：TPS先掉为0，1分钟内恢复正常，存在业务失败。

监控发现：TPS先掉为0，40秒后恢复正常。失败238笔。

登录到业务不在的observer执行以下命令：

预期影响：对系统没有影响。

监控发现：交易TPS和响应时间无明显变化

恢复手段：查看9台observer的进程，找出挂掉的observer，并使用admin用户将observer启动。执行命令如下：

2、服务器层面占用cpu，数据库异常

制造现象：将业务所在的observer上的服务器cpu打满。

登录到业务所在的observer上的服务器运行脚本，脚本内容如下：

预期影响：TPS下降，并且服务器cpu利用率高。

监控发现：TPS由700下降至550，OB CPU利用率90%，保持平稳

恢复手段：可以使用Linux命令找出当前数据库占用CPU较多的进程，判断是否重要，将其杀死

3、服务器层面打满磁盘，数据库异常演练

制造现象：将observer所在服务器的磁盘写满

登录到observer服务器执行命令：

预期影响：TPS降低为0交易持续报错。

监控发现：TPS由700下降为0，磁盘满后交易持续报错共失败3014笔，交易性能大幅波动

恢复手段：发生这种的影响主要来源于两个地方，如果这台机器上只装了ob以及ob相关的组件的话，写满磁盘要么是数据文件，要么是日志文件，如果是数据文件，那么没办，只能扩充资源，如果是日志文件，找到对应目录，删除多余日志文件。

4、数据库中存在并发大量烂sql，数据库异常

制造现象：某正常业务正常运行，这时候并发一个sql比较烂的业务。

预期影响：正常业务TPS下降，并且可能存在失败现象。

监控发现：批量发起1000个数据库并发操作，交易TPS立即由700下降至150，同时批量查询超时失败。

恢复手段：sql烂是数据库的通病，我们可以根据show processlist;查看当前数据库当前正在执行的sql，找出执行时间比较久的。然后对其优化，然后根据OceanBase自带的视图：gv$sql,gv$sql_audit来看数据库之前执行过什么的慢sql对其优化。

5、业务突然增大，并且扩容observer，数据库异常

制造现象：某业务突然增加50用户量。之后调整该租户的cup：alter resource pool xxx_poll unit C12_unit;。

预期影响：并发数据量会产生TPS以及响应时间的上涨，扩充资源会发生抖动，TPS上升，RT下降

监控发现：增加用户TPS由700上升至800，交易响应时间由0.070上升至0.095秒。扩容资源发生一点点抖动，TPS恢复至800，RT时间恢复到0.095秒。

恢复手段：无

6、模拟数据库服务器网络故障。

制造现象：将observer的2882跟2881端口禁掉

执行命令：

预期现象：TPS会出先下降，然后恢复正常，交易会报错。

监控发现：TPS先下降一半，1分钟后恢复正常，交易报错持续4分钟。

恢复手段：