Tags Archives: rds

AWS DB Parameters

Database or DB parameters specify how your database is configured. For example, database parameters can specify the amount of resources, such as memory, to allocate to a database.


You manage your database configuration by associating your DB instances and Multi-AZ DB clusters with parameter groups. Amazon RDS defines parameter groups with default settings.


A DB Parameter Group is a collection of engine configuration values that you set for your RDS database instance.


It contains the definition of what you want each of these over 400 parameters to be set to.


By default, RDS uses a default parameter group specified by AWS. It is not actually necessary to use a different parameter group.


Each default parameter group is unique to the database engine you select, the EC2 compute class, and the storage allocated to the instance.


You cannot change a default parameter group, so if you want to make modifications then you will have to create your own parameter group.


RDS database engine configuration is managed through the use of parameters in a DB parameter group.


DB parameter groups serve as an effective container for holding engine configuration values that are applied to your 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.



When you create a new RDS database, you should ensure you have a new custom DB parameter group to use with it. If not then you might have to perform an RDS instance restart later on to replace the default DB parameter group, even though the database parameter you want to alter is dynamic and modifiable.


This is the best approach that gives you flexibility further down the road to change your configuration later on.


Creating your own parameter group can be done via the console or the CLI. Self-created parameter groups take as their basis the default parameter group for that particular instance and selected db engine.


After creation, you can then modify the parameters via the console or CLI to suit your needs as you change.


Parameters can either be static or dynamic.


Static means that changes won’t take effect without an instance restart.


Dynamic means a parameter change can take effect without an instance restart.


Dynamic parameters are either session scope or global scope.


Global scope dynamic parameters mean that changes will impact the entire server and all sessions.


Session scope dynamic parameters however are only effective for the session where they were set.


Note however that some parameter variables can have both global and session scope.


In these cases, the global value is used as the default for the session scope and any global change to a parameter that also has a session scope will only affect new sessions.


Another important aspect to bear in mind when creating 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.



For exam!


Important to know this DB Parameter above all for the exam:


for PostgreSQL and SQLServer:




this forces ssl connections to be used




BUT – for MySQL /MariaDB you must instead use a grant select command:


GRANT SELECT ON mydatabase.* TO ‘myuser’@%’IDENTIFED BY ‘…’ REQUIRE SSL;




Continue Reading


 RDS is the AWS Relational Database Service



a managed DB service for DB, uses SQL, is a “serverless service”, which runs:


MS SQL Server
AWS Aurora (AWS proprietary DB)



You have to know this for the exam!


Advantages of RDS vs a db engine on an EC2 instance


rds is managed by AWS
automated provisioning, os and db engine upgrades and patching
continuous backups and point-in-time restore
monitoring dashboards
read replicas for improved read performance
multi-AZ for disaster recovery (DR)
maintenance windows for upgrades
scaling capacity, both horizontal and vertical
storage backed by EBS


BUT . you can’t SSH into the RDS instances – we don’t have access to the engine or underlying OS. RDS is purely a managed DB solution.


RDS Backups


automatically enabled
daily full backup
transaction logs backed up every 5 mins
can restore to any point in time
7 days retention, can be increased to 35 days



DB Snapshots


rds db snapshots have to be manually triggered by user

retention for as long as you want




RDS Storage Auto Scaling


dynamic increase in storage is automatic – so this avoids manual scaling, but you have to set a Max Storage Threshold ie limit for db storage – exam question!


set rds to automatically modify storage if:


free storage is less than 10% of allocated storage


low storage lasts at least 5 mins

6 hrs have passed since last modification


useful for apps with unpredictable workloads


supports all rds DB engines – MariaDB, MySQL, PostgreSQL, SQL server and Oracle



Read Replicas with RDS


RDS read replicas provide for faster reads, but not for writes


you create a replica of the DB – up to 5 MAX – can be in the same AZ, cross AZ or cross-region – not needed for exam!


Asynchronous replication takes place – but there is a time lag involved.


hence:  “eventually consistent async replication”


exam question:
a replica can be promoted to become a full separate read-write DB.


application clients must update connection string to connect to the read replica/s.


a very typical exam question use case example:


eg prod DB but you need to run intensive read analysis eg reporting…


this would slow down the prod DB, so you can create a read replica to run the read process from there.


note: only SELECT type statements can be run ie reads, NOT insert, update, delete etc





normally a charge for data transfer from one AZ zo another


but AWS does not charge for RDS read replica data traffic within the same REGION


ie is for free


BUT cross-region is chargeable…


Using RDS Multi-AZ for Disaster Recovery (DR)


This is a common use case for multi-az RDS systems.


This uses sync replication – this means that when the application writes to the master db instance, it is also written to the standby DB instance in the other AZ at the same time.


one dns name, auto app failover to the standover, this increases availability, meaning there is no manual intervention in apps necessary for the changeover. 


Note that it is not used for scaling, just for failover from master db in the event of a failure of the master db.


Note that a lot of questions in exam focus on RDS!


the read replicates can also be set up as multi-az for DR – this is often an exam question! In this case they switch from async replication to sync replication.



How to Move RDS from Single-AZ to Multi-AZ


There is no need to stop DB – just click on modify for the db


how it happens:


a snapshot is done automatically from master db and this is then restored from snapshot to a new db in the new az



a sync is then done. You then have a multi-AZ RDS DR setup.




my rds test database:


Endpoint & port
Endpoint: database-1.c2duk8wm0bjt.us-east-1.rds.amazonaws.com
Port  3306



More on RDS 


its a managed db on the postgresql/myswl/Oracle/SQL level


you must however an ec2 instance and ebs vol type and sufficient size


it supports read replicas and multi-AZ
security is via iam and security groups, kms, and ssl in transit
backup, snapshot and point in time restores all possible


managed and scheduled maintanance


monitoring available via cloudwatch



use cases include:


storing relational datasets rdbms/oltp performing sql queries, transactional inserts, update, delete is possible


rds for solutions architect, considerations include these “5 pillars”:





operations_ small downtimes when failover happens, when maintenance happens, when scaling read replicas, ec2 instances, and restoring from ebs, this requires manual intervention, and when application changes



security: aws is responsible for os security, but we are responsible for setting up kms, security groups, iam policies, authorizing users in db and using ssl



reliability: the multi-az feature makes rds v reliable, good for failover in failure situations


performance: dependent on ec2 instance type, ebs vol type, can add read replicas, storage autoscaling is possible, and manual scaling of instances is also possible


costs: is pay per hour based on provisioned number and type of ec2 instances and ebs usage



Continue Reading