如何实现数据库的不停服迁移？

回答重点

迁移想着很简单，不就是把一个库的数据迁移到另一个库吗？

但是实际上有很多细节，在面试中我们可以假装思考下，然后向面试官复述以下几点：

大部分数据库迁移都会采用双写方案，例如自建的数据库要迁移到云上的数据库这个场景，双写就是同时写入自建的数据库和云上的数据库。

我们来过一遍迁移流程：

1）将云上数据库（新库）作为自建数据库（旧库）的从库，进行数据同步（或者可以利用云上的能力，比如阿里云的 DTS）。

2）改造业务代码，数据写入修改不仅要写入旧库，同时也要写入新库，这就是所谓的双写，注意这个双写需要加开关，即通过修改配置实时打开双写和关闭双写。

3）在业务低峰期，确保数据同步完全一致的时候（即主从不延迟，这个都是有对应的监控的），关闭同步，同时打开双写开关，此时业务代码读取的还是旧数据库。

4）进行数据核对，数据量很大的场景只能抽样调查（可以利用定时任务写代码进行抽样核对，一旦不一致就告警和记录。）

5）如果确认数据一致，此时可以进行灰度切流，比如 1% 的用户切到读新的数据库（比如今天访问前 1% 的用户或者根据用户 ID 或其他业务字段），如果发现没问题，则可以逐步增加开放的比例，比如 5%->20%->50%->100%

6）继续保留双写，跑个几天(或者更久)，确保新库确实没问题了，此时关闭双写，只写新库，这时候迁移就完成了。

除了主从同步，代码双写的方案，也可以采用第三方工具。例如 flink-cdc 等工具来进行数据的同步，它的优点方便，且支持异构（比如 mysql 同步到 pg、es 等等）的数据源。

像 flink-cdc 支持先同步全量历史数据，再无缝切到同步增量数据。上图中蓝色小块就是新增的插入数据，会追加到实时一致性快照中；上图中黄色小块是更新的数据，则会在已有历史数据里做更新。