It’s common to setup a Cluster in any enterprise DB, and AWS makes it easy to create Read/Write replicas across multiple zones if you’d like. What may not be obvious is how to use a R//O (Read-only) replica to your advantage.
Is short, a R/O replicate is a separate, synced copy of your DB, but only allows for Read and not Write operations. It’s got the same login credentials and is typically identical in every way other than not accepting Writes.
If you’re wondering what it’s for, it’s all about speed.
On a typical DB, there are many more Reads than there are Writes. And if it’s faster (much faster) to read from a DB, why not split off your Reads and Writes into separate engines? Even better, how about allowing multiple Reads engines with a round-robin balancer in front of them? Now you have a single engine to handle the small amount of Writes that will happen, and a set of engines for handling the Reads.
While this looks good on the whiteboard, let’s put this into practice in code. If you’re using SQL, hopefully, you have some function deep in your core that executes your queries – something you pass in a “SELECT first_name FROM users” type of command. If so, parse out the commands that start with SELECT and send them to the Read engine, and all others, such as an INSERT or UPDATE to the Write engine and watch your DB performance fly.
A word of caution about using a DB Cluster on any Cloud provider, or even on site. A Cluster implies multiple engines/instances, and these all cost money. A Cluster will never be as cheap as a single DB engine/instance, but if you need to speed, it’s well worth the additional cost.