9

我研究了这篇关于蓝/绿部署的文章，然后更多的谷歌搜索向我介绍了这篇关于金丝雀发布的文章。我有这样的歧义：数据库会发生什么？我们应该如何使它们同步？我有两种可能的情况：

  • 想象一下，当蓝色处于活动状态时，每个环境（绿色和蓝色）有两个单独的数据库
    ，新记录将被插入到它的数据库中，
    除非我们提供类似触发器的机制（或任何其他机制），否则绿色不会意识到这些变化机制）来更新绿色数据库。
  • 第二种情况建议我们在两个环境之间共享一个向后兼容的数据库，但是
    在处理数据库时向后兼容并不是那么容易，我们必须
    在发布应用程序之前发布数据库更改。

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

您认为更好的解决方案是什么，为什么？您是否建议任何其他做法或众所周知的模式？

谢谢你

4

2 回答 2

2

我个人只使用向后兼容的数据库方法。主要好处是它易于理解并且适用于各种部署类型，包括金丝雀和蓝绿；即使没有蓝绿部署策略（对所有服务器的普通滚动部署，本质上是快速金丝雀部署），我也使用了这种方法。与在不同数据库版本之间需要复杂的触发或镜像机制相比，必须在应用程序发布之前部署数据库更改对于几种部署策略来说并不那么繁琐。

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

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

于 2016-01-04T21:56:27.670 回答
0

我从未见过 100% 蓝绿色或金丝雀的应用程序。原因是实际的“数据”层。我们不能在数据库层进行蓝绿部署，因为每种数据库类型都有自己的细微差别。这通常仅用于应用程序（代码）级别。

如果您想对数据库进行蓝绿色部署，则需要在数据库级别进行数据迁移或至少恢复，这对于大多数团队来说实施起来既复杂又麻烦。这将是耗时的，回滚将是一个混乱的状态。只需使用向后兼容的数据库并在回滚时清理数据库更改。

于 2022-01-13T09:33:58.940 回答