是否有适合临时数据库的地方？

Question

我们一直在生产数据库服务器上存储我们的临时数据库,其思路是尽可能与生产相同.

最近,一些评论让我质疑这个想法.由于我有可能错误地将某些东西用于生产,因此不要将它们放在同一台服务器上是有意义的.

我的Staging数据库是否真的与我的开发数据库位于同一服务器上,而不是与生产相同的服务器？

Answer 1

理想情况下,您可能希望有一个独立的临时环境来镜像您的实时环境,但实际上并不存在.但是,$$$并不总是允许这样,因此并不总是遵循理想.

这包括(但不限于)以下内容:

• Web服务器
• 数据库服务器
• 应用服务器

这些机器(物理或虚拟)上的任何内容都应该在各自的环境中隔离,因此您不应该在生产服务器上看到登台代码,同样您也不应该在生产数据库服务器上看到登台数据库.它们应该是分开的.

此外,如果您在内部使用大量带宽,您可能甚至需要隔离网络,以防止暂存环境带宽使用使生产环境的带宽饱和.

Answer 2

在我的书中，暂存环境应该是独立的，因为它可以让您排练新版本的推出过程。如果您在同一个盒子或同一个虚拟机上，您将无法获得库更新等的“完整”体验。

就我个人而言，我喜欢虚拟机，因为我可以将生产拉回到舞台，然后更新它。这意味着我的更新非常现实，因为所有边缘情况数据、库等都被复制。这是一件好事...我无法计算我们主要产品 9 年历史中未包含库模块或数据库的某些更新脚本遇到未检测到的边缘情况的次数。开发和测试环境。

至于接触生产环境......我想说，如果有替代方案，永远不要这样做。更新暂存中的共享库也会影响生产，您会感到痛苦。更新代码并导致您的网络服务器陷入混乱，并且导致（至少部分）您的实时环境瘫痪。

如果您必须伪造它，我建议与开发环境共享，并意识到更新生产会在更新期间导致意外停机，因为您验证一切正常。由于预算原因，我们在最初几年不得不这样做，只要你不只是更新生产并走开，它就可以发挥作用。

总之

• 生产是神圣不可侵犯的：如果可以避免，就不要分享任何非生产方面的内容。
• 虚拟机是您的朋友：它们让您可以克隆工作环境并以几乎零风险进行更新（只需在任何拙劣的更新尝试中复制虚拟机文件即可）。
• 登台应与开发隔离，以避免对更新例程过度自信。