This is what happens when you hit ‘scale up’:
- We fire up a new server in your cloud
- We install your database server (the same version as the original server)
- A full backup of the original server is taken and restored on the new server
- The new server is configured as a slave of the master database
- The master database is configured according to this new setup
- A new set of environment variables are made available to be used in your code and scripts
Why would you use database replication you ask? These are some common use-cases:
- Load balancing - write to one database and read from many.
- Failover- if something happens to the master database, you can switch to the slave.
- Long-running queries- avoids locking tables by not running queries on the production database. Mostly useful for reporting databases.
The actual replication differs by database server, but here are the main aspects of our implementation:
- MySQL: There is only one master server - all other servers are set up as read-only replicas.
- PostgreSQL:There is only one master server - all other servers are set up as read-only replicas. Replication is setup as Streaming Replication.
- MongoDB: Scaling up a MongoDB sets up a replica set, which builds an odd number of servers.
- Redis: There is only one master server - all other servers are set up as replicas, and any changes on them are overwritten by the master.
For more information, please refer to our documentation. We hope you enjoy this new feature, and as always, let us know if you have any questions!