今天早上，我参与了在AWS RDS上升级PostgreSQL数据库的工作。我们想从9.3.3版升级到9.4.4版。我们已经在登台数据库上“测试”了升级，但是登台数据库小得多，并且不使用多可用区。事实证明，该测试还远远不够。
我们的生产数据库使用多可用区。过去，我们已经进行了次要版本升级，在这种情况下，RDS将首先升级备用数据库，然后将其升级为主数据库。因此，在故障转移期间仅发生的停机时间约为60秒。
我们假设主要版本升级会发生同样的情况，但是哦，我们错了。
有关设置的一些详细信息：
- db.m3.large
- 预置IOPS（SSD）
- 300 GB的存储空间，其中已使用139 GB
- 我们的RDS OS升级非常出色，我们想批量进行此升级，以最大程度地减少停机时间
以下是我们执行升级时记录的RDS事件：
数据库CPU在大约08:44到10:27之间已用尽。RDS似乎大部分时间都被RDS占用了，以进行升级前和升级后快照。
该AWS文档不警告这样的反响，尽管从阅读他们很显然，我们在处理一个明显的缺陷是，我们没有创建的副本生产的多AZ建立数据库，并尝试将其升级为试运行
总的来说，这非常令人沮丧，因为RDS很少提供给我们有关它在做什么以及可能需要花费多长时间的信息。（再次，进行试运行会有所帮助...）
除此之外，我们想从这次事件中学习，所以这里是我们的问题：
- 在RDS上进行主要版本升级时，这种情况正常吗？
- 如果我们想在将来以最少的停机时间进行主要版本升级，我们将如何处理？是否有某种巧妙的方式使用复制来使复制更加无缝？
ANALYZE更新统计信息的手册解决了该问题。如果有人对此有任何见识，那也将很棒。