数据设置默认值_Amazon Aurora MySQL 数据库配置最佳实践

在AWS Cloud当中迁移或启动新的Amazon Aurora MySQL实例之后，您是否考虑过以下几个问题？

• “接下来该做什么？我该如何让实例保持最佳运行状态？”
• “是否需要对现有参数做出修改？”
• “具体该对哪些参数做出修改？”

如果这些问题确实困扰着您，希望本篇文章能给大家带来一点有意义的指导与启发。

在本文中，我们将探讨、阐述并总结Amazon Aurora（兼容MySQL）当中的参数配置建议。这些数据库参数本身及其取值，将在AWS Cloud内新创建或迁移实例的存留、调优及重新配置当中发挥重要作用。另外，我们还将讨论应该将Amazon RDS for MySQL中的哪些参数保留至Aurora实例当中。最后，本文还将论述参数的默认值、哪些参数对您实例的稳定性及性能优化至关重要等具体问题。

在执行变更之前，首先需要明确的就是变更背后的需求与动机。尽管大多数参数设置已经具有不错的默认值，但应用程序工作负载本身的变化可能要求我们对参数做出具体调整。因此在着手修改之前，请先回答以下几个问题：

• 当前是否存在稳定性问题，例如重新启动或者故障转移？
• 我能让应用程序的查询运行速度更快一些吗？

Aurora参数组快速入门

Aurora MySQL参数组分为两种类型：数据库参数组与数据库集群参数组。其中某些参数会对整个数据库集群的配置产生影响，例如二进制日志格式、时区与字集集默认值等。其他参数的影响范围则仅限于单一数据库实例。

在本文中，我们将结合不同的上下文对各项参数进行分类，聊聊哪些参数会影响Aurora集群的行为、稳定性及功能，而哪些参数会在变更之后影响性能表现。

需要强调的是，这两种参数类型都具有预设默认值，而且只有部分参数允许修改。

要深入了解参数组的修改与使用基础知识，请参阅《Aurora用户指南》中的以下主题：

• 如何使用数据库参数组与数据库集群参数组
• Aurora MySQL参数

在对生产数据库“下手”之前

参数变更往往会产生意想不到的结果，包括性能下降或者系统不稳定等。在对任何数据库配置参数做出变更之前，请首先思考以下最佳实践：

• 在测试环境中为生产实例创建克隆或还原快照（详见说明文档）。通过这种方式，您既获得高度近似于生产环境的测试条件，又不致对实际业务造成影响。
• 为测试实例生成可模拟生产工作负载的工作负载。
• 根据各项关键性能指标检查系统性能，具体包括CPU利用率、数据库连接数量、内存利用率、缓存命中率、查询吞吐量以及延迟等。请在执行变更之前提取这些基准数据，并在变更之后观察结果变化。
• 一次只变更一项参数，以避免发生歧义。
• 如果变更未能对测试系统产生可以直接测量的影响，请考虑将参数恢复为默认值。
• 记录哪些参数能够产生积极影响，以及哪些性能指标因变更而发生了切实改善。

默认参数值及其重要性

某些数据库实例参数当中包含变量或者公式，其值则由常量确定——例如实例大小、内存占用量、实例的网络端口及其分配到的存储容量等。大家最好不要变动这些设置，因为这些参数会随着实例的规模伸缩而自动调整。

例如，Aurora数据库参数innodb_buffer_pool_size的默认值为：

{DBInstanceClassMemory*3/4}
DBInstanceClassMemory 
是一项变量，以GiB为单位设置为您实例的内存大小。

例如：对于拥有30.5 GiB内存的db.r4.xlarge实例来说，此值为20090716160 bytes，即18.71 GiB。

假如我们决定将此参数设置为一个固定值，例如18000000000 bytes，而后对db.r4.large实例执行缩容操作，那么实例总内存将降低至原本的一半（15.2 GiB）。在对数据库引擎的修改完成之后，我们很可能遭遇内存不足问题，并导致