Skip to content

Why You Should Always Use a Custom DB Parameter Group When Creating an RDS Instance

Before spinning up a new Amazon RDS instance, it’s critical to first make sure you have a new custom DB parameter group ready to use with it. If you don’t, it might become necessary to perform an RDS instance restart to replace the default DB parameter group, even though the database parameter you’d like to change is modifiable and dynamic.

For AWS RDS instances, you manage your database engine configuration through the use of parameters in a DB parameter group. DB parameter groups act as a container for engine configuration values that are applied to one or more DB instances.

A default DB parameter group is created if you make a database instance without specifying a custom DB parameter group. This default group contains database engine defaults and Amazon RDS system defaults based on the engine, compute class, and allocated storage of the instance.

Now, let’s say you need to modify the AUTOCOMMIT DB parameter of your MySQL 5.6 RDS instance. Because it’s modifiable and dynamic, it seems like you can just go ahead and change it and it’ll just take effect, right?

Not so fast. You cannot just modify the parameter settings of a default DB parameter group — you must create your own DB parameter group to change parameter settings from their default value.

For example, this is what happens if you go to the default MySQL 5.6 parameter group and click the “Edit Parameters” button.

With the intention of replacing the default DB parameter group, you proceed to modify the RDS instance and select to apply the changes immediately.

However, this doesn’t mean you’re done. Your RDS instance will now wait for the next reboot before making the DB parameter group replacement effective, even though you just told it to “apply immediately.” The parameter group will show “applying” and then “pending-reboot,” which will clear after you bounce the instance.

The superior method here is to create a new DB Parameter Group before creating the RDS instance, in anticipation of your future needs. Even though you didn’t plan on changing any of the DB parameters at the time, preparing a custom DB parameter group for any new RDS instance provides the flexibility to rapidly realize necessary modifications down the road.

 

FAQ

  1. How do you manage and organize multiple custom DB parameter groups across different environments or projects within AWS to ensure consistency and ease of maintenance?
  2.  
  3. Managing and organizing multiple custom DB parameter groups across different AWS environments or projects requires a systematic approach. Establishing a naming convention that reflects the environment, purpose, and version of the parameter group is important. This helps maintain consistency, simplify updates, and ensure that the right parameter group is applied to the corresponding RDS instance.
  1.  
  2. Are there any best practices for documenting changes to custom DB parameter groups to track the history of adjustments and their impacts on the database performance?
  3.  
  4. Documenting changes to custom DB parameter groups is crucial for maintaining a clear history of modifications. It involves maintaining a change log, either within the AWS environment or through an external documentation system, detailing the changes made, the reason for each change, and its impact on database performance. This practice supports auditing, troubleshooting, and compliance processes.
  1.  
  2. What steps should be taken to securely migrate an existing RDS instance to a new custom DB parameter group without causing downtime or data loss?
  3.  
  4. Migrating an existing RDS instance to a new custom DB parameter group should be done carefully to avoid downtime or data loss. The process typically involves creating the new parameter group, configuring it as needed, and then applying it to the RDS instance during a maintenance window. It's vital to test the changes in a staging environment first, back up the database before making the switch, and closely monitor the system during and after the transition to ensure stability and performance.

 

Author Spotlight:

Ron Eickler

Keep Up To Date With AWS News

Stay up to date with the latest AWS services, latest architecture, cloud-native solutions and more.