Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

You Should Always Use a Custom DB Parameter Group When Creating an RDS Instance — Here’s How

DZone's Guide to

You Should Always Use a Custom DB Parameter Group When Creating an RDS Instance — Here’s How

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.

· Database Zone ·
Free Resource

Running out of memory? Learn how Redis Enterprise enables large dataset analysis with the highest throughput and lowest latency while reducing costs over 75%! 

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?

Image title

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.

Image title

Image title

Image title

Image title

Image title

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

Image title

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.

Image title

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.

Image title

And there you have it!

Ron Eickler is Manager, Cloud Engineering at Stratalux, a consulting and managed services provider for Amazon Web Services (AWS).

Running out of memory? Never run out of memory with Redis Enterprise databaseStart your free trial today.

Topics:
amazon aws ,aws rds ,mysql ,amazon rds ,database management ,database strategy ,database ,mysql 5.6 ,rds

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}