通过第三方产品升级最大程度减少停机时间

Question

我目前正在维护一个 Review Board 服务器（https://www.reviewboard.org/) 其中一个最大的痛点就是安排升级。

目前流程如下：

1. 关闭服务器并向所有用户发送电子邮件通知他们所有审查委员会服务将关闭。
2. 运行审查委员会维护人员提供的升级脚本，如果由于用户众多而导致数据库更新较多，则可能需要几个小时。
3. 在较长的停机时间（有时超过 5 小时）后重新启动服务器。

在升级第三方软件时，是否有比上述更好的解决方案来最大限度地减少停机时间？

我的理论是你可以：

1. 创建 Review Board 当前安装的单独副本以及某个时间（X）的转储数据库。
2. 对重复的安装执行升级。
3. 关闭服务器（时间比当前流程短得多）并向用户发送电子邮件。检查当前时间 (Y) 并查看自时间 (X) 以来对数据库的所有其他更改。
4. 将数据库演变应用于时间 (X) 和时间 (Y) 之间的变化差异。然后插入缺失的数据库行。

我遇到的问题是实施步骤 3 和 4，因为这些步骤不是由 Review Board 维护人员提供的。是否已经有预制工具来帮助解决这些问题？

额外细节：

我正在使用 MySQL 数据库来支持用 Python 编写的 Review Board。

Answer 1

一般情况下，使用多台服务器可以确保停机时间接近于零。例如，穷人的两台服务器解决方案是：

1. 你开始将所有用户从服务器 A 切换到服务器 B，

2. 一旦所有用户都在服务器 B 上，就无法从外部访问服务器 A，

3. 服务器A已更新，

4. 在将其重新上线之前，将检查服务器 A 以确保它按预期工作；您不希望在用户致电给您询问为什么他们不能再访问您的服务时发现更新失败（或引入了回归）。

5. 服务器 A 可以从外部访问，

6. 用户从服务器 B 切换到服务器 A，

7. 重复同样的操作来更新服务器B。

您是否随时向用户发送电子邮件，因为目标是在整个升级过程中保持服务正常运行。一个很好的例子是 Stack Exchange：他们非常频繁地将更新推送到生产环境（如果我没记错的话，播客上每天都会推送十几次），同时保持在线。只有在他们必须更改基础设施时，他们才会将用户重定向到俄勒冈州的 PEAK 数据中心。

至于该流程是否适用于您正在使用的特定产品，请考虑向开发相关产品的公司寻求支持。