railwaysystem/docs/iot/ROUND5V_KINGBASE_MIGRATION_PLAN.md

Round 5V — isolated Kingbase migration and rollback gate

Current Round 5V-4 outcome

The separately authorized new offline V9 recovery container actually restored the native backup; 005 rehearsal, repeatability, transactional rollback and fresh-target backup recovery passed. Only afterwards, the exact approved 16-column/4-index script committed on the named source QA database. Real Kingbase service/transaction/process-interruption tests and Chrome software acceptance now passed. See Round 5V-4 evidence. Do not rerun initialization or overwrite a live database. The following sections retain the pre-migration plan/observations, not current missing-approval claims.

Historical Round 5V-3 decision

The user explicitly authorized migration 005 only on railwaysystem_fusion_qa_20261013, together with protected backup and isolated restore rehearsal. Scope SHA256 remains 90648b6ac67470f9a14f0795c4479dfb4811d4907e41a13ee5eeada16582b87f. Authorization is no longer missing. Status: MIGRATION_AUTHORIZED_BLOCKED_ISOLATED_RESTORE. SSH access, matching native tools, existing management-role access and consistent native backup are now verified. Actual independent database restore is still unverified. No DDL or business DML has been performed. Do not create a database, initialize an instance, start a new container or elevate privileges to overcome this gate without separate authorization. See current evidence and minimal resource proposal. The previous Round5V2 report remains historical evidence, not the current infrastructure status.

Scope and observed prestate

2026-10-14 read-only JDBC probe: database railwaysystem_fusion_qa_20261013, user fusion_qa_app, KingbaseES V009R003C018, current schema public, search path "$user", public. Application account is not superuser and cannot create databases or roles. Existing iotlocks.lock_auth: 10 rows; lock_command: 15 rows. Existing sequence-backed primary keys, unique auth number, unique person/device/type, and unique command number remain unchanged. Round 5S columns/indexes were absent. No migration authorization is inferred from an instruction conditional on approval. The application role has USAGE but not CREATE on both schemas and does not own the affected tables. However, existing grants on public.sys_menu, public.sys_notice_read, and public.sys_role_menu include TRUNCATE, TRIGGER and REFERENCES. Administrator least-privilege review is pending; no grants were changed.

Static review of 005

RuoYi-Vue/sql/iot/005_round5s_execution_safety.sql only adds nullable metadata, NOT NULL defaults for mode/version/state, two unique intent-key indexes, and two recovery indexes. All objects are schema-qualified; no sequences are reset, no existing business uniqueness is removed, no data is deleted, and there is no REAL backfill. Existing records must become LEGACY / 0 / QUARANTINED, not trusted Mock or REAL. Two nullable intent-key indexes must allow multiple nulls on this actual Kingbase instance; validate this with rollback-only synthetic rows after approval.

ADD COLUMN IF NOT EXISTS and CREATE INDEX IF NOT EXISTS are PostgreSQL-style syntax supported by the H2 substitute, not yet a Kingbase execution result. Do not use existence checks as proof of correct definitions: inspect names, types, nullability, defaults and index uniqueness/column order before/after. Use a bounded lock timeout and a single explicit transaction. DDL rollback and concurrent unique-index behavior still require actual Kingbase verification. Application sessions use iotlocks, public, pg_catalog, sys_catalog; do not change the global/database/user search path or accidentally query system sys_user views.

Required approvals and backup

1. Record authorization explicitly naming this database, migration 005 and its SHA256, maintenance window, account and approving administrator. App-account credentials do not grant authority to migrate; do not expand its privileges.
2. Inspect active sessions in this target only. Have owners pause only writers targeting this QA database. Do not kill the experiment, teacher or shared service.
3. Run python3 scripts/qa/qa.py snapshot --config /protected/qa.env. It captures both affected tables with JDBC metadata in a repeatable-read read-only transaction, private WebRowSet XML and SHA256 manifest under .qa-runtime/. These contain credentials/personal data from rows: never commit, print or upload. This is an affected-table snapshot, not a native full-database backup.
4. Before executing DDL, produce an authorized native Kingbase full QA backup (schema/data/sequences/ACLs) using matching licensed vendor tools and validate it in an approved isolated restore destination. Round5V3 completed the native backup; the restore destination is still neither confirmed nor provisioned. Do not use a mismatched PostgreSQL client or restore into any shared database.

Execution and failure rollback (authorized, blocked on isolated restore)

With an approved migration account, enforce current_database() equals the exact target before any change. Begin a transaction, set a local lock timeout (5s), capture prechange schema/index definitions and row counts, execute only migration 005, then verify the following before commit:

• All 16 new columns have the reviewed types/defaults/nullability; index definitions match exactly; existing constraints/sequences and row counts are unchanged.
• Existing rows have execution_mode='LEGACY', intent_version=0, execution_state='QUARANTINED', null intent key/environment/action/attempt time.
• No existing row is REAL, READY or eligible for automatic dispatch.
• A savepoint-based synthetic insert validates null uniqueness and a duplicate nonnull intent key is rejected; roll back the synthetic savepoint. Sequence gaps from rolled-back inserts are expected and must not be "repaired" by setval.

Any error: ROLLBACK the entire DDL transaction, inspect from a second connection to prove original schema/counts/data fingerprints are unchanged. If actual Kingbase DDL is not transactional, stop; never guess or issue automated DROP/CASCADE. After commit, prefer keeping the additive schema and stopping the new application over a destructive down migration. Rollback to old software is NOT automatic once new lifecycle rows exist. Administrator-reviewed selective/native restore requires fresh approval and a proven isolated restore; no generic destructive down.sql.

Required acceptance after migration

Run production XML Mappers, real Services and DataSourceTransactionManager using fusion_qa_app, with MQTT/face transport substitutes only. Persist synthetic QA rows with unique run marker; preserve existing training rows and history. Cover check-in/out intents, commit-before-command crash, never-attempted restart recovery, unknown outcome -> MANUAL_REVIEW without resend, unique-intent concurrent claims, late ACK vs new version, cross-transaction visibility/rollback. Preserve test rows for audit or explicitly scoped cleanup only. H2 results cannot satisfy this gate.