第一种情况：某一台observer挂掉，数据库异常
OceanBase采用的的是多副本集群模式，在不同的zone里面有不同的server，每个zone里面的server是互相备份的。上层是通过slb来分发所以，当其中一台server挂掉的时候，会对业务产生什么影响呢？
制造现象：50用户并发某查询交易时，kill掉某一台（业务所在的observer跟业务不再的observer）observer。
登录到业务所在的ob服务器执行以下命令：
ps -ef|grep observer;kill -9 pid预期影响：TPS先掉为0，1分钟内恢复正常，存在业务失败。
监控发现：TPS先掉为0，40秒后恢复正常。失败238笔。
登录到业务不在的observer执行以下命令：
ps -ef|grep observer;kill -9 pid预期影响：对系统没有影响。
监控发现：交易TPS和响应时间无明显变化
恢复手段：查看9台observer的进程，找出挂掉的observer，并使用admin用户将observer启动。执行命令如下：
su - admin;/bin/observer2ã 服务器层面占用cpu，数据库异常
制造现象：将业务所在的observer上的服务器cpu打满。
登录到业务所在的observer上的服务器运行脚本，脚本内容如下：
#! /bin/bash
# filename killcpu.sh
endless_loop()
{
echo -ne "i=0;
while true
do
i=i+100;
i=100
done" | /bin/bash &
}
if [ $# != 1 ] ; then
echo "USAGE: $0 <CPUs>"
exit 1;
fi
for i in `seq $1`
do
endless_loop
pid_array[$i]=$! ;
done
for i in "${pid_array[@]}"; do
echo 'kill ' $i ';';
done
#运行命令：./killcpu.sh 30
#参数位占用几颗cpu 核数预期影响：TPS下降，并且服务器cpu利用率高。
监控发现：TPS由700下降至550，OB CPU利用率90%，保持平稳
恢复手段：可以使用Linux命令找出当前数据库占用CPU较多的进程，判断是否重要，将其杀死
ps -aux | sort -k4nr | head -N3、服务器层面打满磁盘，数据库异常演练
制造现象：将observer所在服务器的磁盘写满
登录到observer服务器执行命令：
dd if=/dev/zero of=/home/admin/oceanbase/log/1.log bs=100k count=1600000预期影响：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端口禁掉
执行命令：
iptables -A INPUT -i bond0 -p tcp --dport 2882 -j DROP
iptables -A INPUT -i bond0 -p tcp --dport 2881 -j DROP
iptables -A OUTPUT -p tcp --dport 2882 -j DROP
iptables -A OUTPUT -p tcp --dport 2881 -j DROP预期现象：TPS会出先下降，然后恢复正常，交易会报错。
监控发现：TPS先下降一半，1分钟后恢复正常，交易报错持续4分钟。
恢复手段：
iptables -D INPUT 1
iptables -D INPUT 1
iptables -D OUTPUT 1
iptables -D OUTPUT 1
