In our ongoing efforts to enhance data resilience and recovery capabilities, we are excited to announce the public preview of substantial enhancements to our multi-region disaster recovery (DR) strategy for Azure Database for PostgreSQL - Flexible Server. This upgrade is centered around two pivotal features: Virtual Endpoints and the Promote to primary server operation, each designed to simplify and strengthen DR capabilities.
A crucial aspect for any mission-critical application is maintaining operations during unforeseen regional disruptions. To address this, we've rolled out the Promote to primary server feature. This new addition allows for a swift and straightforward swap of roles between your primary database and its replica, ensuring continuous operations with minimal interruption.
In tandem with this, we introduce Virtual Endpoints: your database's steadfast links that remain unchanged, irrespective of role swaps. As a result, the writer endpoint will always connect to the current primary server, and the reader endpoint will point to the current replica. This feature ensures that, even after a promotion event, your application's connection strings remain valid, eliminating the need for manual updates and thereby streamlining your disaster recovery operations.
To locate this feature, simply navigate to the replication blade in the Azure portal. Here, you can manage these settings and familiarize yourself with the seamless disaster recovery options available.
Screenshot of replication blade in Azure portal.
These enhancements collectively simplify your disaster recovery operations. They enable a hassle-free, manual failover to a read replica in a different (or the same) region and an equally smooth return to the primary server, streamlining the failover and failback processes. This simplicity is a game-changer for running regular disaster recovery drills, allowing for a swift and efficient response with virtually no negative impact on your applications.
Below you'll find a diagram that illustrates the pre-promotion configuration with virtual endpoints set up to point to the current primary and replica servers. After executing the promote to primary server operation, the roles of the servers are exchanged, and the virtual endpoints automatically adjust to align with the new server roles.
Diagram of promote to primary server flow.
It's important to note that the existing functionality, which allows a read replica to become a standalone server, has been renamed to "Promote to independent server and remove from replication". This clarifies the different use cases between creating an independent server versus swapping server roles within a replication setup.
You have the option to use virtual endpoints with the “Promote to independent server and remove from replication” action, although it's not a requirement. The accompanying diagram shows the change in server roles and how the virtual endpoints behave after the promote operation.
Diagram of promote to independent server flow.
The promotion of a read replica to a primary server in Azure Database for PostgreSQL - Flexible Server can be executed in two ways:
By choosing the correct promotion option for your situation, you can optimize for data consistency or recovery speed as required.
Further information about the new read replica features in Azure Database for PostgreSQL - Flexible Server is available on read replica documentation. Additionally, for practical guidance, you can follow the how-to tutorial.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.