OCP托管的obproxy组件为何没有像observer一样有二次重启的过程呢?

[DBRE]

在OCP平台部署observer的过程中，发现日志里有observer二次启动的过程，如下图：

于是去扩容obproxy的的日志里寻找，却没有obproxy进程restart的流程，请问这个是有何考虑吗？

不重启obproxy的话，obproxy进程会带很多启动参数的

于是按照observer二次重启的方法，也对obproxy进行了restart，发现访问这个obproxy也是正常，请问这种obproxy二次重启是否标准操作呢？

[obpilot]

obproxy 和 observer 一样，第一次启动的时候参数指定很多，启动成功后参数就持久化到参数文件中了（etc/observer.config.bin 和 etc/obproxy.config.bin ）中。

obproxy 跟 observer 不一样的地方是它只负责 SQL 路由。虽然路由面临的挑战场景也很复杂， 但跟 observer 要干的事情相比还是很简单的，所以 obproxy 启动成功就能用，不需要重启再验证（当然重启一次也无妨）。

第三 ocp部署的obproxy 启动时还会有个守护进程 obproxyd，如果 obproxy 进程挂了，守护进程会自动拉起 obproxy 进程。

为什么 observer 没有守护进程呢。推测是因为 observer 如果挂了，需要dba 去主动拉起。拉不起来的时候需要分析原因。这个是数据库进程，如果有守护进程，搞不好就在那频繁的拉起和挂了（假设已经碰到问题了）。每挂一次就会生成一个跟ob内存差不多大的core文件，这个磁盘可受不了（没有那么多的空间）。所以，ob挂了，需要dba介入处理。 obproxy 太简单，没有那么多风险，挂了就拉起来。当然，如果拉不起来也是要介入处理的。