Ref: https://learn.cantrill.io/courses/1820301/lectures/41301422
RDS Multi-AZ - Instance Deployment
- 💡 Historically the only mode/deployment/architecture of Multi-AZ mode, which provides HA
- 🔧 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