OB 社区版 4.x 运维开发建议

对于大部分公司而言，运维部门属于成本中心，是个很重要但是不一定得到足够投入保障。中小企业的数据库运维很多还是借助第三方服务商完成。国产数据库的运维服务目前是由原厂和三方服务共同保障的，不过长期下去随着原厂投入的减少，其质量曲线也很可能会回归到传统数据库的老路上。作为运维人员，尽量规范操作规避最坏的情形发生。

下面是 OB 社区版 4.x 版本生产环境的运维开发相关的个人建议。

• ⭐️版本低于 4.2.1 的一定要升级到 4.2.1 版本。 高于这个版本的，那就等下一个 LTS 版本 4.2.5 。
• ⭐️一定要做物理备份，备份介质通常是 NAS 提供的 NFS 。
• ⭐️一定要做备租户，备租户在独立的集群。
• 使用 OCP 替代 OBD 运维 OB 集群。OCP 的安全性、便利性都要好很多，也是 OB 相比其他厂商产品的优势之一。
• OCP 里业务 SQL 性能下降（抖动）的告警可能会非常多，如果排除一切可能原因后还无解，可以考虑关闭租户的统计信息动态采集（租户变量 optimizer_dynamic_sampling）。设计上说是统计信息收集不影响性能，实际观察下来好像不全是这样。
• 如果是有大数据量的 INSERT INTO ... SELECT ，建议用并行 DML（hint: enable_parallel_dml parallel(8)
  ）。如果条件允许还可以用 OB 的旁路写入功能（hint: append
  ）。
• obdumper 和 obloader 可以作为 OMS 迁移数据的辅助，特别是静态大表数据从传统数据库迁移到 OB 或者 OB 之间迁移。不过最近的 obdumper 和 obloader 不同版本的小问题可能会有一些。如果一个版本运行报错，可以考虑换一个版本试试。如果是业务数据加载依赖 obloader，一个版本测试通了就不要轻易换版本。
• obloader 的旁路导入功能性能非常好，35 亿的表导入十几分钟就完成了。可以直连 OBServer 旁路导入或者通过 ODP 导入（要求 ODP版本 4.3.0+，目前这个版本还不是稳定版本）。
• OB 的日志（observer.log）刷的挺快的，查问题尽量及时收集日志。过了一天才看日志可能日志就没了。社区版的 obdiag 工具收集日志非常方便。不管看不看得懂日志，先收集备份相关 OB 日志。
• OB 的全链路诊断（show trace
  ）在诊断各个环节延时方面很有用，特别是证明网络方面的延时问题。当执行时间大头在 SQL 解析或执行上时，才是分析 SQL 执行计划和调优的时候。
• 传统业务表的索引很多不合理。大量单列索引、重复度高的组合索引等，以及分区表上的全局索引，加上 SQL 很复杂，都是导致性能不好的原因。优化性能得从业务逻辑实现方法和表的索引梳理上开始。
• OB 环境尽量配置开发环境、测试环境和生产环境。有条件的可以准备一个准生产环境。业务发布验证从测试环境开始，然后是生产环境。
• OB 环境、租户很多，或者用户很多的时候，可以借助 ODC 做好数据库开发、测试的项目管理，做好生产环境的 SQL 审核和权限管控。

前面⭐️标示的三个建议，如果有一个不满足，则有一定的风险。如果三个都不满足，那就非常危险。一旦碰到了集群层面的 BUG 导致整体宕机还拉不起来的时候，那很可能万劫不复了。我就碰到一个社区版客户掉进坑了。熬了半个夜晚帮把集群给拉起来了，又熬了一个夜晚把数据逻辑迁移到 4.2.1 版本。

其他说多了都是泪。

大家还有什么好的经验，欢迎留言交流。