mysql rds_rds更新避免了常见的陷阱

mysql rds

If you plan to host relational databases in Amazon Web Services (AWS), it would be worthwhile diving into Amazon Relational Database Service (RDS). Better still, if you fancy greater performance at a lower cost for MySQL or PostgreSQL, you may want to read into Amazon RDS Aurora, or if you would prefer a cluster that scales automatically to meet demand, you may go one step further and entertain Aurora Serverless for MySQL and PostgreSQL.

如果您打算在Amazon Web Services (AWS)中托管关系数据库，那么就值得深入研究Amazon Relational Database Service (RDS)。 更好的是，如果您希望以较低的成本获得更高的性能，例如MySQL或PostgreSQL ，则可能需要阅读Amazon RDS Aurora ；或者，如果您希望自动缩放以适应需求的集群，则可以更进一步，让Aurora更加有趣适用于MySQL和PostgreSQL无服务器 。

There’s much to learn about the workings of RDS: how to configure clusters, query tables, and maintain the infrastructure going forward. Answers to these questions vary depending on your engine choice. When it comes to querying RDS, you may choose between RDS Proxy — which recently became generally available — or third party clients like Python’s Psycopg library for PostgreSQL. On the other hand, if you’re working with Aurora Serverless, you may entertain RDS Data API, which manages connections to your Aurora Serverless cluster seamlessly under the hood.

关于RDS的工作，有很多要学习的知识：如何配置集群，查询表以及维护基础架构。 这些问题的答案取决于您的发动机选择。 在查询RDS时，您可以选择RDS代理 (最近已普遍使用)或第三方客户端，例如Python的PostgreSQL Psycopg库。 另一方面，如果您使用的是Aurora Serverless，则可以使用RDS Data API ，该API在后台无缝管理与Aurora Serverless群集的连接。

For all aspects of RDS, each option delivers pros and cons, which cannot be emphasised more when it comes to maintaining your clusters and instances — referred to hereafter as “resources” — in production. Have you enabled deletion protection? Are your credentials securely stored and rotated regularly? Are the infrastructure and the processes there to easily recover from a disaster?

对于RDS的各个方面，每个选项都具有优点和缺点，而在生产中维护集群和实例(以下称为“资源”)时，就不能再强调了。 您启用了删除保护功能吗？ 您的凭证是否安全地存储和定期轮换？ 是否有基础设施和流程可以轻松地从灾难中恢复？

Even if you’re adopting a managed Aurora Serverless engine, there’s potential pitfalls to avoid when it comes to production maintenance. One in particular springs to mind involving the use of DB snapshots, which applies to all engines outlined in this article so far. If you’re writing infrastructure as code with CloudFormation, or using tools that generate CloudFormation templates like the Cloud Development Kit (CDK), then this article may serve as a helpful warning to you.

即使您采用的是托管Aurora Serverless引擎，在生产维护方面也要避免潜在的陷阱。 特别值得一提的是涉及数据库快照的使用，该快照适用于到目前为止本文概述的所有引擎。 如果您正在使用CloudFormation将基础设施编写为代码，或者使用诸如Cloud Development Kit (CDK)之类的工具来生成CloudFormation模板，则本文可能对您有帮助。

陷阱是什么？ (So What’s the Pitfall?)

Defining your RDS DB resources, you’re given an abundance of properties to configure. Many are optional, but nonetheless hugely valuable for particular circumstances. Most notably, this includes a snapshot identifier.

定义RDS数据库资源后，您将获得大量要配置的属性。 许多是可选的，但在特定情况下仍具有巨大的价值。 最值得注意的是，这包括快照标识符 。

If you wish to re-create your resource with all its data included, or replicate it in another AWS region, you will require a snapshot to do this. Each snapshot is given a unique ID, which must be fed into the snapshot identifier property in your CloudFormation template. Seems straightforward so far: spin up a resource with your snapshot ID, which will be populated with all the same data that your snapshot holds, then you’re good to go.

