High availability for PostgreSQL is complex because it requires multiple components to work seamlessly, can be time-consuming to set up and configure manually, and ongoing maintenance can be challenging.
Using ready solutions like the Crunchy operator for Kubernetes simplifies the process and improves reliability. Crunchy and similar operators provide a tested and production-ready infrastructure that integrates well with PostgreSQL, as well as features like automatic failover, backups, restores, and upgrades, which can be complex to implement manually. Overall, using a ready solution like Crunchy can reduce complexity and free up time and resources to focus on other aspects of your application.
Crunchy Operator
The Crunchy Operator is an open-source Kubernetes operator that automates the management of PostgreSQL clusters. It provides a simple way to deploy, manage, and operate PostgreSQL clusters in a Kubernetes environment, making it easier to run and scale PostgreSQL workloads.
One of the key benefits of using the Crunchy operator is that it allows for high availability and fault tolerance for your PostgreSQL database. When running a PostgreSQL cluster with the Crunchy operator, you can specify the number of replicas to create, which helps ensure that your database is always available in case of a failure.
Here's how high availability works in terms of the Crunchy operator:
The Crunchy operator deploys a primary PostgreSQL instance and one or more replicas.
The primary instance is responsible for accepting read and write requests and replicating changes to the replicas.
If the primary instance fails, one of the replicas is promoted to become the new primary instance.
The Crunchy operator automatically reconfigures the remaining replicas to replicate from the new primary instance.
This ensures that the cluster remains available even if one or more instances fail.
In addition to high availability, the Crunchy operator also provides other features such as backups and restores, scaling, rolling upgrades, and custom configurations using PostgreSQL custom resource definitions (CRDs).
Install Crunchy
We recommend following official Crunchy Quickstart for how to install and get up and running with PGO. Here are some instructions to get Postgres up and running on Kubernetes:
$ kubectl get pods -n postgres-operator
NAME READY STATUS RESTARTS AGE
pgo-7b5d478777-7g6kc 1/1 Running 0 51m
pgo-upgrade-5b576ccfb5-m5qdc 1/1 Running 0 51m
Create cluster
For creating a new PostgreSQL cluster using PGO you should create CRD PostgresCluster. More detailed information about creating a PGO cluster you can found in official documentation.
Create aidboxdb.yml file with the following content
Look at image property. Generally, you can use the default image provided by Crunchy Operator. But we strongly recommend using healthsamurai/aidboxdb:15.2.0-crunchy image as the image that is optimized for Aidbox.
Important notes
image: healthsamurai/aidboxdb:15.2.0-crunchy - we recommend use our aidboxdb image build that is preconfigured for use in PGO
replicas: 2 - in this configuration, we install 1 master and 1 replica
backup options - in this sample, we use local PVC for storing backups. For configuring cloud storages like S3 or GCS you can follow this instructions
pg_hba: ["host all all 0.0.0.0/0 md5"] - for this tutorial we allow non SSL connection
Create a namespace and apply aidboxdb.yml resource
$ kubectl create ns aidboxdb-db
namespace/aidboxdb-db created ⎈ kind-kind 11:21:57
$ kubectl apply -f aidboxdb.yaml
postgrescluster.postgres-operator.crunchydata.com/aidboxdb created
Verify PostgreSQL cluster
$ kubectl get pods -n aidboxdb-db
NAME READY STATUS RESTARTS AGE
aidboxdb-aidboxdb-p2tm-0 4/4 Running 0 12m
aidboxdb-aidboxdb-tc58-0 4/4 Running 0 12m
aidboxdb-backup-qvk7-q7qmv 0/1 Completed 0 11m
aidboxdb-repo-host-0 2/2 Running 0 12m
Connect to the cluster
Get connection credentials. Crunchy operator store all connection information in related Secret resource. In our case it aidboxdb-pguser-aidbox. More detailed information you can be found in the connection tutorial.
$ kubectl describe secret aidboxdb-pguser-aidbox -n aidboxdb-db
Name: aidboxdb-pguser-aidbox
Namespace: aidboxdb-db
Annotations: <none>
Type: Opaque
Data
====
port: 4 bytes # Database port 5432
host: 32 bytes # Local K8S host name
user: 6 bytes # User name
password: 24 bytes # Password
dbname: 6 bytes # database name
verifier: 133 bytes
jdbc-uri: 120 bytes
uri: 101 bytes
Now you can set up this parameter for the Aidbox database connection. Look at Install Aidbox in Kubernetes tutorial
apiVersion: v1
kind: Secret
metadata:
name: aidbox
namespace: prod
data:
...
PGPASSWORD: < password value from aidboxdb-pguser-aidbox secret>
PGUSER: < user value from aidboxdb-pguser-aidbox secret>
You can create a single copy of the existing cluster by creating a new one and specify dataSource parameter. In the next example, we create a stage cluster that is a copy of aidboxdb cluster. Related documentation.
When you needed to restore a specific time version of the cluster, or you want to periodically restore you can specify restore option on backup config.
To change the primary in your HA cluster, you need to update the PostgresCluster spec to include the following fields:
spec:
patroni:
switchover:
enabled: true
This will prepare your cluster for a switchover. To trigger the switchover, you need to add the postgres-operator.crunchydata.com/trigger-switchover annotation to your custom resource. It's recommended to use a timestamp as the value for the annotation so you can track when you initiated the change.
PGO Command Line Interface (CLI) for the Crunchy Operator built as a kubectl plugin, the pgo CLI facilitates the creation and management of PostgreSQL clusters created using the Crunchy Postgres Operator. For more information about using the CLI and the various commands available, please see the pgo CLI documentation.
# Create a new backup
$ kubectl pgo backup aidboxdb -n aidboxdb-db
# Show backups
$ kubectl pgo show backup aidboxdb -n aidboxdb-db
Monitoring
Configure
Enable monitoring capabilities by configuring monitoring.
