Deploying an Observability Platform on Dameng DM8 and Kylin V10

Why sovereign projects need special database treatment

In a typical private deployment, the database is MySQL or PostgreSQL and you just change a connection string per the docs. Sovereign (xinchuang) projects are different — the database is usually Dameng, KingbaseES or OceanBase, whose storage engine, character set and SQL dialect all differ from MySQL. Skip the compatibility check and you will get failed table creation at best, garbled production data at worst.

This article walks through Dameng DM8 + Kylin V10 and flags the pitfalls up front, so your deployment does not stall in the middle of a compliance deadline.

Environment and version matrix

Pin the versions before you start. A surprising number of issues come from mixing a database version with a platform version that was never tested together — in a regulated project, "it works on my laptop" is not an acceptable answer to an auditor.

• Servers: Kunpeng 920 / Phytium 2000+ or other domestic ARM servers
• OS: Kylin V10 (ARM)
• Database: Dameng DM8 (8.1.2 or later)
• Platform: Observe (single-binary delivery, few dependencies, a good fit for domestic stacks)

Dameng DM8 compatibility settings

Dameng is case-sensitive by default and may use GB18030 as its character set. An observability platform typically expects MySQL-style UTF-8 and lowercase table names, so specify them explicitly when creating the database:

CREATE DATABASE observe
  CHARACTER SET UTF8
  CASE_SENSITIVE 0;

CASE_SENSITIVE 0 turns off case sensitivity and CHARACTER SET UTF8 unifies the character set — together they avoid nearly all "table does not exist" and garbled-Chinese problems. Do this at database creation time; changing it afterwards usually means recreating the database, and a migration at 2 a.m. before a go-live is nobody's idea of fun.

Connection string and deployment

The platform connects to Dameng through its MySQL compatibility layer, so the connection string only needs the compatible port. No code changes, no custom driver:

DB_HOST=192.168.1.20
DB_PORT=5236
DB_USER=observe
DB_PASSWORD=***
DB_NAME=observe

Deployment itself is simple: download the ARM binary, fill in the env file, and start it with systemd.

./observe --config ./env

Two things worth checking at this stage. Run the process as a dedicated non-root user — many sovereign environments mandate it, and it limits blast radius. Point systemd's Restart=on-failure at it, so a crash does not leave your observability layer down right when you need it most.

Data sovereignty and audit

A sovereign deployment is not just about the tech running — it is about what the platform can prove. Confirm three things before handover: all data (logs, traces, metrics) stays inside the network with no external telemetry or phone-home; role-based access and a full audit trail are enabled, so you can answer "who queried what and when"; and the platform runs entirely on the approved domestic stack, including the database. In practice these are the items the acceptance committee will actually check, so do not leave them to the last day.

Data migration and acceptance

When migrating from MySQL to Dameng, do not pull large tables with Dameng's built-in tool in one go. Migrate the schema first, then move data in time-windowed batches — otherwise you will get stuck on long transactions and the migration will crawl.

During acceptance, beyond the three functional self-checks (log search, tracing, alert rules), verify two things specifically. First, Chinese logs query correctly without garbling — search for a known Chinese error string and eyeball the result. Second, query latency does not degrade under heavy writes, say 50,000 logs per second sustained for a few minutes. These two checks catch the character-set and indexing problems that functional tests miss.

Common problems

• ORA-00942 table or view does not exist: case sensitivity was not disabled. Rebuild the database with the right CASE_SENSITIVE setting rather than patching around it.
• Connection timeout: confirm port 5236 is open and the Dameng listener is healthy. Firewalls in sovereign environments are often locked down tighter than you expect, so check the security group before blaming the driver.
• Timestamp drift: align the timezones of Kylin and Dameng, both to Asia/Shanghai. A mismatch here shifts every trace by hours and wrecks alert correlation, and it is one of the most common root causes reported after a go-live.