连续间隔kill DSS Server进程

现象

多次kill主节点的DSS Server进程，主节点上报PANIC重启。查看日志有如下堆栈：

原因

DSS Server不提供服务的场景下，DN写DSS失败主动上报PANIC是一种主动防护手段，其目标是为了此故障不再进一步扩散，属于合理防护，但会影响用户体验。

解决方案

暂无规避方案。

故障发生后，DN重新拉起、DSS Server重新被CM拉起，则数据库可正常提供服务。但如果DSS Server被连续故障5次，并且这5次都没有被成功拉起，则DSS所在节点会被HAS剔除，剔除后不会影响后续为数据库提供服务。

以下提供辅助确认流程，只有当3种情形都满足时，才能表明触发PANIC的原因符合本文描述的场景。

（1）确认故障节点为DSS的读写节点

搜索集群中所有的节点（一般情况下为DSS Server故障所在节点），通过查找DSS Server的日志，搜索关键字：“when set main inst”，如果显示flag为2，则表示对应节点为DSS的读写节点。

搜索的日志路径为：$DSS_HOME/log/run/dssinstance.rlog（若日志已归档，则路径为dssinstance_xxx.rlog），如果读写节点为DSS Server的故障节点，则进行下一步确认，如果不是，则不属于本案例所述场景。

注意：搜索到的关键字所在的时间需要是PANIC前最近一次的日志所在节点为有效读写节点，否则为无效读写节点，不具备参考意义。

（2）确认DSS是否故障

在DSS Server故障节点中，搜索$DSS_HOME路径下startdss.log日志，查找DSS Server在PANIC前所处的状态，可查看日志中有“dssserver is offline”关键字，并且DSS Server进程在PANIC这一时间点没有被拉起。

如图所示表明此时DSS Server已经故障，无法提供服务。

（3）确认客户端因DSS Server无法提供服务导致客户端的错误

在故障节点上客户端的日志中，搜索关键字：“Dss client connet server failed”，日志路径为：$GAUSSLOG/pg_log/dss.rlog，若日志已归档，则搜索带时间戳的文件。

若存在此关键字，表明服务端确实无法提供服务，客户端的操作返回错误。