What is a Parameter Group?


Understanding RDS Scaling & Elasticity
Scaling with RDS
Configuring Operational Parameters for AWS Databases
When to use RDS Multi-AZ & Read Replicas
RDS Multi AZ
Read Replicas

The course is part of this learning path

Start course
2h 8m

This course covers the core learning objective to meet the requirements of the 'Designing Database solutions in AWS - Level 3' skill

Learning Objectives:

  • Analzy targert AWS database platforms when performing a migration
  • Create and deploy an enterprise-wide scalable RDS Database solition to meet and exceed workload performance expectations
  • Create an AWS database slution to withstand AWS global infrastructure outages with minimal data loss

A parameter group is a collection of engine configuration values that you set for your RDS database instance. It contains the mapping of what you want each of these over 400 unique parameters to be set to. Now you may be thinking, I have never made a parameter group before, and I have created dozens of RDS databases. Well that is because all of the databases you already built were done so using a default parameter group specified by AWS. It is not actually necessary to use something other than the default parameters for most amazon RDS for MySQL users

Each default parameter group is unique to the database engine, compute class, and allocated storage of the instance. It is important to note that you have no ability to change a default parameter group, so when you decide to make modifications, you will have to create your own.

Creating your own parameter group is fairly straightforward and is managed through the console or the CLI. Self-created parameter groups take the initial form of the default parameter group of that particular instance / engine combo.

Once created, you can then modify the parameters within the group on the fly using the CLI or the Console. This means you can update and modify your group to suit your needs as you go. Testing and iterating until you come up with the perfect settings for your RDS Database.

When creating and modifying the parameter group, you will see that parameters can either be static or dynamic. This is referencing the ability for the parameter to be changed and affect the instance without an instance restart. So while you can change the values of parameters at any time, they won't reflect back on the instance immediately without a restart if they are a static parameter.

Dynamic parameters operate based on session scope or global scope.

When the variable has global scope, any changes will impact the whole server and all sessions. When the variable has session scope, it is only effective for the session where it was set. To make things more complicated, some variables have both global and session scope.

Amazon has the following to say about that: “Some variables have both global and session scope. In such cases, the global value is default for the session scope. Any global change to a parameter that also has a session scope only affects new sessions.”

I would like to mention that Amazon also has a warning for the first use of a parameter group that is important to know:

“After you create a DB parameter group, you should wait at least 5 minutes before creating your first DB instance that uses that DB parameter group as the default parameter group. This allows Amazon RDS to fully complete the create action before the parameter group is used as the default for a new DB instance. This is especially important for parameters that are critical when creating the default database for a DB instance“ - Source.

And you can take a look here for more information.

Alrighty, well now that we have that out of the way, let's go over a few real-world examples of some of the parameters that you can tune with a parameter group.

About the Author
Learning Paths

Stephen is the AWS Certification Specialist at Cloud Academy. His content focuses heavily on topics related to certification on Amazon Web Services technologies. He loves teaching and believes that there are no shortcuts to certification but it is possible to find the right path and course of study.

Stephen has worked in IT for over 25 years in roles ranging from tech support to systems engineering. At one point, he taught computer network technology at a community college in Washington state.

Before coming to Cloud Academy, Stephen worked as a trainer and curriculum developer at AWS and brings a wealth of knowledge and experience in cloud technologies.

In his spare time, Stephen enjoys reading, sudoku, gaming, and modern square dancing.