A Sovereignty Migration: Moving an Observability Platform from x86 to Domestic ARM + DM Database

Three things to settle before you migrate

The biggest risk in a sovereignty migration is not technical — it's migrating without a clear answer to what, where and how-to-roll-back. Nail down three things before touching anything:

1. Target baseline. Is the CPU Kunpeng or Phytium? The OS Kylin V10 or UnionTech UOS? The database DM or OceanBase?
2. Data scope. Do you migrate historical logs, or only configs, alert rules and user permissions while historical data goes to cold archive?
3. Rollback plan. How long do the old and new stacks run in parallel, where is the cutover point, and how do you fall back?

If these three aren't decided up front, every later step risks rework.

Application-side changes: drivers and SQL compatibility

Observe is built on Go and the MySQL protocol. DM database offers a MySQL compatibility mode, so most SQL runs as-is, but three areas deserve close inspection:

• DDL. AUTO_INCREMENT, ON UPDATE CURRENT_TIMESTAMP and index length limits differ between dialects.
• Pagination. LIMIT offset, count needs rewriting on some DM versions.
• Functions. Verify the DM equivalents of NOW(), IFNULL and GROUP_CONCAT.

Run the DDL through DM's own migration tool on a test box first and clear the errors one by one before you migrate any data. This step takes the most time and is the most commonly underestimated.

Deploying on ARM servers

Use Docker or systemd on domestic ARM servers, and watch three things:

uname -m                 # confirm it's aarch64
docker pull --platform linux/arm64 observe:2.4.0

• Install only aarch64 dependencies; never mix in x86 packages — mixing causes failed image pulls or segfaults at runtime.
• Kylin V10's systemd and kernel parameters differ from CentOS — check file-handle limits (ulimit -n) and vm.max_map_count.
• Set the timezone to Asia/Shanghai everywhere and enable NTP, or log timestamps will drift.

Choosing the database: DM vs OceanBase

Both DM and OceanBase are common targets in domestic projects, and the choice shapes the migration path. DM is the classic drop-in for Oracle-style workloads and ships a MySQL compatibility mode that covers most common SQL; OceanBase is distributed by default and scales horizontally, with a MySQL mode that sits closer to native MySQL syntax.

For an observability platform, the decision usually follows whatever the organization already standardizes on. If the data center runs DM, migrate to DM and budget time for DDL and function compatibility; if OceanBase is the standard, the MySQL-mode path is shorter and most of the work is configuration rather than code. Either way, keep the application's persistence behind the MySQL protocol so a future switch doesn't force you to rewrite the storage layer.

OS-level gotchas on domestic Linux

Kylin V10 and UOS look like CentOS/RHEL on the surface, but three details catch people off guard during deployment:

• Kernel parameters. Default file-handle and mmap limits can be lower than you expect; raise ulimit -n and vm.max_map_count before starting any log or trace store.
• Package signing. Some repositories require importing vendor GPG keys before yum/dnf installs will proceed — pre-import them in the golden image.
• SELinux/AppArmor. Domestic distributions sometimes ship stricter default policies; verify the agent can write to its data directory and bind its ports before blaming the application.

Handle these three in the base image once, and every subsequent deployment is boring — which is exactly what you want.

Data verification and gray cutover

After migrating, confirm consistency with three checks: sample-compare log counts, verify that alert rules still fire as expected, and spot-check a few critical traces. Only then switch traffic gradually — run old and new stacks in parallel for a week, and retire the old environment once it's clean.

Write and rehearse the rollback plan ahead of time: if something goes wrong, point the ingestion endpoint back at the old cluster — cheap and quick. The real danger is "migration succeeded, so tear down the old environment immediately." If you later discover incomplete data, you have nowhere to go back to.

Finally, write the whole thing into a runbook: the DDL diffs, the rollback switch and the verification queries all belong in one place, because the next person to touch this environment may not be the one who migrated it.