Evaluate stronger MySQL migration guarantees and verified adoption

Qubu's initial mysql2 migration support uses a basic runner: execute pending SQL in supplied order and record each completed migration in __qubu_mysql2_migrations. This is intentionally comparable in scope to Drizzle's basic MySQL migrator. It does not implement Qubu's stronger shared migration-executor profile.

MySQL DDL commits implicitly. If a statement or history write fails, earlier schema changes can remain without a completed migration record. The caller must serialize runners and inspect/repair partial changes before retrying.

MySQL now supports strict catalog capture, reviewed-candidate preflight, and acceptance through the shared adoption API and CLI. Its baselineAdapter implements the smaller adoption contract and records the sealed baseline in its own history table. It retains caller-serialized coordination and the basic SQL runner for subsequent migrations; the shared migration executor remains unavailable.

Evaluate these possible improvements separately; they are not requirements for the basic runner:

• Database-scoped migrator leases and cooperative DDL locks held on one pinned connection across implicit commits.
• Durable phase/statement checkpoints, conservative handling of lost responses, and explicit recovery after partially applied DDL. Never infer that a missing completion record means the SQL did not run.
• Stronger journal validation and integrity: detect edited/reordered history, validate reserved tables, and atomically append applied history with a journal-head compare-and-swap.
• Apply strict live schema checks before subsequent migrations. The adoption reader already uses the MySQL catalog, rejects strict failures, and reports unmanaged tables. Avoid a general schema-equivalence engine.
• Integrate MySQL with the shared artifact executor. Add explicit reconciliation and consistent schema checks between adoption and later artifact execution. Shared adoption API/CLI integration is complete; MySQL adoption still records the exact reviewed snapshot in one history insert and does not implement the stronger session guarantees.
• MySQL-aware transaction requirements for generated DDL before enabling the shared executor profile. Do not advertise rollback guarantees for implicit-commit DDL.

Before promoting any stronger profile, prove its Qubu-owned guarantees with focused MySQL 8.4 tests: concurrent runners, disconnects around DDL/checkpoint/history commits, explicit reconciliation, and adoption followed by a migration that preserves existing rows.

References:

• Drizzle MySQL migration runner
• MySQL atomic DDL and implicit commits
• MySQL advisory locks

Start with the MySQL basic runner, its baselineAdapter, and the shared adoption API/CLI to map the current guarantees and boundaries. Run or add focused MySQL 8.4 tests for concurrent runners, disconnects around DDL and history commits, reconciliation, and adoption followed by migration. Done requires an explicitly scoped stronger profile with Qubu-owned guarantees demonstrated without advertising rollback for implicit-commit DDL.