一份可照抄的迁移清单：从 x86 + MySQL 迁到鲲鹏/飞腾 ARM 与达梦/OceanBase，覆盖兼容性盘点、数据迁移、应用适配与性能验收。
信创迁移不是把二进制重新编译一遍那么简单，它牵扯 CPU、操作系统、数据库三层的兼容性。这篇文章给出一份可以照抄的迁移清单，覆盖从盘点、数据迁移、应用适配到验收的完整过程，附上几个我们真实踩过的坑。
信创迁移最常见的坑不是技术，是「想当然」。动手前先把三件事摸清：CPU 架构（鲲鹏还是飞腾）、操作系统（麒麟还是统信 UOS）、数据库（达梦、OceanBase 还是 openGauss）。不同组合兼容性差异很大——同样的二进制在鲲鹏 920 上能跑，换飞腾 2000+ 就可能因为指令集差异出问题。操作系统层面还要记下 glibc 和内核版本，不少国产 OS 的 glibc 偏旧，会直接卡住新编译的二进制。
别拿生产环境当试验田，先搭一台与目标同配置的测试机，把采集、存储、查询全流程跑通一遍，记录下所有依赖的版本号，这份清单后面排查问题时要反复对照。
如果目标库是 OceanBase 或达梦，优先选它们的 MySQL 兼容模式，迁移成本最低。用 mysqldump 导出数据，注意三点：字符集统一用 utf8mb4；时间字段别存成字符串；导出时加 --single-transaction 保证一致性快照。导入后跑校验，两边行数必须对得上：
SELECT count(*) FROM logs_bak;
SELECT count(*) FROM logs;三选一怎么挑：OceanBase 的 MySQL 模式兼容度最高，适合日志量大的场景；达梦对国产 OS 的适配成熟，政企项目常见；openGauss 偏 PostgreSQL 协议，迁移成本相对高。达梦要留意部分 SQL 写法差异，比如分页的 LIMIT 需确认目标版本是否支持，建议统一改用 ROWNUM 或版本推荐写法，避免埋雷。日志表往往很大，导出建议按时间分段导出，一次全量导出容易卡在中途。
Go 写的采集端和平台端交叉编译到 ARM 基本无感，一条命令搞定：
GOOS=linux GOARCH=arm64 go build -o observe ./cmd/observe如果依赖了 C 库，尽量加 CGO_ENABLED=0 走纯静态编译，能绕开国产 OS 上 glibc 版本不一致的坑。重点在第三方依赖：确认所用 C 扩展、二进制包都有 ARM 版，别把 x86 的 so 库直接拷过去——它们加载时会直接报错。数据库驱动换成对应国产库的驱动，连接池参数按新库实际并发能力重调，别沿用 MySQL 默认值，那对新部署的达梦或 OceanBase 往往过猛。
迁移后别只看「能跑」，要跑基准：日志写入吞吐、查询 P95 延迟、告警触发延迟，和迁移前对比，差距超过 20% 就要查原因。ARM 服务器核数多，把采集端、存储、查询绑到不同核上能明显降抖动。验收重点核对三件事：数据一致性、权限模型、审计日志是否完整——信创验收里审计留痕往往是硬指标，缺了它前面做得再好也过不了关。有条件的话，再按等保要求做一轮安全基线核查，把「能用」坐实成「合规」。
整个迁移最稳妥的做法是灰度：先在测试环境验证，再切一部分流量到信创环境跑双写，稳定一段时间后再全量切换。这样任何兼容性问题都能在影响面最小的时候暴露出来。