Ref: https://learn.cantrill.io/courses/1820301/lectures/41301422

• Summary:
• Contents:

RDS Multi-AZ - Instance Deployment

• 💡 Historically the only mode/deployment/architecture of Multi-AZ mode, which provides HA
  • Plain “RDS Multi-AZ” = RDS Multi-AZ Instance Deployment
  • Nowadays there's a more modern architecture with RDS Multi-AZ Cluster Deployment
• 🔧 Primary instance + one single standby instance/replica
  • Primary and standby are in different AZs of the same region
  • Primary data synchronously replicated to standby
    • ‼️ Replication only at the storage level!
      • less efficient than RDS Multi-AZ Cluster Deployment
      • depends on the selected DB engine
  • DB operations committed once registered in both primary and standby
  • ❗ No free tier → Extra replica (standby) carries costs

• All DB accesses done via DB CNAME, which points at primary instance

  • ‼️ Standby is NEVER accessed for reads nor writes!!

• Backups can occur from standby

  • Data moved to S3 & replicated across multiple AZs of the region
  • Backups won't put extra load on primary (important since all DB access is to primary)

• Failover architecture in place, which improves availability

  • Multiple possible reasons for failover: AZ outage, primary failover, manual failover, instance type change, SW patching…

  • If failover is detected, RDS automatically updates DB CNAME to point to standby

    • Standby becomes the new primary instance
    • ❗ Failover switch can take between 60-120 seconds → brief outage
    • 💡 Emptying in-app DNS cache for DB CNAME can reduce failover outage time

    

• 💡 Standby's function is simply to sit there until you have a failure scenario with primary

  • Improves availability
  • Since backups are taken from standby, no negative performance impact on primary
  • No performance scaling, however, since all DB access (Reads & Writes) goes to primary

RDS Multi-AZ - Cluster Deployment

• 🔧 One Writer instance + 2 Reader instances, all in different AZs of the same region
  • 💡 More HA than Multi-AZ Instance
  • Synchronous replication from Writer to both Readers
  • DB operations committed once registered in the Writer and AT LEAST 1 Reader confirms
    • at that point data is resilient across multiple AZs
  • Writer can be used for Reads AND Writes; Readers for Reads but NOT Writes
    • 👍 Allows scaling of Read workloads, unlike Multi-AZ Instance
      • 💡 Can reach highest levels of performance for RDS. Aurora as a DB platform can scale even more
    • 👎 Requires app support
      • app must be aware it can't use the same instance for Reads and Writes
    • 👎 More instances → more expensive than RDS Multi-AZ Instance Deployment
  • ‼️ Do NOT confuse with Aurora clusters!!
    • Aurora clusters can have more than 2 Reader instances
    • Each RDS instance has its own local EBS storage, which is different from Aurora

• DB cluster accessed with endpoint types (similar to Aurora)
  • Cluster endpoint → Points at Writer, can be used for Reads, Writes, and admin functions
    • 💡 like CNAME endpoint in Multi-AZ Instance
  • Reader endpoint → Directs any Reads at an available reader instance
    • ❗ In some cases, this will direct to Writer! (since it can also be used for Reads)
    • Generally points to Readers → allows Read scaling
  • Instance endpoints → point at specific instance
    • Each instance has one
    • ‼️ Not recommended for general use!
      • No toleration of instance failures, they don't switch to other instances
      • Use them for testing & fault finding
• Transaction logs: register all transactions done to the DB
  • Useful when there’s a DB outage
  • 👍 Allows more efficient replication
  • 👍 Allows faster failover: ~35secs + transaction log apply
    • transaction log apply = time required to apply transaction logs to Readers
• Other advantages over Multi-AZ Instance Deployment:
  • 👍 Much faster HW: Graviton architecture + local NVMe SSD storage
  • 👍 Fast writes to local storage, which is then flushed to EBS
    • 💡 Benefits of super fast local storage + availability & resilience benefits of EBS