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.
Join the DZone community and get the full member experience.Join For Free
This article was originally published on June 28, 2018.
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.
And there you have it!
Opinions expressed by DZone contributors are their own.
Microservices: Quarkus vs Spring Boot
AWS Multi-Region Resiliency Aurora MySQL Global DB With Headless Clusters
What Is mTLS? How To Implement It With Istio
8 Data Anonymization Techniques to Safeguard User PII Data