Master: The primary DB instance that is the target of write (and read) operations.
Standby: A DB instance that will be considered for promotion (available for reads).
Read replica: Implies local or remote read-only instance (a.k.a replica).
What is an Aiven PostgreSQL remote read replica?
When it comes to Aiven PostgreSQL, until remote replica functionality was released a few weeks ago, there were traditionally two types of DB instances namely, Master, and one or more Standby instances. Each standby instance serves two purposes: the first is to be considered for promotion in the event the master fails, and the other is to serve read-only operations.
Standalone read replica is the newest member to this family. The differences between a standby instance and a remote read replica are that, a remote read replica will never be considered for promotion if the master failed, and a standby is always located in the same region as the master.
As with all flavors of standby and read replica instances (local or remote), the mechanism used to replicate data from the master to the replicas is asynchronous. By not relying on network service quality & bandwidth coupled with the low overhead inherent in PostgreSQL streaming replication, the impact to the write and read performance of the Master DB instance is negligible.
Note: A remote read replica can be set up between homogenous or heterogenous cloud providers. For example, you can have your primary service in Google Cloud (Iowa) and have a read replica in DigitalOcean (New York) or Google Cloud (South Carolina).
Why remote read replicas are a business imperative
At this point, you might be wondering what the big deal is about the new addition. The two most fundamental uses of the remote read replica are to provide greater data availability, and increased performance (throughput and latency) for reads and writes. By offloading reads to the replica, you are essentially doing two things:
1. increase read throughput (fairly obvious), and
2. increase write throughput on the master (not so obvious).
To illustrate, let’s say that you have a business-critical application that records online merchandise purchases. In order to record and fulfill those orders you have invested in one of the premium Aiven PostgreSQL plans equipped with a read/write Master and two standby instances, where all the DB instances are located in the same region.
What would happen if the region your Aiven service is running in goes black, as would happen with a natural disaster?. You are then in a situation where you can neither view existing orders, let alone fulfill them. Nor can you record any new orders that your customers want to make from your website. As your sales are impacted, so is your bottom line.
If you were taking advantage of remote read replica functionality, your day would have gone a lot better. Because, the remote read replica will remain fully operational for reads even if the primary region hosting your Master and local replicas becomes inoperable. Therefore, you can continue to fulfill existing orders that were already made.
You can even tweak it so that you can convert the remote read replica to a read/write Master and point your web application to it within a matter of a few minutes, thereby allowing you to continue accepting new orders. In short, a remote read replica provides greater data availability for your business-critical applications.
And availability is just the most obvious benefit of remote read replicas; there are also performance benefits. Especially in the age of globalization, it makes sense to place the data close to consumers. In this case, there may be data that various regional departments share. By allowing for the placement of data close to consumers, a remote read replica makes it more efficient to access.
A similar use case is where massive amounts of data are used in various regions to generate daily performance reports and analytics. Again, replicating and placing this data closest to the regions where the reports and analytics are run for decision makers enables them to make more timely decisions based upon the data. Aiven PostgreSQL remote read replica feature makes this possible.
How to set up a read replica in 7 steps
Setting up a remote read replica is made convenient through the Aiven console. Please follow the instructions below to setup a remote read replica for any non-hobbyist Aiven PostgreSQL plan.
1. Navigate to the Aiven console.
Note: If you don’t have a PostgreSQL service running, create a Startup or higher Aiven PostgreSQL service from the Aiven console per Getting started with Aiven PostgreSQL.
2. Once your PostgreSQL service up and running, navigate to the service details page by clicking on the service name.
3. Click on the “Create a read replica” button shown in the bottom-right corner to get to the new remote read replica configuration screen.
4. Give the remote read replica service a name.
5. Select the Cloud provider who will be hosting the remote read replica service (and the region).
6. Select a plan for the service (default: same plan as the main service).
7. Click “Create” to provision the remote read replica service. Give the service a few minutes to complete startup.
Note: To obtain the credentials to access the remote read replica, simply click on its service name to enter the service details page.
Create your first read replicas today
If you have a business-critical application that requires data (and associated service) to survive complete failure of a cloud provider’s region or wish to increase the performance of your existing Aiven PostgreSQL database, take advantage of the Aiven PostgreSQL remote read replica functionality. The cost is will be nominal compared to benefits and peace of mind it will bring.