如何处理蓝/绿部署技术中的数据更改?

时间:2015-05-10 14:04:24

标签: design-patterns blue-green-deployment canary-deployment

我已经研究了this关于蓝/绿部署的文章,然后一些谷歌搜索引入了我关于Canary Release的this文章。 我有这种含糊之处:数据库会发生什么?我们应该如何使它们同步? 我有两种可能的情况:

  • 想象每个环境有两个独立的数据库 (蓝色和蓝色)在蓝色激活时,新记录将是 插入到它的数据库中,绿色不知道这些变化 除非我们提供类似机制(或任何其他机制)的触发器 更新绿色数据库。
  • 第二种情况表明我们共享一个向后兼容的数据库 在两个环境之间,但向后兼容并不那么容易 在处理数据库时,我们必须发布数据库更改 在发布申请之前。

可能存在第三种情况,为主要蓝/绿部署中的数据库实施蓝/绿部署。

您认为更好的解决方案是什么?为什么?你建议任何其他练习或众所周知的模式吗?

谢谢

1 个答案:

答案 0 :(得分:2)

我个人只使用向后兼容的数据库方法。主要的好处是它很好理解并适用于各种部署类型,包括金丝雀和蓝绿色;即使没有蓝绿色部署策略(对所有服务器进行平凡的滚动部署,本质上是一个快速的金丝雀部署),我也使用了这种方法。必须在应用程序发布之前部署数据库更改对于几种部署策略来说是常见的,与不同数据库版本之间复杂的触发或镜像机制的需求相比,这种策略并不繁琐。

您的第三个场景也陷入了需要在数据库切片之间进行触发或镜像的陷阱。在RDBMS术语中,这通常是不受支持的或完全不可能的,因为只有master数据库而所有其他实例都不接受写操作。这样做的最终结果是主实例的版本是整个数据库的事实版本。

某些No-SQL数据库不属于此陷阱。例如,MongoDB很乐意在同一个集合中允许多个不同版本的文档模式。这样可以让您的应用程序了解数据版本并以不同方式处理文档。但是,MongoDB并不适用于所有应用程序(就像RDBS不是某些类型数据的正确数据存储一样)。