Restoring database clusters in case of an availability zone failure

If one of the availability zones is unavailable, the process depends on the host location and cluster state. In the examples below, the ru-central1-b is assumed to be unavailable. Select the appropriate use case:

• All cluster hosts are in the unavailable zone.
• Some hosts are in the available zone; the master switched.
• Some hosts are in the available zone; the master did not switch, and the cluster is read-only.
• The cluster does not have hosts in the unavailable zone.

All cluster hosts are in the unavailable zoneAll cluster hosts are in the unavailable zone

To reduce the downtime, do not wait for the availability zone to become available again and start restoring from a backup.

1. Check the available cluster’s backups and choose the restore point. Recovery to a certain time period depends on the service and backup type.
2. Restore your cluster from a backup using your service’s guide. When configuring the new cluster, locate its hosts in different availability zones.
3. Wait until the recovery is complete, check the data, and configure your application connection to the new cluster.

Guide on restoring from a backup:

A Managed Service for Sharded PostgreSQL backup contains shard configuration. Restore the shard data separately in Managed Service for PostgreSQL if needed.

Some hosts are in the available zone; the master switchedSome hosts are in the available zone; the master switched

This use case is suitable for a multi-host cluster if a master switched to a host in a different availability zone.

1. Make sure your application connects to the new master and can write data.
2. If adding hosts is not available, add hosts to a different zones to replace the unavailable ones. If you cannot add hosts, contact support.
3. What until the new hosts sync data and will be able to operate. Then delete the hosts in the ru-central1-b zone considering the service limit on the minimum number of hosts. If deletion is temporarily unavailable, try again later.

Guides on managing hosts:

Master did not switch, and the cluster is read-onlyMaster did not switch, and the cluster is read-only

This use case is suitable for a multi-host cluster with some hosts in the ru-central1-b zone, if a master did not switch, and the cluster switched to read-only (RO).

Automatic master switch may not occur because of the risk of data loss. In this use case, you cannot switch the master manually.

1. Contact support. Specify the cluster ID and describe its state.
2. Wait for the support team to switch your master.
3. Perform the actions described in the use case where the master switched.

The cluster does not have hosts in the unavailable zoneThe cluster does not have hosts in the unavailable zone

To prepare for possible failures of other availability zones:

1. Check the cluster’s and application’s configuration using these recommendations on fault tolerance. Consider your service requirements to the host location and number.
2. If you need to set up data transfer and replication, check these Data Transfer guides and requirements on preparing the source and target.

Restoring a cluster from a backup using the OpenSearch APIRestoring a cluster from a backup using the OpenSearch API

You can connect Object Storage to a Managed Service for OpenSearch cluster as a snapshot repository. You will be able to create backups manually or on schedule using the OpenSearch Snapshot API.

1. Create a repository to store snapshots specifying Object Storage.
2. Create a policy for regular snapshot creation.
3. Configure access permissions and add the snapshot repository for your Managed Service for OpenSearch cluster.
4. Configure access permissions and add the snapshot repository for your Managed Service for OpenSearch cluster.

Migrating a database from Managed Service for PostgreSQL to a different PostgreSQL cluster using logical replicationMigrating a database from Managed Service for PostgreSQL to a different PostgreSQL cluster using logical replication

A Managed Service for PostgreSQL cluster supports logical replication. This allows you to use built-in PostgreSQL tools for migrating databases across different PostgreSQL clusters.

To migrate a database, follow this tutorial.