我们一直将暂存数据库存储在生产数据库服务器上，认为尽可能与生产环境相同是有意义的。
最近，一些评论让我对这个想法产生了疑问。由于有一些遥远的可能性，我会因错误而影响到生产环境，因此不将它们放在同一台服务器上可能是有意义的。
我的暂存数据库是否真的应该与开发数据库位于同一服务器上，而不是与生产数据库位于同一服务器上？
7个回答
7
理想情况下，您希望拥有一个单独的暂存环境，它可以镜像您的生产环境，但实际上并不存在于其中。然而，$$$并不总是允许这样做，所以理想并不总是被遵循。
这包括（但不限于）以下内容：
- Web服务器 - 数据库服务器 - 应用服务器
那些机器上的任何东西（物理或虚拟）都应该在各自的环境中进行隔离，因此您不应该在生产服务器上看到暂存代码，同样，在生产数据库服务器上也不应该看到暂存数据库。它们应该是分开的。
此外，如果您在内部使用大量带宽，甚至可能需要隔离网络，以防止暂存环境的带宽使用量饱和生产环境的带宽。
这包括（但不限于）以下内容：
- Web服务器 - 数据库服务器 - 应用服务器
那些机器上的任何东西（物理或虚拟）都应该在各自的环境中进行隔离，因此您不应该在生产服务器上看到暂存代码，同样，在生产数据库服务器上也不应该看到暂存数据库。它们应该是分开的。
此外，如果您在内部使用大量带宽，甚至可能需要隔离网络，以防止暂存环境的带宽使用量饱和生产环境的带宽。
- Joseph
2
2一台强大的机器配备多个虚拟服务器可以以更少的费用提供良好的近似效果。 - MaxVT
@MaxVT 是的，回想起来，我并不是特指物理机器，我会更新我的答案以反映这一点。 - Joseph
3
无论你最终选择哪种解决方案，我建议：将生产服务器仅用于生产！如果你在上面放置一些非生产内容，当然会有错误的风险，就像你所说的那样......但也存在着错误风险：例如，如果你的应用程序出现问题并使用了服务器的所有CPU，那么你的生产可能会受到影响。
当然，这只是一个例子;-) 在我看来，最好的解决方案是为暂存设置另一台服务器，并尽可能接近生产环境的设置（真正的“克隆”会是最好的）。
考虑到这可能会花费相当多的钱购买一台仅供少数测试人员使用的机器，因此通常不太可能：
（在开发服务器上托管的虚拟机）是我见过的替代方法：它就像一个“真实”的机器，你可以在上面做任何想做的事情，而不会影响生产或开发。
如果需要，你可以使用多个虚拟机，以便更接近生产设置。
当然，这只是一个例子;-) 在我看来，最好的解决方案是为暂存设置另一台服务器，并尽可能接近生产环境的设置（真正的“克隆”会是最好的）。
考虑到这可能会花费相当多的钱购买一台仅供少数测试人员使用的机器，因此通常不太可能：
（在开发服务器上托管的虚拟机）是我见过的替代方法：它就像一个“真实”的机器，你可以在上面做任何想做的事情，而不会影响生产或开发。
如果需要，你可以使用多个虚拟机，以便更接近生产设置。
- Pascal MARTIN
3
在我的看法中，一个暂存环境应该是独立的，因为它可以让你排练新版本的发布过程。如果你在同一台机器或虚拟机上操作，就无法获得库更新等方面的“完整”体验。
个人而言，我喜欢虚拟机，因为我可以将生产环境还原到暂存环境并进行更新。这意味着我的更新是非常逼真的，因为所有边缘情况数据、库等都在复制。这是一件好事...在我们的主要产品历史的9年中，有多少次由于未包含库模块或数据库的某个更新脚本触发了未在开发和测试环境中检测到的边缘情况，我们已经数不清了。
至于触及生产环境...如果有替代方案的话，我会说永远不要这么做。在暂存环境中更新共享库会影响到生产环境，你会感到痛苦。更新代码，导致你的 web 服务器进入混乱状态，并使你的在线环境受到 (至少部分) 影响。
如果必须伪造，我建议与开发环境共享，并意识到更新生产环境可能会在验证所有工作正常期间引起意外停机。由于预算原因，我们在前几年不得不这么做，只要你不是更新生产环境然后就离开，这种方法也是可行的。
总之：
- 生产环境是神圣不可侵犯的：如果有可能，不要分享任何非生产方面。 - 虚拟机是你的朋友：它们让你克隆工作环境并用近乎零风险进行更新 (只需复制 VM 文件以解决任何失败的更新尝试)。 - 暂存环境应该与开发分离，以避免对更新程序的过度自信。
个人而言，我喜欢虚拟机，因为我可以将生产环境还原到暂存环境并进行更新。这意味着我的更新是非常逼真的，因为所有边缘情况数据、库等都在复制。这是一件好事...在我们的主要产品历史的9年中，有多少次由于未包含库模块或数据库的某个更新脚本触发了未在开发和测试环境中检测到的边缘情况，我们已经数不清了。
至于触及生产环境...如果有替代方案的话，我会说永远不要这么做。在暂存环境中更新共享库会影响到生产环境，你会感到痛苦。更新代码，导致你的 web 服务器进入混乱状态，并使你的在线环境受到 (至少部分) 影响。
如果必须伪造，我建议与开发环境共享，并意识到更新生产环境可能会在验证所有工作正常期间引起意外停机。由于预算原因，我们在前几年不得不这么做，只要你不是更新生产环境然后就离开，这种方法也是可行的。
总之：
- 生产环境是神圣不可侵犯的：如果有可能，不要分享任何非生产方面。 - 虚拟机是你的朋友：它们让你克隆工作环境并用近乎零风险进行更新 (只需复制 VM 文件以解决任何失败的更新尝试)。 - 暂存环境应该与开发分离，以避免对更新程序的过度自信。
- Godeke
2
您的暂存数据库不应该与生产环境位于同一台服务器上。但是，我认为将其放置在开发服务器上是可以接受的。
有许多事情可能会出错，
在错误的数据库上操作数据
执行某些可能会导致服务器崩溃的操作。在开发和测试期间，您可能需要重新启动您的数据库服务器。
通常情况下，我认为开发人员不应该访问实际环境。只有运维人员才应该有权限。
- skyfoot
2
1我不同意让开发人员能够访问生产环境-实施热修复不应该需要在周六凌晨3点叫醒10个人，或者不得不写一份2页的文件，解释第10次如何注册一个对象，以便于某些有限资质的技术支持人员可以尝试着不再把事情搞砸。当然，充分的测试应该可以避免这种情况，但在现实中，在任何足够复杂并处于任何程度的变化中的应用程序中总会有一些细节被忽略。 - 3Dave
也许我应该限定一下我的说法。我曾经为几家受 SOX 约束的美国公司工作过，因此开发人员无法访问服务器。我们使用了一个持续集成服务器，它构建和部署代码，并运行脚本来部署到生产服务器。如果出现错误，那么 Opps 可以轻松地部署最后一个可靠版本而无需进行紧急处理或救火。这个 bug 将在第二天在开发环境中得到解决。 - skyfoot
2
正如其他人所说，应该像瘟疫一样避免在生产环境中保留非生产实体。开发人员可能会错误地添加或修改某些依赖于生产环境的内容。我们的生产服务器仅在部署期间进行修改。我们跟踪每个更改的文件，并采取机制以最小的努力回滚更改。
如果无法获得专用硬件，请将暂存环境保留在开发环境中。
- 3Dave
1
在生产服务器上拥有一个暂存数据库是有风险的。但是，通过充分的调试/测试阶段，对生产的实际风险是最小的。尤其是如果暂存负载很少。
- John Gietzen
0
如果您没有专门用于开发、暂存和生产的硬件，那么将您的暂存数据库放在开发SQL服务器上是一个常见的解决方案。
这比将您的暂存数据库放在生产服务器上要安全得多，因为这样可以避免在处理暂存数据库时导致生产SQL服务器崩溃。
- Justin Niessner
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接