金沙4166

XML 地图 | Sitemap 地图
金沙4166> 行业资讯> 简单数据库迁移实践
?

简单数据库迁移实践

2017/6/23 9:41:51 | 来源:www.usa-idc.com
  现在NoSQL流行,有一个原因也是因为不需要去刻意处理table的schema,直接存储数据,这样简单!所以也不会有数据库表的迁移问题。数据库表迁移这一块儿一直是一个麻烦点,但我最近用了sqlite3做了个小项目,所以回顾下数据库迁移的方案。

  原理
  每一次数据表改动,都对应一个数据库版本号

  数据迁移是渐进式的,比如把数据库版本从1 升级到n,那么就升级n-1次,版本1到2,2到3,直到n-1到n。

  实施
  1. 使用sqlite3的user_version 存贮自定义的数据库版
  /*设置版本号*/
  PRAGMA user_version=1;
  /*读取版本号*/
  PRAGMA user_version;

  2. 所有的数据库升级文件,放在一个文件中,都直接使用sql文件,方便直接查看办理。文件结构如下

  v1.sql v2.sql, v3.sql等 是每个数据库版本,完整的数据库定义文件
  v1tov2.sql, v2tov3.sql等 是间隔版本数据库升级文件。一个数据m到n升级的过程就是,运转 v[m]tov[m+1].sql, v[m+1]tov[m+2].sql, 直到 v[n-1]tov[n].sql
  run.sh 就是每次要跑的数据迁移脚本,包括了当前的版本号和迁移逻辑
  其中的v2.sql 到v[n].sql 不是必须的,只是为了方便查看当前最新的数据表设计,如果存在v[n].sql 那么创建新数据库也可以直接从这个文件来创建

  3. 迁移脚本如下, 具体逻辑注释中已经写明。

  4. v[n].sql 和v[n-1]tov[n].sql 文件的最后都去需要经过user_version来设置数据版本为n,一个v2tov3.sql 的demo如下:

  回顾
  使用场景
  此刻这套方案适合数据量小,对停机维护可以接受的业务情况,因为需要停机升级,但是这个方案,足够简单清晰且能满足所有不同版本间的数据升级。

  不足与展望
  这个方案没有考虑到数据升级失败的回滚。由于是小业务,所以考虑更多的是简单易维护。所以针对这种情况的,首先要包管升级脚本经过了足够的线上数据测试,经的起考验。其次,一旦产生问题,线上可以直接操纵维护,写脚本。这样说,因为你都没有测试到这种需要rollback的case,你也不能在写升级脚本的时候,知道这种case是怎样,所以提前写好rollback的逻辑不一定可行或者合适。

  摆设时,数据迁移之前要备份,数据量较大些,用增量备份,节省时间。备份有成熟的工具,而且备份方便升级失败时rollback。摆设的步骤应该是: 拉代码build(或者拉docker镜像)-> 备份数据库 -> 升级数据库 -> 跑新的代码

  对于Android,iOS的设备中使用sqlite3的情况,数据迁移的逻辑是一样。sql文件结构设计可以重用,也可以写到代码里去办理。迁移脚本需要转换成native的Java或者Objective-C,Swift的代码。

  对于更大的业务,多实例的的数据库迁移可以使用Flyway。
金沙4166运营部编稿

猜你喜欢

金沙4166为您的网站提供全球顶级IDC资源
在线咨询
24H在线QQ
400-6866-820
24H免费热线
400-6866-820
Copyright @2005 - 2018 粤ICP备13012552号-3 增值电信业务经营许可证:粤B2-20090095
在线咨询
在线客服


7X24小时在线QQ

免费电话:
400-6866-820

最新活动
XML 地图 | Sitemap 地图