OPPO《业务恢复时长缩短10+mins:OPPO数据库可靠性提升实践》

如何获得讲师PPT：

扫码关注公众号，后台回复「Q106」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

我们可以首先观察历史监控曲线，特别是七天和一天的数据。如果在这两个时间段内，CPU的利用率始终保持在10%以下，那么可以考虑降低其规格。

关于节点数的确定，我们之前（2023年以前）为了完成跨地方高层切换，默认设置了四个节点，其中A级房和B级房各两个。但随后发现，B级房的两个节点中，有一个并未得到充分利用，这主要是因为它被用作备份。而在A级房中，一个节点作为主库，另一个则用于业务读取和故障切换。因此，我们可以考虑去掉多余的节点。

此外，我们还需要考虑在三个节点的情况下，是否有可能减少到两个节点。以某个节点为例，尽管其流量很小，但如果三个节点导致成本过高，而两个节点在满足主节点故障时能够快速扩容的情况下，那么两个节点是完全足够的。

至于配套的自动化监控，我们目前使用的是开源的采集程序，而存储则采用了OPPO自研的、兼容普罗米修斯的组件TS。当业务申请集群时，用户能够查看到该集群的所有监控信息。

这个可以看下我分享的相关文档，其中京东云的部分写得相当出色。特别是关于德鲁伊的部分，它详细分享了与MySQL相关的内容，并清晰解释了相关的连接词和参数。

不，域名并不负责四层或七层的处理，它的主要任务仅是解析请求中的域名，并将其转换为对应的IP地址。这样，应用就能够直接与后端进行交互了。

这是肯定的。如果业务方仅配置了一个节点的IP，那么一旦该节点的IP出现故障，这个MongoDB与其自身的高可用运行对业务方来说将完全失去作用。因此，为确保业务的连续性和稳定性，建议业务方进行更全面的IP配置和故障恢复策略的制定。

不会，因为我们的agent只在Java程序首次启动时发挥作用。一旦Java程序完全运行起来，agent将停止执行任何操作。

本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。