从 x86 ELK 迁移到信创可观测平台：数据迁移清单与国产数据库适配

信创迁移的三个真实难点

很多团队以为信创改造就是「把软件装到国产服务器上」。实际落地时，真正卡人的是三件事：历史数据怎么搬、数据库换成国产后兼容性如何、新旧系统并行期间怎么不丢数据。本文按这三件事拆开讲。

第一件事：历史数据迁移

日志和链路数据量大，直接全量搬运不现实。建议分层处理：

1. 热数据（近 30 天）：通过迁移工具按天回放，导入新平台，保证近期排查能力不断档。
2. 温数据（近 1 年）：做聚合归档，只保留关键索引，按需回迁。
3. 冷数据（1 年以上）：留在旧集群只读访问，随旧系统自然退役。

迁移前先做一次数据盘点：单日日志量、峰值 QPS、需要保留的字段。这些数字决定迁移窗口和资源投入。回放时注意按时间顺序导入，避免乱序写入影响查询索引；大文件建议切分后多线程并发回放，同时观察目标库写入压力，别把新库压垮。

第二件事：国产数据库适配

炬鲸 OBSERVE 使用 MySQL 协议，可对接：

• OceanBase（MySQL 模式）：改连接串即可，应用零改动。
• openGauss / 达梦：通过 MySQL 兼容层接入，需做一次 SQL 方言兼容性测试。

适配清单：

| 检查项 | 说明 |
| --- | --- |
| 连接协议 | 确认走 MySQL 协议还是需兼容层 |
| 索引与分区 | 时序数据建议按天分区，验证分区裁剪是否生效 |
| 事务隔离 | 高并发写入下的隔离级别与锁行为 |
| 备份恢复 | 国产库的物理备份/恢复脚本跑通一次 |

SQL 方言测试不用太复杂：挑平台里最常用的几十条查询（日志检索、聚合、分页、时间范围），逐条在国产库上跑一遍，重点看函数差异（日期函数、字符串函数）和 LIMIT 分页写法是否一致。

第三件事：双轨运行与切流

不要一次性切干净。建议：

1. 双写阶段：日志同时写旧 ELK 和新平台，跑 2-4 周，对比查询结果和告警一致性。
2. 灰度切流：按服务或按租户逐步把查询流量切到新平台。
3. 回退预案：保留旧集群至少一个季度，确认新平台稳定后再下线。

双写阶段最怕两套系统结果对不上。建议抽几个固定的排查场景（按 trace id 查、按关键词查、按时间范围聚合），每天在两边跑同一组查询，对比结果条数和关键字段，出现差异先定位是采集、解析还是索引的问题。

迁移后的验收

• 全量日志检索、链路追踪、告警规则三项自检通过
• 数据完全落在内网，无外发连接
• 权限、审计、多租户隔离满足等保要求
• 高峰时段写入不积压、查询不超时

信创迁移的终点不是「能跑起来」，而是「跑得和原来一样稳，甚至更好」。