小编jon*_*ton的帖子

今天早上我参与了升级 AWS RDS 上的 PostgreSQL 数据库。我们想从 9.3.3 版迁移到 9.4.4 版。我们已经在临时数据库上“测试”了升级，但是临时数据库要小得多，并且不使用多可用区。事实证明，这个测试是相当不充分的。

我们的生产数据库使用多可用区。过去我们做过次要版本升级，在这种情况下，RDS会先升级standby，然后将其提升为master。因此，故障转移期间发生的唯一停机时间约为 60 秒。

我们假设主要版本升级也会发生同样的情况，但是我们错了。

关于我们设置的一些细节：

• db.m3.large
• 预配置 IOPS (SSD)
• 300 GB 存储空间，其中使用了 139 GB
• 我们有未完成的 RDS 操作系统升级，我们希望批量进行此升级以最大程度地减少停机时间

以下是我们执行升级时记录的 RDS 事件：

数据库 CPU 在大约 08:44 和 10:27 之间达到最大值。RDS 拍摄升级前和升级后的快照似乎占用了大部分时间。

该AWS文档不警告这样的反响，尽管从阅读他们很显然，我们在处理一个明显的缺陷是，我们没有创建的副本生产的多AZ建立数据库，并尝试将其升级为试运行

总的来说，这非常令人沮丧，因为 RDS 给我们的关于它正在做什么以及可能需要多长时间的信息非常少。（再次，进行试运行会有所帮助......）

除此之外，我们想从这次事件中吸取教训，所以这里是我们的问题：

• 在RDS做大版本升级时出现这种情况正常吗？
• 如果我们想在未来以最少的停机时间进行主要版本升级，我们将如何进行？是否有某种巧妙的方法可以使用复制使其更加无缝？