Installing and Upgrading High Availability (HA) Embedded Database Cluster
You must plan your installation, upgrade, and rollback operations based on your environments.
There are three phases that constitute the installation process.
If the database mode is HA, the following components must be
installed in the same order as described:
- Dedicated Longhorn storage class - Applicable only for Cloudera Embedded Container Service installations only
- CloudNativePG - PostgreSQL Operator for Kubernetes
- HA DB cluster and associated artifacts
During the installation process, only after installing the Longhorn system, the Longhorn storage class must be installed. The new storage class is based on the default Longhorn storage class.
Verify if the operator Pods are running and the Custom Resource Definition (CRD) are installed before continuing to install the Database cluster.
For the DB cluster installation, the helm chart contains templates for the secrets,
cluster, network policy, service and podmonitor described below. In addition, existing templates
from embedded-db except for pvc, statefulset and service will be included in the
cluster helm chart. The CA and server certification and the db admin (PostgreSQL)
username/password are automatically inherited as part of the installation process.
Backward compatibility is supported for the existing DB clusters.
After the installation process is completed, you can use the following command to check for cluster readiness.
kubectl wait --for=jsonpath='{.status.phase}'='Cluster in healthy state'
cluster/ha-embedded-db -n cdp --timeout=300s
Upgrading Data Services on premises cluster
Short Description: To upgrade an existing HA DB cluster, the requirements are the same as compared to the fresh installation. But varies on a couple of scenarios.
The HA db cluster must migrate data from existing non-HA embedded db clusters. Either migrate from the same PostgreSQL major version or from an older version.
Upgrading with the same Database version
The Data Services on premises Installer verifies the existing Database version on the cluster for consistency.
The following cluster values are used to facilitate the starting up of the new HA db
cluster. The difference lies with the starting up of the new HA db cluster when compared with
that of the installation process. The administrator user postgres must have the
replication permissions to initiate the streaming backup of
pg_basebackup.
Upgrading with the different Database version
For other db version bootstrap, a ‘monolith’ import type of initdb startup method is employed. The rest of the setup is the same as the ‘pg_basebackup’ method by providing source db connection details.
Note: In the CloudNativePG operator, the monolith import
type in an initdb bootstrap specification allows you to import multiple
user-defined databases and roles from an old DB (PostgreSQL) version into a newer DB version
with their original names.
Support for on-demand HA Database migration
There is no separate migration script or a method to support migration from a non-HA cluster to the HA enabled DB cluster. Migration will be enabled when a checkbox is ticked during the respective install and upgrade processes. This is applicable only in the Cloudera Embedded Container Service environment, which includes fresh installation and upgrade processes.
Rollback HA Database migration
- You can scale down to a single instance.
- Reduces the HA cluster topology to a single standalone instance without removing the
CloudNativePG (CNPG) operator control plane.
-
Uncheck the Enable DB Migration option in the Cloudera Manager User Interface during the upgrade workflow.
-
Resultant outcome:
- Bypasses the database migration sequence entirely.
- Reduces storage overhead back to baseline (single-volume requirement).
- Retains the CNPG operator for continuous health monitoring, lifecycle management, and rapid future re-enabling of HA.
-
