google-cloud-sql - Cloud SQL Postgres 故障转移和 CPU/内存升级期间预期不可用？

Question

我对 AWS RDS MySQL 多可用区 (HA) 有一些经验。我正在寻找一个新项目的 GCP Cloud SQL Postgres HA。
我试图弄清楚某些维护操作是如何工作的，但无法从 Cloud SQL 文档中弄清楚。

故障转移会导致多少不可用？

CPU/内存升级会导致多少不可用？

故障转移后，最终“故障恢复”到原始主实例是否重要？或者我可以让它无限期地在备用实例上运行吗？ (Cloud SQL HA failover diagram 使两个实例看起来不完全对称。)

仅供引用，AWS RDS 的答案
故障转移:在我的应用程序能够再次发出查询之前，通常在 70 秒内不可用。

这适用于计划内的故障转移。 (对于计划外的故障转移，RDS 在实际启动故障转移之前检测到主实例没有响应可能需要更长的时间。)

很多故障转移延迟可能是由于 DNS。使用 AWS RDS 代理服务可能会减少该时间(他们声称减少了约 80%)。 Cloud SQL HA failover diagram显示两个实例共享一个虚拟 IP，这可能意味着没有 DNS 延迟？

CPU/内存升级:我认为 AWS 可以通过一次不可用的故障转移来实现这一点。它升级备用实例(无不可用)，执行故障转移，然后升级另一个实例。
在 RDS 上，我认为作为 HA 设置一部分的两个实例是对称的。因此，如果您故障转移到备用数据库，那么保持这种状态就好了。没有必要(就 RDS 而言)故障转移回原始状态。

Answer 1

回答您的以下问题:

正如您所提到的，不可用的持续时间会有所不同，具体取决于它是计划内(手动)故障转移还是计划外故障。最好测试并手动启动故障转移，以便您可以查看实例响应它的时间，通常需要一分钟左右。当谈到计划外故障转移时，文档中几乎涵盖了当发生故障转移时，与主实例和只读副本的任何现有连接都将关闭，重新建立连接大约需要 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/内存)将导致停机，因此您应该在进行这些更改时提前计划。

要了解故障恢复的重要性，这里是此 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:
Cloud SQL 上的 HA 将为您的备用实例配置与您的主实例类似的规范，这就是为什么您将获得非 HA 实例价格两倍的费用。此外，故障恢复的重要性不仅限于任何云提供商。确保所有操作都返回到您的主实例而不是仅将其留在备用实例上是一种很好的做法。在这种情况下，故障回复(具体是在 Cloud SQL 上)对于确保在中断后一切恢复正常是非常必要的。
更新 2:
如果您不进行故障回复，则可能发生的情况是，当运行备用实例的区域出现中断时(您无法控制 zone 备用实例来自什么)，您将无法执行故障转移，因为操作将被阻止。 (见文档)
不幸的是，几乎没有选择，因为每当您更换硬件时都需要停机。该过程将要求实例重新启动。这是查看 how long it would take的链接.
其他资源: https://severalnines.com/database-blog/achieving-mysql-failover-failback-google-cloud-platform-gcp