OceanBase 社区版 MES/OEE/ 追溯 全套最佳实践(三节点生产专用,精简落地版)

一、硬件 & 系统部署规范(3 台标准集群)

1. 服务器配置(MES 长期亿级流水、十年数据)

最低生产:16 核 64G 1TB SSD/NVMe;推荐 32 核 128G 2TB NVMe

  • 系统盘独立 240G,数据盘、Clog 事务日志盘分开挂载,不要共用一块盘
  • 万兆内网交换机,三台机器同机房、不同空开供电,避免同时断电
  • 备份单独一台机械盘 / NFS 共享存储,不和 OB 数据盘混跑

2. 操作系统选型(放弃 CentOS7/8)

首选 Rocky Linux 9 / Anolis OS 9,长期安全更新,完美适配 OB 4.3 社区版

必改内核参数(每台机器)

plaintext

vm.swappiness=0          # 禁用交换分区,避免数据库换页卡顿
vm.max_map_count=655350
fs.file-max=655360
net.ipv4.tcp_syncookies=1

关闭防火墙、SELinux,关闭 NUMA 平衡;磁盘挂载barrier=0提升写入性能。

3. 集群部署标准

  1. 版本固定 4.3.x LTS,不使用测试预览版
  2. 3 台机器 1 个 Zone,三副本(Paxos 强一致),禁止单机单副本生产
  3. 统一用 OBD 部署,安装 ODP(OBProxy)做连接负载均衡,应用全部连 ODP,不直连 2881 端口
  4. 配套 OCP Express 图形监控,实时看 CPU、IO、副本状态、慢 SQL
  5. 一台独立中控机存放备份、监控、运维脚本,不和数据库节点混部

二、租户资源规划(MES 专用 MySQL 租户)

  1. 只创建MySQL 模式租户,社区版无 Oracle 模式能力
  2. 资源单元规格(64G 机器示例):max_cpu=14,memory_size=48G,预留系统内存
  3. 内存分配黄金比例:
    • ob_memstore_size(MemTable 写入内存):总租户内存 30%
    • block_cache(数据缓存):50%
    • row_cache(行缓存,近一年工单热点):15%
  4. 关闭租户外键约束,业务代码做关联校验(社区版外键性能差、易锁)
  5. sql_mode 修改,适配 MES 时间字段:去掉NO_ZERO_DATE,允许 NULL 替代0000-00-00

三、表结构 & 分区核心规范(十年亿级流水不卡顿)

1. 所有流水大表强制按月 RANGE 分区(过站、采集、不良记录)

sql

CREATE TABLE station_record (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    line_id INT,
    work_order VARCHAR(32),
    output INT,
    create_time DATETIME
) PARTITION BY RANGE (TO_DAYS(create_time)) (
PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01'))
);
  • 单分区控制 50~100GB,不要单分区堆积数亿行
  • 每年提前预创建下一年分区,定时脚本自动生成

2. 索引设计

  1. 主键必须自增 BIGINT;高频查询组合建复合索引(产线 + 工单 + 时间)
  2. 禁止单表超过 5 个索引,大批量采集写入会严重变慢
  3. 历史冷分区可删除无用索引,减少合并开销

3. SQL 开发强制规范(规避分布式慢查询)

  1. 查询必须携带时间条件,触发分区裁剪,禁止不带时间全表扫描
  2. 分页禁止limit 100000,20,使用主键游标分页
  3. 批量更新 / 删除按分区拆分执行,不一次性操作全表
  4. 禁止跨大量分区 JOIN;OEE 统计走内置列存 HTAP 并行计算
  5. 批量插入用INSERT INTO ... VALUES(),(),()批量语法,提升写入吞吐

4. 冷热数据处理(十年追溯)

过期年份分区直接DROP PARTITION,秒级清理,不逐行 DELETE;

需要归档则先分区级备份再删除,避免产生大量碎片。

四、HTAP 实时分析(MES OEE 大屏标配)

  1. 租户开启列存副本,同步行存数据,报表查询不抢占报工写入 IO
  2. 实时产量、不良率、OEE 聚合查询不加业务锁,前台产线无延迟
  3. 凌晨低峰执行分区合并、统计信息收集,白天限制 Compaction 磁盘 IO

五、高可用 & 故障处理(三台机器硬盘损坏 / 断电)

  1. 默认三副本,写入必须 2 副本落盘才算提交,单台断电业务不停
  2. 关键参数:server_permanent_offline_time = '4h',给维修换盘留出充足时间
  3. 单台仅换硬盘(IP 不变): 停止节点→格式化挂载同路径→清空数据目录→重启 observer,集群自动同步副本修复
  4. 整机报废换新机器: 删除旧故障节点→新机 OBD 扩容加入集群→后台自动均衡补齐三副本
  5. 三台机器不要同时断电;机房配备 UPS,避免瞬时跳闸触发大量 SSTable 碎片

六、备份恢复策略(十年海量数据,速度快、不卡产线)

1. 架构

开启日志归档 + 租户物理备份,存储到独立 NFS

  • 日志归档 2 分钟自动同步,RPO<5 分钟,支持任意时间点恢复 PITR
  • 每周凌晨一次全量备份;日常自动增量备份,只同步变更数据
  • 备份优先读取 Follower 副本,完全不占用主节点业务 IO,白天也能跑备份

2. 自动清理

脚本定时删除 3 个月前增量、1 年前全量,控制备份磁盘容量

3. 恢复优势

分布式并行恢复,按分区并发加载;相比单机 PG 恢复速度提升 5~10 倍

七、日常运维最佳实践

  1. 每日凌晨定时收集统计信息,避免优化器选错执行计划
  2. 监控重点指标:副本健康状态、磁盘使用率、慢 SQL、Compaction 堆积、归档延迟
  3. 慢 SQL 阈值设 1 秒,每日导出审计报表,优化追溯查询
  4. 版本升级走 OBD 灰度滚动升级,业务零中断
  5. 扩容仅新增 OB 服务器,自动均衡分区,不用改代码、迁移历史数据
  6. 每月做一次故障演练:手动下线一台节点,验证集群自动切换、副本自愈

八、性能调优核心要点

  1. 高并发设备采集写入:调大 MemTable,拆分批量写入批次
  2. 报表查询慢:确认开启列存、强制分区裁剪、加复合索引
  3. 磁盘 IO 高:限制白天合并任务并发,冷数据分区减少索引
  4. 热点分区:按月分区天然打散,极端热点增加二级 Hash 分区

九、避坑红线(MES 绝对不能做)

  1. 不用 CentOS Stream、Windows 生产跑 OB 集群
  2. 不单机单副本存放十年追溯数据,断电极易元数据损坏
  3. 大表不做时间分区,单分区堆积上亿行,查询、备份持续恶化
  4. 日志盘、数据盘共用一块硬盘,断电易同时损坏
  5. 业务直连 OB 2881 端口,不使用 ODP 负载均衡
  6. 频繁批量 DELETE 历史数据,改用 DROP 分区
  7. 长期只剩两副本运行,再坏一台直接集群只读、产线停报工

极简一句话落地总结

3 台 Rocky9 + NVMe 分开数据 / 日志盘 + MySQL 租户按月分区 + 三副本 Paxos + 日志归档增量备份 + ODP 负载均衡,这套规范跑 MES 十年亿级追溯、OEE 统计,稳定、断电自愈、备份快、无需手动分表。

阅读剩余
THE END