背景图

数据表结构的迁移策略

本来打算进行数据表结构的更改,而更改的过程中必然遇到数据的迁移和有些字段值的恢复。后来因为公司不再关注这块的业务,所以最后,我们没有实施,还有另外一个原因,DBA比较难对付,拼命说合规,与他合作总是打折扣,否则依照我这个暴脾气,即使公司不在乎这个系统了,做完的功能也要上线。有时很多事情本身就是很无奈的。所以说下面的就是我为这次迁移准备的预案,现在看来是实施不了了。记录下来,至少说我努力了,结果就不考虑了,做了是经验,总结也是经验。

概述

系统在新搭建的时候,可能由于需求的变化,或者后期系统更改的时候发现以前的表结构的设计会是一个软肋,或者表结构设计的并不好,会影响后期的开发,这时候你面临一个选择,在现有的表结构上进行扩展,还是更改现有的表结构,进行一次迁移。

总的来说这个是一个很难做决定的选项,这个要视具体情况而定了,你可能想使用新的表结构,但是你甩不掉历史的包袱,老结构的数据是一定要转成新的结构的,那么该如何转,一种是停机维护,出问题回滚,下次再来。另一种方式是平滑过渡,其实我比较推崇后一种方式来进行。因为第一种方式的破坏性极强。而且有的时候项目初建的时候的确会有很多没有考虑的地方,所以如果出现这样的问题,那么我们确实需要切换一下表结构,这也是没办法的事情,我们现在遇到的问题就是表结构由于前期需求方向不明,或者我们的策略想的有点简单,项目要求快点上线,导致我们现在的处理不是很好,所以必然要面对一次切换。

维护方式

停机维护

这种方式就是大家要在晚上人特别少的时候进行,这样做的好处是

  • 没有人使用,不用考虑增量数据,一次性导入没有任何问题。
  • 出问题回滚,不会影响线上数据

缺点:

  • 一般要晚上加班搞
  • 用户体验差,时间就是金钱,一般没人想停服。
  • 如果数据量大,停服时间特长,需要评估切换成本。

有的时候,我们是不得不采用这种方式进行停服维护,但是个人真的不是很推崇这种方式,万不得已也没办法。

平滑过渡

其实这种方式就是我比较推崇的方式,这种方式的好处就是不同停服,切换方式比较复杂,需要运维支持。

首先部署新的结构和新的项目,这个项目不开放,然后从老库导数据。然后将流量引入到新系统中。这里面的问题就是增量数据的问题,迁移过程可以是很长时间。对于增量数据,一种是新旧系统上线后互相推数据,新系统要做幂等性,dba在导数据时也需要实现幂等性,待所有老数据导完后,就可以切服务了。还是就是先切,再导增量数据,这样就是最近数据可能不可见,随后可见。增量数据也可以通过binlog分析得出,也可以通过触发器的方式进行数据的推送。总之方法有很多种。

还是就是是否需要新旧共存,如果是需要相互导数据。

优点:

  • 没有停服压力,切换过程时间一般没限制
  • 可以在晚上进行,也可白天进行,一般还是流量小的时候进行。
  • 用户体验好,业务还在跑

缺点:

  • 需要处理增量数据的问题,dba不能一次搞定。
  • 需要考虑数据重复的问题,操作流程比较复杂
  • 需要介入的人员很多。
  • 对开发和介入人员的要求很高。

事情准备

其实不管以上哪种切换方式,我们都需要在事情开始前进行准备。否则这件事不太好处理,还要想好预案进行处理,出现突发情况又该如何处理等等。

  • 需要评估数据转换的时间,根据线上数据量和预生产环境中进行一次实验,预估线上数据的转换时间。
  • 运维需要准备机器,部署线上的环境
  • 开发人员需要更改旧系统和老系统,一起发布上线实现,增量数据的传输和转换。
  • DBA需要在上线之后开始执行转换,但一定要做到幂等性的插入。

想好应急方案,一般就是旧系统维护一段时间才能真正下线,所以数据最好是双推,这样容错性更好。

事后检测

成功转换数据后不能下架老服务,需要检测新服务,没有问题才能下架老服务。在整个过程中我们都必须进行各种评估,出现问题要即时解决,决定是继续还是终止。终止重来也是很令人头疼的事。

总结

总的来说大家或多或少都经历过迁移的事情,我以前的公司都是停服维护,现在我们会采用平滑过度的方案来解决我们的问题。

但是有一点必须说明平滑过度一定要之前想好方案,否则很多问题是解决不了的。

0%