Azure Database for PostgreSQL Replication

Sebastian Pacheco 136 Reputation points
2022-03-16T02:26:35.463+00:00

I would like to know what feature Azure Database for PostgreSQL (General Purpose) has by default, specifically about high availability and replication.

***when creating the db select backup "with geo-redundant backup storage."

In the event that something happens to my db, is an automatic movement made to continue running?, the service automatically replicate data? or the client must configure some mechanism of disaster recovery.

I see that there is a "Replication" option and that it is read-only, if that replication is configured and something happens to my primary DB, how should it be configured to continue operating?

Azure Database for PostgreSQL
{count} votes

Accepted answer
  1. Anurag Sharma 17,576 Reputation points
    2022-03-17T06:31:27.077+00:00

    Hi @Sebastian Pacheco , thanks for providing the details.

    Azure PostgreSQL Single Server offers both the local and geo-redundant backups, however geo-redundant backups can only be configured at the time of server creation and backups are stored in paired region (List here)

    If our primary server fails in case of geo-redundant then we need to manually create another server and restore it from the the geo-redundant backups as mentioned in below article. As we are creating new server we need to manually change the connection details to point to this new server. This is not automatic failover.

    Geo restore

    RTO and RPO for different capability is mentioned in below screenshot:

    183967-image.png

    In above screenshot we notice the read replicas have better RTO and RPO compared to geo-redundant backups. Again in the event of a primary server failure, it is not automatically failed over to the read replica.

    Once we have decided we want to failover to a replica,

    1. Stop replication to the replica: This step is necessary to make the replica server to become a standalone server and be able to accept writes. As part of this process, the replica server will restart and be delinked from the primary. Once you initiate stop replication, the backend process typically takes few minutes to apply any residual logs that were not yet applied and to open the database as a read-writeable server. See the stop replication section of this article to understand the implications of this action.
    2. Point your application to the (former) replica: Each server has a unique connection string. Update your application connection string to point to the (former) replica instead of the primary.

    Once your application is successfully processing reads and writes, you have completed the failover. The amount of downtime your application experiences will depend on when you detect an issue and complete steps 1 and 2 above.

    Reference: Failover to replica

    For read-replicas as they are already existing server we just need to use their connection credentials, however for geo-redundant backups firstly we need to create a new server and then use the connection details to work on them.

    However please refer below article for some scenarios where Azure Database for PostgreSQL automatically recovers:

    Unplanned downtime: failure scenarios and service recovery

    Please let us know if this helps or else we will continue the discussion.

    ----------

    If answer is helpful please please click on 183947-image.png as it could help other members of the Microsoft Q&A community who have similar questions and are looking for solutions. Thank you for helping to improve Microsoft Q&A!

    0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Sebastian Pacheco 136 Reputation points
    2022-03-17T20:32:58.597+00:00

    thanks for all @AnuragSharma-MSFT :)

    0 comments No comments