2

我们需要定期修改生产数据库的结构。在许多情况下，这些更改对应于引用新更改的代码库中的更改。

我们通常会在拉取新更改并运行新 SQL 查询时放置一分钟的失败鲸鱼页面，但我有兴趣编写一个组件或其他东西来动态运行 SQL 查询，这样就不会停机将是必需的。

我还没有尝试过，但这是我的计划：

  1. 编写一个组件或其他东西来运行一个或多个特定查询。查询可能会进行检查，IF EXISTS因此它们只运行一次。我认为它也必须清除模型/持久缓存。
  2. 从 AppController 内部调用上述组件/查询beforeFilter。
  3. 将更改拉入实时（使用上述代码）。
  4. 等待几秒钟让应用程序运行一次（由其他用户或我们）。
  5. 删除触发 SQL 查询运行的 beforeFilter 代码。

这是一个疯狂的想法吗？这是我的问题： A. 这样的事情会奏效吗？B.有没有更好的方法来做到这一点，我错过了？C. 关于模型缓存，我需要了解哪些信息才能避免引发错误。据推测，调试级别将设置为 0（因为该站点将处于生产状态）。

顺便说一句，提到我们不在负载平衡系统上似乎是相关的。我们在一个专用服务器上。

4

2 回答 2

3

这样的事情会起作用吗？

有点。您可能仍会遭受停机时间。即使只是在查询完成运行时短暂。如果站点在您的部署期间流量很大，您也可能会遇到并发问题。

有没有更好的方法来做到这一点，我错过了？

使用负载平衡系统，您可以一次更新一个系统，同时将流量转移到另一个系统，直到所有系统都更新完毕。

您可以标记您的代码。在启用此功能之前，代码不会运行。因此，启动您的代码，当您的数据库更新完成后，启用该功能。

我需要了解有关模型缓存的哪些信息以防止引发错误。

我对缓存不够熟悉，但缓存可能会让人产生网站可用的错觉。但是任何动态请求（表单提交）仍然可能导致错误。

顺便说一句，如果您还没有，请查看Schema Migrations 。

于 2013-11-05T16:36:24.143 回答
0

这样的事情会起作用吗？

我相信它会起作用，但如果你用力敲钉子，你也可以用鞋子敲钉子。

有一个更好的方法吗？

Jason McCreary 的评论是绝对正确的，他提到代码不应该自行部署，并且您应该使用部署过程——无论是（至少）自定义脚本、迁移，还是像我公司的工具BuildMaster这样的自定义工具它将数据库部署作为一流的概念处理。

使用这样的工具来充实您的流程将使您可以轻松地逐步建立一个完全自动化的系统，这样，如果您确实添加了负载平衡（或其他一些额外的基础设施），您就不必花费全部大量时间在各处更新您的部署过程。您还可以计划回滚、高级部署方案和其他很酷的事情，这些事情不能简单地通过将部署代码放在应用程序代码中来完成。

特别是对于数据库部署，BuildMaster 可以管理脚本，并在使用适当的部署操作时自动以相同的顺序部署它们。这将最大限度地减少您尝试手动运行它们时可能遇到的任何停机时间。您还可以放入停止/启动应用程序操作，这将清除任何服务器端缓存。然而，总会存在 ViewState 或其他客户端持久性的问题，但这完全是一个不同的问题。

于 2013-11-05T22:46:34.063 回答