Relational Database Service (RDS)

  1. RDS is AWS managed relational db service.
    1. Database will run in EC2 instance within your VPC/Subnet but you can’t SSH or have root access
    2. You can have public access thru DB instance connection string, port, id and password.
  2. DB subnet groups:

    1. While creating DB, you need to pick a DB subnet group for the DB instance to reside in.

    2. A DB subnet group is a collection of subnets (typically private) that you create in a VPC and that you then designate for your DB instances.

    3. Each DB subnet group should have subnets in at least two Availability Zones in a given AWS Region.

    4. From the DB subnet group, Amazon RDS chooses a subnet and an IP address within that subnet to associate with your DB instance.
    5. The DB instance uses the Availability Zone that contains the subnet.

    6. If the primary DB instance of a Multi-AZ deployment fails, Amazon RDS can promote the corresponding standby and subsequently create a new standby using an IP address of the subnet in one of the other Availability Zones.

    7. The subnets in a DB subnet group are either public or private. They can’t be a mix of both public and private subnets. The subnets are public or private, depending on the configuration that you set for their network access control lists (network ACLs) and routing tables.

  3. Size limits
    1. 16 TB is limit for MySQL as of 2018 April. So if you have an existing 10 TB MySql that you want to migrate to AWS RDS, and expect that it will double in one year, go for AWS Aurora (common exam question) as its compatible with MySQL and supports up to 64 TB db size.
  4. Cacheing
    1. Amazon Aurora offer an integrated cache that is managed within the database engine and has built-in write-through capabilities. When the underlying data changes on the database table, the database updates its cache automatically
    2. You can use AWS Elasticache with AWS RDS but you need to customize your code (Eg. EC2 web app calling RDS to get resultset and calling Elasticache API to cache the resultset and later retrieve the result set from elasticache as opposed to RDS)
  5. Two types of backups are supported
    1. Automatic Backups
      1. Enabled by default
      2. Backup data is stored in S3 (you get free S3 storage allowance equal to the size of your RDS db)
      3. Daily snapshots + transaction logs
      4. AB’s let you recover at any point of time within a retention period
      5. Retention period can be set as 1 day to 35 days
      6. Backups are taken at a specified window of time
      7. During the backup time the latency may be higher than normal so choose a backup window time which is least in demand for your services
      8. Deleted automatically when you delete RDS inst.
    2. Manual Snapshots
      1. Snapshots are manual
      2. Initiated by the admins
      3. Unlike automatic backups, the snapshots are available even after you deleted your RDS instances
      4. When you restore a snapshot it will create a new RDS instance with a new endpoint.
  6. Encryption:
    1. You can encrypt your Amazon RDS instances and snapshots at rest by enabling the encryption option for your Amazon RDS DB instance.
    2. Amazon RDS encrypted instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server’s EBS that hosts your Amazon RDS instance.
    3. Once your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. You don’t need to modify your database client applications to use encryption.
    4. Encryption at rest is done thru AWS KMS
    5. supported for MySQL, Oracle, MariaDb, SQL Server  and PostGreSQL
    6. Existing un-encrypted db can’t be encrypted. You need create a new encrypted RDS instance and migrate to it
    7. All storage, snapshots, automatic backups, read replicas will be encrypted as well if source is encrypted
  7. Multi AZ deployment for high availability  (Resilient pillar)
    1. Synchronously replicated in another AZ
    2. Automatic fail over (dns endpoint remains same. No need to point to the secondary db)
    3. Disaster Recovery (DR) purpose only (Resilient pillar). Not for performance. Use read replicas instead for scalability and performance enhancements.
  8. Read Replicas  (Performance pillar)
    1. They are different from multi Availability Zone deployment
    2. Asynchronous replication (NOT Synchronous)
    3. Replica lag will be there (time taken to sync once master is modified)
    4. Creates exact copy of master db
    5. If multi AZ is enabled, then RR uses secondary db to create the initial snapshot thus avoiding 1 min slowdown time which would otherwise happen
    6. Read replicas have separate end points which can be directly used by EC2 instances running applications (connection strings)
    7. Read replicas can have read replicas (Double replica lag)
    8. MySQL, Maria Db and PostgreSQL support 5 Read Replicas. Aurora supports upto 15 read replicas.
    9. RRs can be a different region/AZ for MySQL
    10. RRs can be promoted to be master dbs. Once promoted, the RR link will be lost and the promoted instance will act as an independent master db
    11. RRs are Read only. Can’t write to RRs
    12. Scaling up (Better CPU/Memory/Instance Type) is a manual process unlike in DynamoDB where scaling can take place with push button
  9. Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
    1. Commonly used in disaster recovery strategy, RPO is the amount of data loss measured in time (Eg: Last 10 min of data is lost)
    2. RTO is the amount of time needed to restore a business process to its service level. (Eg. Took 2.5 hours to bring production up and running after disaster)
<<< Cloud FormationDynamoDB NoSQL key value and document database >>>
Copyright 2005-2016 KnowledgeHills. Privacy Policy. Contact .