A MySQL migration needs evidence that the target contains the required business state, not only evidence that a transfer process finished. OceanBase and TiDB are relevant distributed-engine targets, while a Vitess project has a different transition boundary around retained MySQL. The reconciliation plan should match the actual route and the application’s data meaning.
Its purpose is to make discrepancies explainable before the new system becomes authoritative for normal work.
Define the records and time boundary being compared
Start with the migration scope: applications, customers or business domains, current records, and history. Identify exclusions explicitly.
Then establish the comparison boundary. If the source continues accepting changes, an earlier target copy cannot be compared with a later source state as though both represented the same moment.
Ask how later changes are captured or how the validation window is controlled under the supported migration design. Keep that mechanism separate from the business checks that confirm the result.
This avoids treating every difference as a transfer defect when some may be explained by an undefined comparison point.
Use several levels of evidence
No single check answers every reconciliation question.
| Check level | What it can reveal | What it does not establish alone |
|---|---|---|
| Object and scope inventory | Missing tables, domains, or planned exclusions | Correct contents of every record |
| Record counts | Unexpected omissions or additions within a defined scope | Correct values and relationships |
| Business totals | Differences in balances, quantities, or period summaries | Every individual record is correct |
| Representative records | Meaningful value and relationship differences | Complete coverage of the dataset |
| End-to-end journeys | Whether the application can use the migrated state | All historical and exceptional data are covered |
Choose checks that complement one another and record what each result actually supports.
Evaluate OceanBase with business-owned expectations
OceanBase’s Enterprise product information gives a compatibility-oriented target to investigate. Reconciliation should use the actual proposed configuration and the application’s important data behavior.
For example, an order total, inventory quantity, or account adjustment can be checked through both records and the business output derived from them. Include the conditions that matter to the application rather than testing only convenient sample rows.
The supplied OceanBase casebook’s Ctrip migration account illustrates staged project work involving an archive pilot. It is historical vendor evidence for a project sequence, not proof that another application’s reconciliation or cutover will have the same outcome.
Use such examples to organize the evaluation, then retain the current project’s own evidence.
Keep differences classified and owned
For every discrepancy, record the scope, expected result, observed result, likely cause, owner, and decision. Avoid a large unresolved category labeled data looks close enough.
Distinguish planned transformations from unexpected differences. If a field or representation intentionally changes, the business needs a documented comparison rule.
Also distinguish a display difference from a changed business value. The application owner should judge whether the difference matters, using known inputs and expected outcomes.
An untested area remains unknown. Do not classify it as passed simply because nearby tables or a small sample were checked.
Include updates, deletions, and corrections
A static initial copy is only part of an active migration. Use representative events after the copy begins and verify how they appear at the target.
Include a new record, a later amendment, a deletion where appropriate, and a business correction. Check related records and derived outputs rather than inspecting each event in isolation.
TiDB’s MySQL compatibility guide helps identify application differences that may influence the test. Vitess represents a different clustering and sharding route, whose data movement and application path need the corresponding validation.
Use the chosen provider’s supported transition design. Reconciliation questions should be consistent across candidates even when their tools and technical steps differ.
Connect reconciliation to the cutover decision
Define the evidence required before write authority transfers. Identify who can accept a known exception and which discrepancy prevents the affected scope from proceeding.
Preserve the actual comparison data, configuration, results, and approvals. A prepared reconciliation plan should not be confused with executed checks.
After cutover, validate the first normal business activity and the relevant reporting or processing window. This confirms that the application is using the intended state rather than only proving a pre-launch copy.
Make the acceptance record reproducible. Store the approved comparison boundary, expected business results, known differences, and responsible owners alongside the decision. If the source continues changing, identify which later activity belongs in the next comparison rather than silently mixing different periods. This gives business and technical teams a common explanation for a mismatch and prevents an operator’s memory from becoming the only account of why the data was accepted.
OceanBase may be the right distributed target when tested compatibility and the operating design fit the application. The migration becomes credible when the business can explain the data boundary, completed checks, remaining exceptions, and transfer of authority. That is stronger evidence than a successful transfer status alone.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.