数据库架构在线数据迁移（转）

数据库架构 - 在线数据迁移&＃xff08;转&＃xff09;

1.前期知识储备

　　在线数据迁移&＃xff0c;是指将正在提供线上服务的数据&＃xff0c;从一个地方迁移到另一个地方&＃xff0c;整个迁移过程中要求不停机&＃xff0c;服务不受影响。根据数据所处层次&＃xff0c;可以分为cache迁移和存储迁移&＃xff1b;根据数据迁移前后的变化&＃xff0c;又可以分为平移和转移。

　　平移是指迁移前后数据组织形式不变。比如Mysql从1个实例扩展为4个实例&＃xff0c;Redis从4个端口扩展到16个端口&＃xff0c;HBase从20台机器扩展到30台机器等等。如果在最初的设计里就为以后的扩容缩容提供了方便&＃xff0c;那么数据迁移工作就会简单很多&＃xff0c;比如Mysql已经做了分库分表&＃xff0c;扩展实例的时候&＃xff0c;只需要多做几个从库&＃xff0c;切换访问&＃xff0c;最后将多余的库表删除即可。更进一步&＃xff0c;在实现上已经做到全自动数据迁移&＃xff0c;如 HBase&＃xff0c;就更简单了&＃xff1a;添加机器&＃xff0c;手工修改配置或者系统自动发现&＃xff0c;然后等待系统完成迁移。

　　转移是指数据迁移前后&＃xff0c;数据组织形式发生了变化。多年前&＃xff0c;某社交平台曾经为ID升级做过一次数据迁移&＃xff0c;将ID由最初的自增算法修改为巧妙设计的UUID算法&＃xff0c;这次迁移最大的挑战是要修改数据的主键&＃xff0c;主键本来是数据的唯一标识&＃xff0c;它发生变化&＃xff0c;也就意味着原来的数据不复存在&＃xff0c;新的数据凭空产生&＃xff0c;对于整个系统中所有业务流程、周边配套、上下游部门都会产生巨大的兼容性挑战。不过大部分数据迁移项目都不会修改主键&＃xff0c;甚至不会修改数据本身&＃xff0c;改变的只是数据的组织形式。比如某社交平台计数器原本为了节约存储空间&＃xff0c;使用redis hash进行存储&＃xff0c;后来为了提升批量查询的性能&＃xff0c;迁移成 KV 形式&＃xff1b;又比如某社交平台的转发列表和粉丝列表&＃xff0c;最初都使用Mysql存储&＃xff0c;后来为了更好的扩展性和成本&＃xff0c;都迁移到HBase存储。

2.数据迁移步骤

上线双写&＃xff0c;将数据同时写入新/旧两个系统。
历史数据离线搬迁&＃xff0c;将历史存量数据从旧系统搬到新系统。
切读&＃xff0c;即将读请求路由到新系统。
清理沉淀&＃xff0c;包括清理旧的数据&＃xff0c;回收资源&＃xff0c;及清理旧的代码逻辑&＃xff0c;旧的配套系统等等&＃xff0c;将迁移过程中的经验教训进行总结沉淀&＃xff0c;将过程中开发或使用的工具进行通用化改造&＃xff0c;以备下次使用。

　　注意&＃xff1a;某些情况下&＃xff0c;步骤一和步骤二也可能倒过来&＃xff0c;先做历史数据搬迁&＃xff0c;然后再写入新数据&＃xff0c;这时候就需要谨慎地处理搬迁这段时间里产生的新数据&＃xff0c;一般使用queue缓存写入的方式&＃xff0c;称为“追数据”。