Google Cloud SQL 维护时段答案

【问题标题】：Google Cloud SQL Maintenance WindowGoogle Cloud SQL 维护时段
【发布时间】：2020-01-13 21:26:15
【问题描述】：

我在 RDS 和 Cloud SQL 之间犹豫不决的原因是，我找不到如果我将 Cloud SQL 实例设置为具有只读副本的高可用性，计划的维护将如何进行。在阅读了几个小时的 SO 和文档之后，我相信即使在 HA 实例的情况下，您也可能会因计划维护而遇到中断，因此您无法将任何设置/策略设置为具有几乎 100% 的正常运行时间，这与 AWS RDS 不同可以为副本设置不同的维护窗口。

我说的对吗？如果没有，如何实现与 AWS 中的相同？如果我是，这种行为背后的理由是什么？如果您不能保证始终可以访问它，您甚至应该如何将您的服务转移到 GCP？如果 HA 也有停机时间，那它还有什么意义？

【问题讨论】：

本文档涵盖维护窗口：cloud.google.com/sql/docs/mysql/maintenance 用于 MySQL。每个数据库都有一个类似的文档。编辑您的问题以指定什么类型的事件。有些事件需要停机，有些则不需要。
设计您的服务以处理停机时间。没有任何服务可以提供 100% 的正常运行时间。不管花多少钱，总会有一个小窗口。

标签： google-cloud-platform google-cloud-sql

【解决方案1】：

高可用性等同于多 az sql 实例。因此，当您设置此选项时，您会在一个区域中运行一个主实例，在另一个区域中运行辅助实例。因此，当云中的维护窗口启动时，sql 应该自动故障转移到其他可用区，并且您的应用程序/用户不应该受到影响。但是，有一些报告的事件是 Cloud SQL 导致停机（请参阅下面的编辑说明）。

另一方面，只读副本可帮助您从主实例卸载流量，但不会为您提供冗余。

没有托管 SQL 提供 100% 的正常运行时间保证。 RDS Aurora 提供 99.99%。另一方面，Cloud SQL 提供 99.95% 的正常运行时间保证，这相当于停机时间不超过每日：43.2 秒。每周：5m 2.4s。每月：21m 54.9s。

我们使用 Cloud SQL，它足够可靠，并且在维护时段内可以无缝升级。

希望这会有所帮助。

编辑

我自己没有亲身经历过这种情况，但根据 Stefan G 的指针，Google Cloud SQL 有 open issue 尽管有 HA 导致维护窗口期间停机：

【讨论】：

不保证故障转移实例的维护顺序。为什么您认为升级顺序很重要？
好点，据我了解，只要故障转移实例位于另一个可用区，那么更新应该按顺序进行，是的。我会尝试找到一些关于此的参考文档并更新我的答案。
只是为了澄清，恐怕接受的答案不正确。至少第一段。您似乎正在考虑在维护窗口期间提升只读副本，而这不是那样工作的。当实例运行状况不佳时发生故障转移，在指定或非指定窗口期间发生维护。在@Maxim 发布的第二个“此处”链接中，您可以阅读并了解即使使用 HA，维护也会中断服务。当您接受 Parth Mehta 消息时，我假设您了解 Cloud SQL 的行为方式，但 Maxim 的回答是正确的。
总而言之：即使您有 HA，也可能会发生维护并中断您的服务，即使是很短的时间。在这个链接[1]中，人们正在专门讨论这个。希望这可以帮助。 [1]：issuetracker.google.com/111521234
我想澄清它可能发生，而不是它会一直发生。他主要担心有任何停机时间，我认为让他知道并且 Google 正在努力解决这个问题是公平的。感谢您对其进行编辑。

【解决方案2】：

只读副本既不提供高可用性也不提供，恐怕它们也不支持维护窗口。这在Cloud SQL FAQs 中进行了解释以及其他信息。

Public Issue Tracker 上有关于此 here 和 here 的功能请求 - 您可以通过单击星号按钮来表示您的兴趣。

发生计划维护时，首先在只读副本上执行操作，然后在主实例上执行操作。 Cloud SQL 尝试让其中一个始终运行，但这不能保证，可能会发生变化，您不应依赖它。

如果可用性对您来说至关重要，您最好改用 Cloud Spanner，它提供 99.999% 的可用性 SLA。

【讨论】：