时间点介绍：

  • A：启动数据迁移
  • B：全部迁移完成
  • C：新服务启动成功（切换数据源）

A~C之间可能遇到的情况枚举如下：


 新增数据 修改数据 删除数据
场景1 × x x
场景2 ✅ × x
场景3 × ✅ x
场景4 × × ✅
场景5 ✅ ✅ x
场景6 × ✅ ✅
场景7 ✅ × ✅
场景8 ✅ ✅ ✅

场景分析：

  • 场景1（无任何变化）：皆大欢喜，新服务启动后，即可正常运行
  • 场景2\5\7\8（新增数据）：时间点C之后，对增量数据（创建时间 > A）再次迁移
  • 场景3\5\6\8（修改数据）：时间点C之后，在旧库定位到修改数据（修改时间 > A），获取到PK后在新库删除，然后进行增量迁移
    • 注意：这部分在旧库中被修改的数据，在新库中可能被再次修改（修改时间 > C），需要人为解决冲突

  • 场景4\6\7\8（删除数据）：时间点C之后，在旧库定位到删除数据（分析binlog），获取到PK后在新库删除

    • 注意：这部分在旧库中被删除的数据，在新库中可能被修改(而非删除)，需要人为解决冲突

      可能存在的坑：

  • 上诉修改/删除数据的场景中：不管是分析还是操作都会花费一段时间，这段时间内可能反复出现新的冲突。

  • 场景5\8（新增+修改场景中）：如果微服务设计中采用了序列号表来记录自增Key种子，那么当A~C之间有新增数据（同时自增Key种子++）的话，新服务启动后会通过旧的种子生产重复的Key，从而导致业务阻塞等严重后果。解决方案：修改相关种子到最新值