Migrating an Observability Platform to Domestic ARM and a Domestic Database

A domestic-computing migration is more than recompiling a binary — it spans CPU, operating system and database compatibility. This article is a reproducible checklist covering inventory, data migration, app adaptation and acceptance, with a few real pitfalls we've hit along the way.

Do a compatibility inventory before you move

The most common pitfall in a domestic-computing migration isn't technical, it's assumption. Before touching anything, pin down three things: the CPU architecture (Kunpeng or Phytium), the operating system (Kylin or UnionTech UOS), and the database (DM, OceanBase or openGauss). Compatibility varies sharply across combinations — a binary that runs fine on a Kunpeng 920 can break on a Phytium 2000+ because of instruction-set differences. On the OS side, also record the glibc and kernel versions; many domestic distributions ship an older glibc that will refuse to run freshly compiled binaries.

Don't use production as your test bed. Stand up a test box matching the target configuration, walk the entire ingest-store-query flow end to end, and record the version of every dependency. You'll diff against that list repeatedly when something breaks later.

Database migration: prefer the MySQL-compatible mode

If the target is OceanBase or DM, choose their MySQL-compatible mode to keep migration cost low. Export with mysqldump and follow three rules: use utf8mb4 everywhere, don't store timestamps as strings, and pass --single-transaction for a consistent snapshot. After importing, verify the row counts match:

SELECT count(*) FROM logs_bak;
SELECT count(*) FROM logs;

How to pick among the three: OceanBase's MySQL mode has the highest compatibility and suits high log volume; DM is mature on domestic operating systems and common in government projects; openGauss leans toward the PostgreSQL protocol and costs more to migrate. For DM, watch for SQL differences — confirm the target version supports LIMIT for pagination, or switch to ROWNUM or the version-recommended form before you rely on it. Log tables are often huge, so export in time-bounded chunks; a single full dump tends to stall halfway through.

Application adaptation

Cross-compiling the Go-based collector and platform to ARM is nearly painless — one command does it:

GOOS=linux GOARCH=arm64 go build -o observe ./cmd/observe

If you depend on C libraries, prefer CGO_ENABLED=0 for a fully static build — it sidesteps glibc version mismatches on domestic operating systems. The real work is in third-party dependencies: confirm every C extension and binary you depend on ships an ARM build, and don't just copy x86 .so libraries over — they'll fail to load. Swap the database driver for the domestic database's driver, and retune the connection pool for the new database's actual concurrency rather than inheriting MySQL defaults, which are usually too aggressive for a freshly deployed DM or OceanBase instance.

Performance verification and acceptance

Don't stop at 'it runs'. After the move, benchmark log write throughput, query P95 latency and alert trigger latency, and compare against the pre-migration baseline — if any gap exceeds 20%, dig into why before you sign off. ARM servers have plenty of cores, so pin the collector, storage and query workloads to separate cores to cut latency jitter. For acceptance, verify three things: data consistency, the permission model, and whether audit logs are complete. Audit trails are often a hard requirement in domestic-computing acceptance; miss them and nothing else you did matters. If you have the budget, run a security-baseline check against the classified-protection (等保) requirements to turn "it works" into "it's compliant".

The safest way through the migration is gradual: validate in test first, then run dual-write with a slice of traffic pointed at the new environment, and cut over fully only after it has been stable for a while. That way any compatibility issue surfaces while the blast radius is still small.