5_RDS Flashcards Preview

Architecting on AWS > 5_RDS > Flashcards

Flashcards in 5_RDS Deck (12)
Loading flashcards...
1
Q

AWS Databases Types

  • RDS - OLTP (read the FAQ!)
    • SQL Server
    • MySQL
    • PostgreSQL
    • Oracle
    • Aurora
    • MariaDB
  • DynamoDB - NoSQL
  • RedShift - OLAP
  • Elasticache - In Memory Caching
    • Memcached
    • Redis
A

AWS Databases Types

  • RDS - OLTP (read the FAQ!)
    • SQL Server
    • MySQL
    • PostgreSQL
    • Oracle
    • Aurora
    • MariaDB
  • DynamoDB - NoSQL
  • RedShift - OLAP
  • Elasticache - In Memory Caching
    • Memcached
    • Redis
2
Q

Automated Backups

There are two different types of Backups for AWS: Automated Backups and Database Snapshots.

Automated Backups allow you to recover your database to any point in time within a “retention period”. Retention period can be between one (default) and 35 days. Automated Backups will take a full daily snapshot and will also store transaction logs throughout the day. When you do a recovery, AWS will first choose the most recent daily back up, and then apply transaction logs relevant to that day. This allows you to do a point in time recovery down to a second, within the retention period.

A
3
Q

Automated Backups

Automated Backups are enabled by default. The backup data is stored in S3 and you get free storage space equal to the size of your database. So if you have an RDS instance of 10Gb you will get 10Gb worth of storage.

Backups are taken within a defined window (preferred backup window). During the backup window, storage I/O may be suspended while your data is being backed up and you may experience elevated latency.

A
4
Q

Snapshots

Snapshots are user-initiated storage volume snapshot of DB instance, backing up the entire DB instance and not just individual databases that can be restored as a independent RDS instance.

They are stored even after you delete the original RDS instance, unlike automated backups.

A
5
Q

Restoring Backups

Whenever you restore either an Automatic Backup or a manual Snapshot, the restored version of the database will be a new RDS instance with a new end point.

Preferred backup window: is the user-defined period of time during which your DB Instance is backed up (<> Maintenance window). During the backup window, storage I/O may be briefly suspended while the backup process initializes. There is no I/O suspension for Multi-AZ DB deployments, since the backup is taken from the standby.

A
6
Q

When to use RDS?

A
7
Q

Multi-AZ RDS

Multi-AZ allows you to have an exact copy of your production database in another Availability Zone of the same Region. AWS handles the replication for you, so when your production database is written to, this write will automatically be synchronized to the stand by database.

Multi-AZ deployments utilize synchronous replication, making database writes concurrently on both the primary and standby so that the standby will be up-to-date in the event a failover occurs.

In the event of planned database maintenance, DB Instance failure, or an Availability Zone failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without administrative intervention and updates the DNS record to point to standby. Snapshots and backups are taken from standby and eliminate I/O freezes

Multi-AZ is for Disaster Recovery only. It is not primarly used for improving performance. For performance improvement you need Read Replicas.

A
8
Q

Multi-AZ Database available for:

  • SQL Server
  • Oracle
  • MySQL Server
  • PostgreSQL
  • MariaDB
A
9
Q

Read Replica

Read Replica’s allow you to have a read only copy** of your production database. This is achieved by using **Asynchronous replication from the primary RDS instance to the read replica. You use read replica’s primarly for very-heavy database workloads. While Read Replicas can provide some read availability benefits (read scaling), they are not designed to improve write availability.

Available for:

  • MySQL Server
  • PostgreSQL
  • MariaDB
A
10
Q

Read Replica

There are a variety of scenarios where deploying one or more Read Replicas for a given source DB Instance may make sense. Common reasons for deploying a Read Replica include:

  • Scaling beyond the compute or I/O capacity of a single DB Instance for read-heavy database workloads. This excess read traffic can be directed to one or more Read Replicas.
  • Serving read traffic while the source DB Instance is unavailable. If your source DB Instance cannot take I/O requests (e.g. due to I/O suspension for backups or scheduled maintenance), you can direct read traffic to your Read Replica(s). For this use case, keep in mind that the data on the Read Replica may be “stale” since the source DB Instance is unavailable.
  • Business reporting or data warehousing scenarios; you may want business reporting queries to run against a Read Replica, rather than your primary, production DB Instance.
A
11
Q

Multi-AZ vs Read Replica

  • Read Replica is used for scaling**, not for **Disaster Recovery (DR)
  • You must have automatic backups turned on in order to deploy a read replica
  • You can have up to 5 read reaplicas copies of any database
  • You can have read replicas of read replicas (but watch out for latency)
  • Each read replica will have its own DNS end point
  • You cannot have Read Replicas that have Multi-AZ, i.e. a Read Replicas cannot have a Multi-AZ copy
  • You can create Read Replica’s of Multi-AZ source databases however
  • Read Replicas can be promoted to be their own databases. This breaks the replication
  • Amazon RDS for MySQL, MariaDB and PostgreSQL supports cross-region Read Replicas.
  • If you are looking to increase database write availability by taking backups from your Read Replica instead of its source DB Instance, you can accomplish the same objective by running your DB Instance as a Multi-AZ deployment. Backups will then be initiated from the Multi-AZ standby to minimize availability impact.
A
12
Q

RDS - Exam Tips

  • By default, customers are allowed to have up to a total of 40 Amazon RDS DB instances. Of those 40, up to 10 can be Oracle or SQL Server DB instances under the “License Included” model.
  • Maintenance Window: Weekly timeframe when DB instance modifications (such as scaling DB instance class) and software patching occur, in the event they are requested or required. Maintenance windows are 30 minutes in duration. Can be choosen by the user.Â
A