Migrate MySQL to OceanBase by assessing SQL compatibility in MySQL mode, converting schema with OMA or manual review, syncing incremental changes with OMS, validating checksums, then cutting over through OBProxy with a documented rollback path.

Use this checklist for MySQL-mode OceanBase migrations. Adjust phases for your change window, data volume, and compliance requirements.

Phase 1: Assessment

  • Inventory schemas, stored programs, and session variables.
  • Run compatibility assessment (OMA or equivalent) against target OceanBase 4.x.
  • Document unsupported SQL, charset differences, and sequences/auto-increment behavior.
  • Define RPO/RTO targets and rollback DNS or connection string plan.

Phase 2: Schema and staging

  • Convert schema in a staging tenant; fix dialect gaps before bulk load.
  • Size units and resource pools for expected TPS and storage growth.
  • Configure OBProxy endpoints for application teams.

Phase 3: Incremental sync

  • Configure OMS (or supported CDC path) for incremental replication.
  • Run row checksum or targeted count validation on critical tables.
  • Monitor replication lag and error queues daily during dual-run period.

Phase 4: Cutover

  • Freeze schema changes or route them through both sides.
  • Stop writes to MySQL, confirm OMS caught up, run final validation queries.
  • Switch application connection strings to OBProxy.
  • Keep MySQL read-only or offline per rollback plan for the agreed window.

Phase 5: Post-cutover

  • Watch top SQL, replication (if any remaining links), and memstore pressure.
  • Schedule backup and PITR drill within the first maintenance cycle.
  • Update runbooks with new tenant IDs and observer topology.

Common mistakes

  • Cutover before charset or collation mismatches are tested on real data.
  • Skipping OBProxy failover test during the migration window.
  • No written rollback when DNS TTL exceeds the maintenance window.

Sources and further reading