We now make it easy for you to replicate your databases between
stacks. There are many use cases for this, but here are the main ones:
- Preparing a failover for an existing stack
This allows you to have a replica of your production database somewhere else (eg. a different region) in case of disaster. Should the master database fail, you can easily switch over to use the slave.
- Moving your stack to a different cloud vendor/region
You find out that most of your users are based in Asia, while your servers are in Europe. You can migrate your stack from one data center to another, setting up a slave database in the new region that will constantly read the master database. Once you’re happy with your migration, you can simply switch the slave to a master.
- Using your database in applications like reporting tools
It’s often not desirable to use your production database fornon-critical functions like reporting tools. For example, if a user queries the database incorrectly, this could bring down your production database! In this case, it’s better to have a replicated database that simply reads from your production database.
Setting up replication between stacks involves just a few clicks for our users, but this is what happens in the background:
- We take a full backup of the database in your source stack and restore it on the target server
- The target server is configured to be a slave of the source database, and vice-versa
- The relevant environment variables are updated for use in your code and scripts
Have a look at our documentation for more details about database
replication between stacks.