RDS Multi-AZ and Read Replicas

Backups, Multi-AZ, and Read Replicas

Automated Backups

  • 2 Different types: automated backuips and snapshots
  • Automated Backups
    • Allow you to recover your database to any point in time within a "retention period"
    • Retention period can be between one and 35 days
    • 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 backup, 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
    • Enabled by Default
    • Backup data is stored in S3
      • Get free storage space equal to the size of your DB
      • RDS of 10GB, you get 10GB worth of strage in S3
    • Backups are taken within a defined window
    • During the backup window, storage IO may be suspended while your data is being backed up and you may experience elevated latency
      • Define backup window during database creation or edit it
  • Snapshots
    • Done Manually (user initiated)
    • They are stored even after you delete the original RDS instance, unlike automated backups
  • Restoring Backups
    • The restored version of the database will be a new RDS instnace with a new DNS endpoint
    • Completely new database

Encryption

  • Encryption at rest is supported for MySQL, Oracle, SQL Server, PostgreSQL, MariaDB, and Aurora
  • Done using the AWS Key Management Service (KMS)
  • Once your RDS instance is encrypted, the data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots
  • At the present time, encrypting an existing DB instance is not supported
    • To use Amazon RDS encryption for an existing Database, create a snapshot, make a copy of that snapshot, and encrypt the copy
    • THEN, launch a new instance from this snapshot with encryption turned on

What is Multi-AZ

  • Elastic Load balancer with EC2 instances all pointing at RDS database in us-east-1A
  • If the ec2 instances make any changes, the changes are replicated to us-east-1b
  • Disaster recovery only
    • Failure in 1A failovers to us-east-1B
  • The connect.php file had the hostname, which contained the "us-east-1" dns address
    • if you lose the primary database, it wil update the dns address to point to the multi-AZ copy of the database
      • Only deal with DNS endpoints in RDS, never ip Addresses

What is Multi-AZ RDS

  • Allows you to have an exact copy of your production database in another availability zone
  • AWS handles the replication for you, so when your production database is written to, this write will automatically be synchronized to the standby database
  • In the event of planned database maintenance, DB instance failure, or an AZ failure, Amazon RDS will autmatically failover to the standby so that database operations can resume quickly without administrative intervention
  • MULTI-AZ IS FOR DISASTER RECOVERY ONLY!!!!!!
    • NOT FOR PERFORMANCE
      • For performance improvement, you need read replicas
  • Available for SQL Server, Oracle, MySQL server, PostgreSQL, MariaDB, Aurora by Default
    • Don't have to turn on multi-az for aurora, but you do for others

Read Replicas

  • Elastic Load Balancer with EC2 instaces writing to RDS database
  • Read replicas push the writes out to replicas of the database
  • if 90% of your traffic is read traffic to the database, you can have it so that EC2 instances read from read replicas
    • Point each EC2 to a replica
    • Spread the load across read replicas
  • Can have replicas of Replicas
  • Replica in anopther AZ or in a completely different region
  • Allow you to have a read-only copy of your production database
  • Asynchronous replication from the Primary RDS instance to the read replica
  • Use them primarily for very read-heavy database workloads to scale out
  • MySQL Server, PostgreSQL, MariaDB, Aurora
  • USED FOR SCALING, NOT DISASTER RECOVERY!!!!!
    • For disaster recovery, use Multi-AZ
  • Must have automatic backups turned on in order to deploy a read replica
  • Can have up to 5 read replica copies of any database
  • Can have read replicas of read replicas (but watch out for latency)
  • Each read replica will have its own DNS endpoint
  • Can have read replicas that have multi-az enabled
  • Can create read replicas of Multi-AZ source databases
  • Read replicas can be promoted to be their own databases
    • will break replication
  • Can have a read replica in another region outside of the region the production database is in
  • Can enable encryption on read replicas even if primary is not encrypted