Design patterns 如何在蓝色/绿色部署技术中处理数据更改？

我研究了一篇关于蓝色/绿色部署的文章，然后更多的Google向我介绍了一篇关于金丝雀发布的文章。 我有一个模棱两可的问题：数据库会发生什么？我们应该如何使它们同步？ 我有两种可能的情况：

• 假设有两个独立的数据库，每个环境一个
  （绿色和蓝色）蓝色激活时，将显示新记录 插入到它的数据库中，格林没有意识到这些变化
  除非我们提供类似触发器的机制（或任何其他机制）来 更新绿色数据库
• 第二个场景建议我们共享一个向后兼容的数据库 在两个环境之间，但向后兼容性不是那么容易
  在处理数据库时，我们必须发布数据库更改
  在发布应用程序之前

可能还有第三种情况，在主蓝/绿部署中为数据库实现蓝/绿部署

你认为什么是更好的解决方案？为什么？你有没有建议其他的做法或众所周知的模式

---

谢谢

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

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

---

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

向后兼容的数据库方法使部署有点“部分”金丝雀部署，因为旧服务和新服务都指向新升级的数据库。