Cloud SQL Postgres 故障转移和 CPU/memory 升级期间预计不可用？
Expected unvailability during Cloud SQL Postgres failovers and CPU/memory upgrades?
我有一些使用 AWS RDS MySQL 多可用区 (HA) 的经验。我正在为一个新项目查看 GCP Cloud SQL Postgres HA。
我试图弄清楚某些维护操作是如何工作的，但无法从云 SQL 文档中弄清楚。
- 故障转移会导致多少不可用性？
- CPU/memory 升级会导致多少不可用？
- 故障转移后，最终“故障回复”到原始主实例是否重要？或者我可以将它 运行 无限期地留在备用实例上吗？ （Cloud SQL HA failover diagram 使这两个实例看起来并不完全对称。）
仅供参考，AWS RDS 的答案
故障转移：通常在 70 秒内不可用，然后我的应用程序才能再次发出查询。
- 这是针对计划的故障转移。 （对于计划外的故障转移，RDS 在实际启动故障转移之前检测到主实例无响应可能需要更长的时间。）
- 很多故障转移滞后可能是由于 DNS。使用 AWS RDS 代理服务可能会减少该时间（他们声称减少了约 80%）。 Cloud SQL HA failover diagram 显示两个实例共享一个虚拟 IP，这可能意味着没有 DNS 延迟？
CPU/memory 升级：我认为 AWS 可以通过一次不可用的故障转移来实现这一点。它升级备用实例（无不可用），执行故障转移，然后升级另一个实例。
在 RDS 上，我认为属于 HA 设置的两个实例是对称的。因此，如果您故障转移到备用数据库，那么就这样吧。没有必要（就 RDS 而言）故障转移回原来的状态。
回答您的以下问题：
正如您所提到的，不可用的持续时间会有所不同，具体取决于它是计划内（手动）故障转移还是计划外故障转移。最好测试并手动启动故障转移，这样您就可以看到您的实例响应多长时间，通常需要一分钟左右。当涉及到计划外的故障转移时，文档中几乎涵盖了当发生故障转移时，与主实例和只读副本的任何现有连接都会关闭，并且大约需要 2-3 分钟才能重新建立连接。
要解决这个问题，您需要了解实例的 requirements 以允许故障转移：
The primary instance must be in a normal operating state (not stopped, undergoing maintenance, or performing a long-running Cloud SQL instance operation such as a backup, import or export operation).
这意味着升级您的实例时故障转移不计算在内，更改您的硬件规格 (CPU/Memory) 将导致停机，因此您在进行这些更改时应提前计划。
- 要了解故障恢复的重要性，请参阅此 link 的摘录：
High availability solutions continuously replicate data to a remote site or cloud. In the event that a primary system goes down, the remote, secondary system can be spun up and users are rerouted. This process is commonly referred to as “failover,” and it reduces downtime to seconds or minutes.
However, failover isn’t a permanent state. Once primary servers are up and running, data and applications must be restored so normal operations can resume. This process is known as failback, and it is very important from a DR testing standpoint. Here’s why: Not all replication technology is created equally when it comes to failback. In some cases, failing back to production servers can be painfully slow.
更新 1：
HA on Cloud SQL 将为您的备用实例提供与您的主实例相似的规格，这就是为什么您将获得非 HA 实例价格的两倍。此外，故障回复的重要性不仅限于任何云提供商。确保所有操作 returns 到您的主实例而不是仅将其留在备用实例上只是一个好习惯。在这种情况下，确实有必要进行故障恢复（具体来说是在云 SQL 上）以确保在中断后一切恢复正常。
更新 2：
如果您不进行故障回复，可能会发生的情况是，当您的备用实例 运行 所在的区域出现中断时（您无法控制 zone 您的备用实例将来自哪个区域），您将无法进行故障转移，因为操作将被阻止。 （查看文档）
不幸的是，几乎没有任何选择，因为每当您更换硬件时都需要停机。该过程将要求实例重新启动。这里有个link看how long it would take.
其他资源：https://severalnines.com/database-blog/achieving-mysql-failover-failback-google-cloud-platform-gcp
我有一些使用 AWS RDS MySQL 多可用区 (HA) 的经验。我正在为一个新项目查看 GCP Cloud SQL Postgres HA。
我试图弄清楚某些维护操作是如何工作的，但无法从云 SQL 文档中弄清楚。
- 故障转移会导致多少不可用性？
- CPU/memory 升级会导致多少不可用？
- 故障转移后，最终“故障回复”到原始主实例是否重要？或者我可以将它 运行 无限期地留在备用实例上吗？ （Cloud SQL HA failover diagram 使这两个实例看起来并不完全对称。）
仅供参考，AWS RDS 的答案
故障转移：通常在 70 秒内不可用，然后我的应用程序才能再次发出查询。
- 这是针对计划的故障转移。 （对于计划外的故障转移，RDS 在实际启动故障转移之前检测到主实例无响应可能需要更长的时间。）
- 很多故障转移滞后可能是由于 DNS。使用 AWS RDS 代理服务可能会减少该时间（他们声称减少了约 80%）。 Cloud SQL HA failover diagram 显示两个实例共享一个虚拟 IP，这可能意味着没有 DNS 延迟？
CPU/memory 升级：我认为 AWS 可以通过一次不可用的故障转移来实现这一点。它升级备用实例（无不可用），执行故障转移，然后升级另一个实例。
在 RDS 上，我认为属于 HA 设置的两个实例是对称的。因此，如果您故障转移到备用数据库，那么就这样吧。没有必要（就 RDS 而言）故障转移回原来的状态。
回答您的以下问题：
正如您所提到的，不可用的持续时间会有所不同，具体取决于它是计划内（手动）故障转移还是计划外故障转移。最好测试并手动启动故障转移，这样您就可以看到您的实例响应多长时间，通常需要一分钟左右。当涉及到计划外的故障转移时，文档中几乎涵盖了当发生故障转移时，与主实例和只读副本的任何现有连接都会关闭，并且大约需要 2-3 分钟才能重新建立连接。
要解决这个问题，您需要了解实例的 requirements 以允许故障转移：
The primary instance must be in a normal operating state (not stopped, undergoing maintenance, or performing a long-running Cloud SQL instance operation such as a backup, import or export operation).
这意味着升级您的实例时故障转移不计算在内，更改您的硬件规格 (CPU/Memory) 将导致停机，因此您在进行这些更改时应提前计划。
- 要了解故障恢复的重要性，请参阅此 link 的摘录：
High availability solutions continuously replicate data to a remote site or cloud. In the event that a primary system goes down, the remote, secondary system can be spun up and users are rerouted. This process is commonly referred to as “failover,” and it reduces downtime to seconds or minutes.
However, failover isn’t a permanent state. Once primary servers are up and running, data and applications must be restored so normal operations can resume. This process is known as failback, and it is very important from a DR testing standpoint. Here’s why: Not all replication technology is created equally when it comes to failback. In some cases, failing back to production servers can be painfully slow.
更新 1： HA on Cloud SQL 将为您的备用实例提供与您的主实例相似的规格，这就是为什么您将获得非 HA 实例价格的两倍。此外，故障回复的重要性不仅限于任何云提供商。确保所有操作 returns 到您的主实例而不是仅将其留在备用实例上只是一个好习惯。在这种情况下，确实有必要进行故障恢复（具体来说是在云 SQL 上）以确保在中断后一切恢复正常。
更新 2： 如果您不进行故障回复，可能会发生的情况是，当您的备用实例 运行 所在的区域出现中断时（您无法控制 zone 您的备用实例将来自哪个区域），您将无法进行故障转移，因为操作将被阻止。 （查看文档）
不幸的是，几乎没有任何选择，因为每当您更换硬件时都需要停机。该过程将要求实例重新启动。这里有个link看how long it would take.
其他资源：https://severalnines.com/database-blog/achieving-mysql-failover-failback-google-cloud-platform-gcp