Charmed PostgreSQL VM

Channel Revision Published Runs on
latest/stable 345 09 Nov 2023
Ubuntu 22.04 Ubuntu 20.04 Ubuntu 18.04 Ubuntu 16.04 Ubuntu 14.04
latest/stable 239 09 Feb 2022
Ubuntu 22.04 Ubuntu 20.04 Ubuntu 18.04 Ubuntu 16.04 Ubuntu 14.04
latest/stable 226 01 Apr 2021
Ubuntu 22.04 Ubuntu 20.04 Ubuntu 18.04 Ubuntu 16.04 Ubuntu 14.04
14/stable 468 11 Sep 2024
Ubuntu 22.04
14/stable 467 11 Sep 2024
Ubuntu 22.04
14/candidate 468 02 Sep 2024
Ubuntu 22.04
14/candidate 467 02 Sep 2024
Ubuntu 22.04
14/beta 502 23 Oct 2024
Ubuntu 22.04
14/beta 503 23 Oct 2024
Ubuntu 22.04
14/edge 516 Yesterday
Ubuntu 22.04
14/edge 515 Yesterday
Ubuntu 22.04
juju deploy postgresql --channel 14/stable
Show information

Platform:

Ubuntu
22.04 20.04 18.04 16.04 14.04

Remove or recover a cluster

This guide will cover how to manage clusters using an example PostgreSQL deployment with two servers: one in Rome and one in Lisbon.

Prerequisites

Summary


Switchover

If the primary cluster fails or is removed, it is necessary to appoint a new cluster as primary.

To switchover and promote lisbon to primary, one would run the command:

juju run -m lisbon db2/leader promote-to-primary

Detach a cluster

Clusters in an async replica set can be detached. The detached cluster can then be either removed or reused.

Assuming lisbon is the current primary, one would run the following command to detach rome:

juju remove-relation -m lisbon replication-offer db2:replication

The command above will move the rome cluster into a detached state (blocked) keeping all the data in place.

Reuse a detached cluster

The following command creates a new cluster in the replica set from the detached rome cluster, keeping its existing data in use:

juju run -m rome db1/leader promote-to-primary

Remove a detached cluster

The following command removes the detached rome cluster and destroys its stored data with the optional --destroy-storage flag:

juju remove-application -m rome db1 --destroy-storage

Recover a cluster

If the integration between clusters was removed and one side went into a blocked state, integrate both clusters again and call the promote-cluster action to restore async replication - similar to the “Reuse a detached cluster” step above.

If the cluster group lost a member entirely (e.g. rome is suddenly no longer available to the cluster group originally consisting of rome and lisbon), deploy a new postgresql application and set up async replication. The data will be copied automatically after the promote-cluster action is called, and the new cluster will join the cluster group.


Help improve this document in the forum (guidelines). Last updated 2 months ago.