Two-way scanning validates a migration by checking that every row in the source appears in the destination, then checking the reverse direction. The two passes reveal rows that exist only on one side. section 12.2.5 section 12.3
Use the technique as a focused migration check:
- Scan source rows and verify their presence in the destination. section 12.2.5
- Repeat the scan from destination to source to find rows missing in the opposite direction. section 12.2.5
- When a full scan is impractical, sample random token ranges or data slices. section 12.2.5
- Use the results to build confidence before switching traffic, while retaining dual-writing afterward as a fallback. section 12.2.5
Sampled migration check
Choose a random token range, list its rows in the source database, and confirm that each appears in the destination. Then list the destination rows in that range and check them against the source. Any one-sided row becomes a migration mismatch to investigate. section 12.2.5
Figure 12.8 By dual-reading your application’s request, you can check for mismatches and verify the correctness of your migration.
A dual-read flow provides a visual companion: application requests reach both databases so mismatches can be detected during migration validation. section 12.2.5