如果您希望重新创建包含所有数据的资源，或者将其复制到另一个AWS区域中，则需要快照才能执行此操作。 每个快照都有一个唯一的ID，该ID必须输入到CloudFormation模板的快照标识符属性中。 到目前为止似乎很简单：使用快照ID启动一个资源，该资源将填充有快照所拥有的所有相同数据，那么就可以了。

The complication comes when you wish to update the resource later on, which presents a requirement that may not seem intuitive to new users. If you want to apply an update, which properties are required? We’ve already applied the snapshot, so there’s no need to provide the snapshot ID again. If we have the required properties, such as the master user’s password, we’re good to go, right?

当您以后希望更新资源时，就会出现复杂的情况，这提出了一个新用户似乎不直观的要求。 如果要应用更新，则需要哪些属性？ 我们已经应用了快照，因此无需再次提供快照ID。 如果我们具有必需的属性(例如主用户的密码)，那么我们就很好了，对吧？

Wrong. As AWS outlines in the snapshot identifier documentation, we must re-supply the same snapshot ID we used to spin up the resource, otherwise we risk losing this altogether to a new one:

错误。 正如AWS在快照标识符文档中概述的那样，我们必须重新提供用于启动资源的相同快照ID，否则我们有可能将其完全丢失，从而有一个新的快照ID：

After you restore a DB cluster with a SnapshotIdentifier property, you must specify the same SnapshotIdentifier property for any future updates to the DB cluster. When you specify this property for an update, the DB cluster is not restored from the snapshot again, and the data in the database is not changed. However, if you don't specify the SnapshotIdentifier property, an empty DB cluster is created, and the original DB cluster is deleted.

使用SnapshotIdentifier属性还原数据库集群后，必须为以后对数据库集群的任何更新指定相同的SnapshotIdentifier属性。 当您为更新指定此属性时，不会再次从快照还原数据库集群，并且数据库中的数据也不会更改。 但是，如果您未指定SnapshotIdentifier属性，则会创建一个空的数据库集群，并删除原始数据库集群。

The effects of this mistake are clear: if we lose our resource to an entirely new one, without the snapshot ID, we have an empty database. Given our snapshot retains the original data, and assuming we have regular snapshots thereafter saving more recent states for the resource, our data is safe, but nonetheless missing from its intended location. If you enabled deletion protection, the old resource will be saved from obliteration.

此错误的后果很明显：如果我们将资源丢失给一个没有快照ID的全新资源，那么我们将有一个空数据库。 鉴于我们的快照保留了原始数据，并且假设此后我们有定期的快照，然后为资源保存了更多的近期状态，则我们的数据是安全的，但仍会丢失其预期位置。 如果启用了删除保护，则旧资源将被清除。

Easy to fix with the correct setup in place, but nonetheless worth stressing to anyone that plans to use RDS in production. Keep an eye out for CloudFormation’s “Requested update requires the creation of a new physical resource; hence creating one”. To protect yourselves from potential pitfalls precisely like this, take regular snapshots, enable deletion protection, and rigorously review your CloudFormation change sets.

易于使用正确的设置进行修复，但是仍然值得任何计划在生产中使用RDS的人强调。 请密切注意CloudFormation的“请求的更新需要创建新的物理资源； 因此创造一个”。 要像这样精确地保护自己免受潜在陷阱的侵害，请定期拍摄快照，启用删除保护并严格检查CloudFormation更改集 。

If you have any questions about RDS, particularly Aurora Serverless and the RDS Data API, feel free to reach out for further details — I’ll be happy to answer these questions based on my own experiences.

如果您对RDS有任何疑问，尤其是Aurora Serverless和RDS Data API，请随时与我们联系以获取更多详细信息-我将根据自己的经验很乐意回答这些问题。

翻译自: https://medium.com/swlh/rds-updates-avoid-a-common-pitfall-b4aad286b8e8

mysql rds