Shopify公司的高级数据库工程师Akshay Suryawanshi和Jeremy Cole 参加了Percona Live ONLINE的会议，在会议上分享了Shopify公司过去一年在谷歌云上运行MySQL所面临的挑战和进展机遇的演讲。
Shopify是一个在线和内部部署的商务平台，成立于2006年。Shopify被超过一百万的商人使用，自平台成立以来，已经发生了数千亿美元的销售。该公司是MySQL的明星用户，黑色星期五和网络星期一周末是一年中的高峰时段，使用MySQL处理数千亿次查询。
PPT中的关键Google Cloud概念
作为演示的一部分，重要的是要了解围绕Google Cloud的命名约定：
- 区域–云在其中运行的地理区域（这些区域可能包括建筑物或相邻建筑物）
- 区域–特定区域内的细分。通常，每个区域内有三个，但每个区域会有所不同。
- GCE – Google Compute Engine平台，该系统提供虚拟机以作为服务器运行（Shopify的大多数微型基础架构都在GCP上并在VM中运行）。
- 虚拟机实例–在特定区域中调度的GC虚拟机
- 永久磁盘–网络连接的日志结构块存储区
- GKE – Google的Kubernetes引擎，这是一个托管的Kubernetes解决方案，在Google Cloud Platform（GPC）上进行管理，并在Google Cloud中进行管理。
和平时期的故事
Akshay谈到了永久性磁盘，这些永久性磁盘是网络连接的分布式日志结构块存储：“在这里，您基本上可以说大部分数据都是在这里，尤其是在运行MySQL数据或任何种类的数据库时。” 除了它们的性能（通常受网络连接存储的某种程度的延迟影响）之外，它们还提供了令人难以置信的功能，尤其是卷的快速快照。
“我们已经利用快照行为来改造我们的备份和还原基础架构，甚至对于一个数TB的磁盘，我们的恢复时间也缩短到了不到一小时。这是如此之快，以至于我们实际上每天还原保存或保留的每个快照作为备份。在我们运营MySQL团队最多的两个地区都在发生这种情况。” Akshay说道。
可配置的虚拟机
虚拟机（VM）公开了广泛的API，该API可以通过编程方式执行以下操作：“ API非常有用。它有据可查，我们正在很多地方使用它。” Akshay继续说道。
上下扩展VM是无缝操作（当然，其中大多数都需要重新启动）并且易于管理。Akshay表示，在适当的区域中配置新的VM非常容易：“同样，由于API广泛，它提供了构建抵御自身故障的弹性所需的功能。因此，我们将虚拟机分布在多个区域中。当特定区域出现故障时，这对我们有很大帮助。所有这些使我们能够构建自我修复工具，以轻松地自动替换发生故障的VM。”
GCP确实是跨地区的
Google Cloud的多区域可用性意味着从一个区域到另一个区域的故障转移非常容易，Shopify可以在短短几分钟内一天将其所有流量从一个区域转移到另一个区域。他们也可以在无需大量工作的情况下扩展到遥远的地理区域，同时保持相同的稳定性。
Akshay指出：“在过去的一年中，当我们推出了需要在特定区域保存PII数据的某些产品时，隔离PII数据对于Shopify来说是一个巨大的胜利，GCP为此提供了出色的支持。”
Google Kubernetes引擎
Kubernetes是一个用于容器编排的开源项目，而Google Kubernetes Engine（GKE）是一个使用和运行Kubernetes的功能丰富的工具。根据Akshay的说法：“我们未来的大部分工作都是针对编写MySQL并在公司内部运行和调度它们的容器进行的。自动存储和文件系统扩展有助于解决数据库问题。”
区域感知群集节点调度有助于调度Kubernetes Pod，以便它们对区域故障具有容错能力。
GCP网络很容易设置。区域间的延迟非常低，Shopify可以在发生灾难时快速对数据库执行区域故障转移。“我们可以在几分钟内完成整个区域的撤离工作。这是因为由于这些低延迟，我们可以使两个地区的数据库保持最新状态。” Akshay解释说。
虚拟私有云（VPC）是分割工作负载的好方法。在VPC级别隔离网络连接有助于实现这一目标。
战争：某些可能出错的地方
Jeremy详细介绍了Shopify在过去一年中面临的一些具体挑战，包括缺货，当时缺货是当时请求的资源（例如VM或磁盘）不可用。
杰里米（Jeremy）指出：“看起来像是您尝试使用一些API进行分配，而这只需要很长时间才能显示出来。在一个特定的实例中，在一个区域中，PD和VM的存货量连续数周保持不变。”
这意味着该公司必须适应一下暂时无法使用资源的情况，并考虑必须在哪里为时间紧迫的组件提供资源才能获得可用性。
永久磁盘土地出现问题
根据Jeremy所说：“我们通常遇到的更大问题之一是永久性磁盘（PD）。” 一个例子是最近发生的永久磁盘后端更改引起的中断，该中断导致“从较小的延迟影响到基础PD卷几秒钟的完全停顿的任何地方的回归，这当然假装是磁盘”。因此，这意味着磁盘已完全停滞了几秒钟。”
经过数周的诊断，正确地将摊位的责任归咎于PD。Jeremy指出：“故事的有趣之处在于，缓解此特定问题的方法包括将大量的PD容量附加到我们的每个VM上，以解决PD发生的问题。为了做到这一点，由于我们总共有这么多虚拟机，我们必须分配数PB的永久磁盘，并将它们保留几个月。
解决问题的关键是与供应商合作伙伴紧密合作。正如杰里米（Jeremy）所说：“有时候，您必须具有相当的创造力，才能使事情立即生效，并使自己重新投入行动。
部队替换
上一年在Percona Live上的Shopify演讲中提到了实时迁移（LM），但根据Jeremy所说，问题仍然存在。“我们一直在实时迁移机器，并在不同的物理机器之间迁移它们的VM。”
LM问题的发生频率及其引起该问题的次数与Linux内核或Intel CDE的发生频率直接相关。Jeremy解释说：“在迁移失败并杀死主机的情况下，我们仍然遇到hostError实例故障。”
NTP时间同步中的某些实时迁移仍处于中断状态。“而且，对于相同的维护，我们仍会定期为每个VM进行多次迁移-在一天左右的时间内最多迁移11次。”
区域盟友投降
去年，发生了区域性故障：“ Google对一个地区的流量路由进行了更改，基本上导致了网络堆栈的过载。因此，我们的努力非常艰难。我们真的无能为力，”杰里米说。尽管部署在多个区域和多个区域中，但仍需要这样做。
杰里米（Jeremy）的讲话很简单：在云中运行MySQL并不是魔术。“ Google Cloud面临一些独特的挑战，在云基础架构中运行MySQL面临着独特的挑战，而云本身也面临着独特的挑战。有时在云中运行数据库可能会感觉就像您一直在交战。”
提前做好有关如何在云中管理数据库的准备工作可能会有所帮助，特别是当您以Shopify那样的规模运行时。但是，总会有意外事件和事件发生。您的云合作伙伴和支持提供商合作也可以提供帮助。
文章来源：https://www.percona.com/community-blog/2020/06/02/percona-live-online-mysql-on-google-cloud-war-and-peace-by-akshay-suryawanshi-jeremy-cole/
