如何做在线数据迁移

迁移数据是一个比较常见的操作,在很多情况下,我们都需要将数据从一个位置迁移到另一个位置,以满足一些需求,比如获得更大的存储容量,或者将压力均衡分布到多个节点。举例来说,下面这些场景都需要迁移数据:

  • 将数据从单个数据库迁移到多个数据库中,以提升存储容量
  • 将数据从关系型数据库迁移到NoSQL数据库中,使之更适合业务场景
  • 在分布式数据库内部,比如hbase,当节点数目发生变化时,也需要将数据进行迁移,使集群负载均衡

这里主要的难点在于,如何在迁移数据的过程中,保证上层服务仍然可以读取到数据。

对于上面第三个场景,很多分布式数据库已经能够自动处理,即迁移数据以达到负载均衡,并且在这个过程中能够做到不影响正常读写请求的处理。

在讨论具体的方案之前,我们先明确一下几个细节:

  • 需求是将数据从一个位置迁移到另一个位置
  • 在迁移过程中可以处理读写请求
  • 读写数据的请求具体包括read、write、update这三种

基于这些假设,可以抽象出几个参与数据迁移的模块,包括:

  • 之前的数据库,存放着当前所有数据,这个数据库记为old_db
  • 新的数据库,数据将会从old_db迁移到此处,这个数据库记为new_db
  • 请求路由层,路由层告诉应用程序,应该将读写请求发送到哪个数据库,路由层记为router

下面描述几种可行的方案。

同步+双写

这种方案的核心思想是保证稳定性,即如果迁移过程或者迁移后出现了问题,那么仍然可以回滚到之前的架构,数据不会丢失或者出错。它的大致过程是这样:将数据从old_db拷贝到new_db,保证两个数据库中的数据是一致的,然后每次进行write和update时,同时write/update两个数据库中的数据,等到new_db稳定后,再将old_db下线。

具体的实施会比较复杂,在数据量和请求量都很大的情况下,这个过程也比较长,中间需要使用到一个临时数据库,这里记为temp_db,详细的执行步骤如下:

  1. 准备好new_db,temp_db
  2. 选择一个时间点,获取这个时间点old_db的快照。取快照是一个很快的操作(需要数据库支持快照功能)。这个过程需要短暂的停止向数据库写入和更新数据,在快照取完后,更新router的策略,将每次更新操作同时写到两个位置,一个是old_db,一个是temp_db。
  3. 将快照数据导入到new_db中
  4. 快照数据导入完成后,开始将temp_db中记录的操作应用到new_db中。这需要额外开发一个程序来完成这个工作,这个程序会持续运行,消费temp_db中记录的操作。
  5. 在上面两步执行的过程中,应用程序还在继续发起读写请求,因此会不停的有更新操作写入到temp_db中。
  6. 等到某个时刻,temp_db中记录的操作被清零,即全部应用到了new_db,同时还没有新的更新操作进来。此时切换router的逻辑,开始双写,每一次更新操作同时写入old_db和new_db。(temp_db可以销毁了)。
  7. 观察双写情况下,new_db和old_db的数据是否完全一致,这里也需要额外开发一个比对的程序。
  8. 等待一段数据,如果new_db和old_db的数据没有出现不一致,则可以切换router的逻辑,将所有读写请求发送到new_db。

实施这个方案,需要一次短暂的停止写入,这个时间取决于获取old_db快照所需要的时间,大多数数据库的快照实现都是非常高效的(取快照的实现本质上就是计一个时间戳,然后使用类似copy on write的机制来处理后续的更新)。

此外,还需要两个额外的程序:

  • 一个用来将temp_db中记录的更新操作应用到new_db中
  • 一个用来比对new_db和old_db中的数据
    router也需要增加几个逻辑:
  • 同时写old_db和temp_db
  • 同时写old_db和new_db
  • 写new_db

同步+双写的方案最大的优势是:整个过程中,任何一步如果有问题都可以随时停止,对历史数据没有任何影响。这个过程比较复杂,需要额外的开发,在实施的过程也需要人工参与。

redis的主从同步过程和这个方案有点相似,使用了快照+temp_buffer来同步历史数据。

渐进式+后台迁移

渐进式的迁移数据是比较简单的方式。具体如下:

  1. 准备new_db
  2. 更新router的策略,对于read操作:先从new_db中读,如果没有的话再去old_db中读,如果从old_db中读到了数据,则将数据写入到new_db中。对于update操作:使用类似的逻辑,如果在old_db中有数据,而new_db中没有,则将数据迁到new_db中,再进行update。对于write操作:写入到new_db,然后将old_db中的数据删除。(这些逻辑可能不太适合在router这一层实现,而是需要在应用程序中实现)
  3. 等到old_db中的数据全部迁移完成,更新router的策略,改为直接读写new_db。

这个迁移的过程完全依赖于应用程序对数据的访问,如果存在一部分数据长时间没有被访问,那么这些数据也就没有机会被迁移到new_db。因此这种渐进式的迁移一般都需要搭配一个后台迁移程序,这个迁移程序会主动的将数据从old_db迁移到new_db。

很明显,这种方案不能像双写方案那样随时回滚到old_db,因为数据只会存在一份,要么在new_db,要么在old_db,一旦从old_db迁移到new_db,就没有方法迁移回来了(当然可以开发一个反向迁移的工具,但是大多数时候并没有这个必要)。

总结

数据迁移虽然没有特别复杂的难以理解的地方,但是在实际工作,这是一个很重要的事情,因为数据非常重要,大多数应用程序都是在围绕数据进行一些逻辑处理,数据本身一旦出问题,整个应用也就会跟着出问题,而且是比较严重的问题。此外,实际的业务系统中,对数据的读写模式往往不仅仅是read、write、update这么简单,可能会包括一些其他的操作,比如scan读取,事务操作等,迁移的过程还需要额外的考虑这些操作。因此,实际工作中进行数据迁移是一件很耗时耗力的事情,需要定制精确的执行步骤,做详尽的测试验证,实操时也需要格外谨慎。

你可能感兴趣的:(如何做在线数据迁移)