Freigeben über

Überprüfen und Testen einer PostgreSQL-Datenbankbereitstellung auf Azure Kubernetes Service (AKS)

In diesem Artikel führen Sie verschiedene Test- und Validierungsschritte für eine auf AKS bereitgestellte PostgreSQL-Datenbank durch. Dazu gehören die Überprüfung der Bereitstellung, das Herstellen einer Verbindung mit der Datenbank und das Testen von Failoverszenarien.

Von Bedeutung

Open-Source-Software wird überall in AKS-Dokumenten und -Beispielen erwähnt. Software, die Sie bereitstellen, ist von AKS-Vereinbarungen zum Servicelevel, der eingeschränkten Garantie und dem Azure-Support ausgeschlossen. Wenn Sie Open-Source-Technologie zusammen mit AKS nutzen, nutzen Sie die Supportoptionen, die von den jeweiligen Communitys und Projektbetreuenden angeboten werden, um einen Plan zu entwickeln.

Microsoft übernimmt die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung beinhaltet die vollständige Übernahme des Build-, Scan-, Signier-, Validierungs- und Hotfix-Prozesses sowie die Kontrolle über die Binärdateien in Container-Images. Weitere Informationen finden Sie unter Sicherheitsrisikomanagement für AKS und AKS-Supportabdeckung.

Überprüfen des bereitgestellten PostgreSQL-Clusters

Überprüfen Sie, ob PostgreSQL über mehrere Verfügbarkeitszonen verteilt ist, indem Sie die AKS-Knotendetails mithilfe des kubectl get-Befehls abrufen.

kubectl get nodes \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    --output json | jq '.items[] | {node: .metadata.name, zone: .metadata.labels."failure-domain.beta.kubernetes.io/zone"}'

Die Ausgabe sollte der folgenden Beispielausgabe ähneln, wobei die Verfügbarkeitszone für jeden Knoten angezeigt wird:

{
    "node": "aks-postgres-15810965-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-postgres-15810965-vmss000001",
    "zone": "westus3-2"
}
{
    "node": "aks-postgres-15810965-vmss000002",
    "zone": "westus3-3"
}
{
    "node": "aks-systempool-26112968-vmss000000",
    "zone": "westus3-1"
}
{
    "node": "aks-systempool-26112968-vmss000001",
    "zone": "westus3-2"
}

Herstellen einer Verbindung mit PostgreSQL und Erstellen eines Beispieldatensatzes

In diesem Abschnitt erstellen Sie eine Tabelle und fügen einige Daten in die App-Datenbank ein, die in den zuvor bereitgestellten CNPG-Cluster-CRD erstellt wurde. Sie verwenden diese Daten, um die Sicherungs- und Wiederherstellungsoperationen für den PostgreSQL-Cluster zu validieren.

  • Erstellen Sie eine Tabelle und fügen Sie mit den folgenden Befehlen Daten in die App-Datenbank ein:

    kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    -- Create a small dataset
CREATE TABLE datasample (id INTEGER, name VARCHAR(255));
INSERT INTO datasample (id, name) VALUES (1, 'John');
INSERT INTO datasample (id, name) VALUES (2, 'Jane');
INSERT INTO datasample (id, name) VALUES (3, 'Alice');
SELECT COUNT(*) FROM datasample;

    Geben Sie \q ein, um psql zu beenden, wenn Sie fertig sind.

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

    CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
count
-------
    3
(1 row)

Verbindung zu PostgreSQL-Replikaten mit Lesezugriff

  • Stellen Sie eine Verbindung zu den PostgreSQL-Replikaten mit Lesezugriff her und validieren Sie das Beispieldataset mit den folgenden Befehlen:

    kubectl cnpg psql --replica $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    SELECT pg_is_in_recovery();

    Beispielausgabe

    pg_is_in_recovery
-------------------
t
(1 row)

    SELECT COUNT(*) FROM datasample;

    Beispielausgabe

    count
-------
  3
(1 row)

Einrichten von bedarfsgesteuerten und geplanten PostgreSQL-Backups mit Barman

Hinweis

Es wird erwartet, dass CloudNativePG die native Barman Cloud-Unterstützung zugunsten des Barman Cloud Plugins in der bevorstehenden Version 1.29 einstellen wird. Die Schritte in diesem Leitfaden funktionieren noch heute, aber planen Sie, nach der Stabilisierung zum Plug-In zu migrieren.

  1. Überprüfen Sie mit dem folgenden Befehl, ob der PostgreSQL-Cluster auf das in den CNPG-Cluster-CRD angegebene Azure-Speicherkonto zugreifen kann und ob Working WAL archiving als OK berichtet:

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Beispielausgabe

    Continuous Backup status
First Point of Recoverability:  Not Available
Working WAL archiving:          OK
WALs waiting to be archived:    0
Last Archived WAL:              00000001000000000000000A   @   2024-07-09T17:18:13.982859Z
Last Failed WAL:                -

  2. Stellen Sie ein On-Demand-Backup auf Azure Storage bereit, das die AKS Workloadidentitätsintegration verwendet, indem Sie die YAML-Datei mit dem Befehl kubectl apply verwenden.

    export BACKUP_ONDEMAND_NAME="on-demand-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: $BACKUP_ONDEMAND_NAME
spec:
  method: barmanObjectStore
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

  3. Überprüfen Sie den Status der bedarfsgesteuerten Sicherung mit dem Befehl kubectl describe.

    kubectl describe backup $BACKUP_ONDEMAND_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Beispielausgabe

    Type    Reason     Age   From                   Message
 ----    ------     ----  ----                   -------
Normal  Starting   6s    cloudnative-pg-backup  Starting backup for cluster pg-primary-cnpg-r8c7unrw
Normal  Starting   5s    instance-manager       Backup started
Normal  Completed  1s    instance-manager       Backup completed

  4. Überprüfen Sie mit dem folgenden Befehl, ob der Cluster einen ersten Wiederherstellungspunkt hat:

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

    Beispielausgabe

    Continuous Backup status
First Point of Recoverability:  2024-06-05T13:47:18Z
Working WAL archiving:          OK

  5. Konfigurieren Sie ein geplantes Backup für jede Stunde um 15 Minuten nach der vollen Stunde, indem Sie die YAML-Datei mit dem kubectl apply-Befehl.

    export BACKUP_SCHEDULED_NAME="scheduled-backup-1"

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: $BACKUP_SCHEDULED_NAME
spec:
  # Backup once per hour
  schedule: "0 15 * ? * *"
  backupOwnerReference: self
  cluster:
    name: $PG_PRIMARY_CLUSTER_NAME
EOF

  6. Überprüfen Sie den Status der geplanten Sicherung mithilfe des kubectl describe-Befehls.

    kubectl describe scheduledbackup $BACKUP_SCHEDULED_NAME \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

  7. Zeigen Sie die Sicherungsdateien an, die im Azure Blob Storage für den primären Cluster gespeichert sind, mithilfe des az storage blob list-Befehls.

    az storage blob list \
    --account-name $PG_PRIMARY_STORAGE_ACCOUNT_NAME \
    --container-name backups \
    --query "[*].name" \
    --only-show-errors

    Ihre Ausgabe sollte der folgenden Beispielausgabe entsprechen, die bestätigt, dass die Sicherung erfolgreich war:

    [
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/backup.info",
  "pg-primary-cnpg-r8c7unrw/base/20240605T134715/data.tar",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000001",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000002",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000003.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000004",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000005.00000028.backup",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000006",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000007",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000008",
  "pg-primary-cnpg-r8c7unrw/wals/0000000100000000/000000010000000000000009"
]

Wiederherstellen der bedarfsgesteuerten Sicherung in einem neuen PostgreSQL-Cluster

In diesem Abschnitt stellen Sie die zuvor erstellte bedarfsgesteuerte Sicherung mithilfe des CNPG-Operators in einer neuen Instanz mithilfe der Bootstrap-Cluster-CRD wieder her. Der Einfachheit halber wird ein einzelner Instanzcluster verwendet. Denken Sie daran, dass die AKS-Workloadidentität (über CNPG inheritFromAzureAD) auf die Sicherungsdateien zugreift und dass der Name des Wiederherstellungsclusters verwendet wird, um ein neues Kubernetes-Dienstkonto zu generieren, das für den Wiederherstellungscluster spezifisch ist.

Außerdem erstellen Sie einen zweiten Satz Partneranmeldeinformationen, um das neue Wiederherstellungsclusterdienstkonto dem vorhandenen UAMI zuzuordnen, das Zugriff auf die Sicherungsdateien im BLOB-Speicher hat.

  1. Erstellen Sie mithilfe des Befehls az identity federated-credential create einen zweiten Satz Anmeldeinformationen für die Partneridentität.

    export PG_PRIMARY_CLUSTER_NAME_RECOVERED="$PG_PRIMARY_CLUSTER_NAME-recovered-db"

az identity federated-credential create \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --issuer "${AKS_PRIMARY_CLUSTER_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${PG_NAMESPACE}":"${PG_PRIMARY_CLUSTER_NAME_RECOVERED}" \
    --audience api://AzureADTokenExchange

  2. Stellen Sie die bedarfsgesteuerte Sicherung mithilfe der Cluster-CRD mit dem kubectl apply-Befehl wieder her.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME_RECOVERED
spec:

  inheritedMetadata:
    annotations:
      service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
    labels:
      azure.workload.identity/use: "true"

  instances: 1

  affinity:
    nodeSelector:
      workload: postgres

  # Point to cluster backup created earlier and stored on Azure Blob Storage
  bootstrap:
    recovery:
      source: clusterBackup

  storage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

  walStorage:
    size: 2Gi
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 2Gi
      storageClassName: managed-csi-premium
      volumeMode: Filesystem

  serviceAccountTemplate:
    metadata:
      annotations:
        azure.workload.identity/client-id: "$AKS_UAMI_WORKLOAD_CLIENTID"
      labels:
        azure.workload.identity/use: "true"

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups
        serverName: $PG_PRIMARY_CLUSTER_NAME
        azureCredentials:
          inheritFromAzureAD: true
        wal:
          maxParallel: 8
EOF

  3. Stellen Sie eine Verbindung zur wiederhergestellten Instanz her und überprüfen Sie mit dem folgenden Befehl, ob das Dataset, das auf dem ursprünglichen Cluster erstellt wurde, in dem die Vollsicherung durchgeführt wurde, vorhanden ist:

    kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME_RECOVERED --namespace $PG_NAMESPACE

    SELECT COUNT(*) FROM datasample;

    Beispielausgabe

     count
-------
     3
(1 row)

Type \q to exit psql

  4. Löschen Sie den wiederhergestellten Cluster mithilfe des folgenden Befehls:

    kubectl cnpg destroy $PG_PRIMARY_CLUSTER_NAME_RECOVERED 1 \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

  5. Löschen Sie mithilfe des Befehls az identity federated-credential delete die Anmeldeinformationen für die Partneridentität.

    az identity federated-credential delete \
    --name $PG_PRIMARY_CLUSTER_NAME_RECOVERED \
    --identity-name $AKS_UAMI_CLUSTER_IDENTITY_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --yes

Den PostgreSQL-Cluster über einen öffentlichen Lastenausgleich zugänglich machen

In diesem Abschnitt konfigurieren Sie die nötige Infrastruktur, um die PostgreSQL-Endpunkte für Lese- und Schreibzugriff mit IP-Quellenbeschränkungen für die öffentliche IP-Adresse Ihrer Clientworkstation freizugeben.

Sie rufen auch die folgenden Endpunkte vom Cluster-IP-Dienst ab:

  • Ein primärer Lese-/Schreibzugriffsendpunkt, der auf *-rw endet.
  • Null bis N (abhängig von der Anzahl der Replikate) schreibgeschützte Endpunkte, die auf *-ro enden.
  • Ein Replikationsendpunkt, der auf *-r endet.

  1. Rufen Sie die Cluster-IP-Dienstdetails mithilfe des kubectl get-Befehls ab.

    kubectl get services \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME

    Beispielausgabe

    NAME                          TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
pg-primary-cnpg-sryti1qf-r    ClusterIP   10.0.193.27    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-ro   ClusterIP   10.0.237.19    <none>        5432/TCP   3h57m
pg-primary-cnpg-sryti1qf-rw   ClusterIP   10.0.244.125   <none>        5432/TCP   3h57m

    Hinweis

    Es gibt drei Dienste: namespace/cluster-name-ro ist dem Anschluss 5433 zugeordnet, namespace/cluster-name-rw, und namespace/cluster-name-r dem Anschluss 5433. Es ist wichtig, denselben Port wie den Lese-/Schreibknoten des PostgreSQL-Datenbankclusters zu vermeiden. Wenn Sie möchten, dass Anwendungen nur auf das schreibgeschützte Replikat des PostgreSQL-Datenbankclusters zugreifen, leiten Sie sie zu Port 5433. Der letzte Dienst wird normalerweise für Datensicherungen verwendet, kann aber auch als reiner Leseknoten fungieren.

  2. Rufen Sie die Dienstdetails mithilfe des Befehls kubectl get ab.

    export PG_PRIMARY_CLUSTER_RW_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-rw")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RW_SERVICE

export PG_PRIMARY_CLUSTER_RO_SERVICE=$(kubectl get services \
    --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    -l "cnpg.io/cluster" \
    --output json | jq -r '.items[] | select(.metadata.name | endswith("-ro")) | .metadata.name')

echo $PG_PRIMARY_CLUSTER_RO_SERVICE

  3. Konfigurieren Sie den Lastenausgleichsdienst mit den folgenden YAML-Dateien mithilfe des kubectl apply-Befehls.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-rw
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: primary
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -f -
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-resource-group: $AKS_PRIMARY_CLUSTER_NODERG_NAME
    service.beta.kubernetes.io/azure-pip-name: $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME
    service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
  name: cnpg-cluster-load-balancer-ro
  namespace: "${PG_NAMESPACE}"
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 5433
    targetPort: 5432
  selector:
    cnpg.io/instanceRole: replica
    cnpg.io/podRole: instance
  loadBalancerSourceRanges:
  - "$MY_PUBLIC_CLIENT_IP/32"
EOF

  4. Rufen Sie die Dienstdetails mithilfe des Befehls kubectl describe ab.

    kubectl describe service cnpg-cluster-load-balancer-rw \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

kubectl describe service cnpg-cluster-load-balancer-ro \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE

export AKS_PRIMARY_CLUSTER_ALB_DNSNAME="$(az network public-ip show \
    --resource-group $AKS_PRIMARY_CLUSTER_NODERG_NAME \
    --name $AKS_PRIMARY_CLUSTER_PUBLICIP_NAME \
    --query "dnsSettings.fqdn" --output tsv)"

echo $AKS_PRIMARY_CLUSTER_ALB_DNSNAME

Überprüfen öffentlicher PostgreSQL-Endpunkte

In diesem Abschnitt überprüfen Sie, ob der Azure Load Balancer ordnungsgemäß eingerichtet ist, indem Sie die zuvor erstellte statische IP-Adresse verwenden und Verbindungen zu den primären schreibgeschützten und schreibgeschützten Replikaten weiterleiten, und Sie verwenden die Befehlszeilenschnittstelle PSQL, um sich mit beiden zu verbinden.

Denken Sie daran, dass der primäre Schreib-/Leseendpunkt dem TCP-Port 5432 und die schreibgeschützten Replikationsendpunkte dem Port 5433 zugeordnet sind, damit der gleiche PostgreSQL-DNS-Name für Leser und Schreiber verwendet werden kann.

Hinweis

Sie benötigen den Wert des Kennworts der benutzenden Person für PostgreSQL „basic auth“, das zuvor generiert und in der Umgebungsvariablen $PG_DATABASE_APPUSER_SECRET gespeichert wurde.

  • Überprüfen Sie die öffentlichen PostgreSQL-Endpunkte mithilfe der folgenden psql-Befehle:

    echo "Public endpoint for PostgreSQL cluster: $AKS_PRIMARY_CLUSTER_ALB_DNSNAME"

# Query the primary, pg_is_in_recovery = false

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5432 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"

    Beispielausgabe

    pg_is_in_recovery
-------------------
 f
(1 row)

    echo "Query a replica, pg_is_in_recovery = true"

psql -h $AKS_PRIMARY_CLUSTER_ALB_DNSNAME \
    -p 5433 -U app -d appdb -W -c "SELECT pg_is_in_recovery();"

    Beispielausgabe

    # Example output

pg_is_in_recovery
-------------------
t
(1 row)

    Bei erfolgreicher Verbindung mit dem primären Schreib-/Leseendpunkt gibt die PostgreSQL-Funktion f für FALSE zurück, was anzeigt, dass die aktuelle Verbindung beschreibbar ist.

    Wenn eine Verbindung zu einem Replikat besteht, gibt die Funktion tTRUE zurück und zeigt damit an, dass die Datenbank wiederhergestellt und schreibgeschützt ist.

Simulieren eines ungeplanten Failovers

In diesem Abschnitt lösen Sie einen plötzlichen Ausfall aus, indem Sie den Pod, auf dem der primäre Server läuft, löschen. Dies simuliert einen plötzlichen Absturz oder den Verlust der Netzwerkverbindung zu dem Knoten, auf dem der primäre PostgreSQL-Server läuft.

  1. Überprüfen Sie den Status der laufenden Podinstanzen mit dem folgenden Befehl:

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Beispielausgabe

    Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

  2. Löschen Sie den primären Pod mithilfe des kubectl delete-Befehls.

    PRIMARY_POD=$(kubectl get pod \
    --namespace $PG_NAMESPACE \
    --no-headers \
    -o custom-columns=":metadata.name" \
    -l role=primary)

kubectl delete pod $PRIMARY_POD --grace-period=1 --namespace $PG_NAMESPACE

  3. Überprüfen Sie, ob die Podinstanz pg-primary-cnpg-sryti1qf-2 jetzt der primäre Befehl ist, indem Sie den folgenden Befehl verwenden:

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Beispielausgabe

    pg-primary-cnpg-sryti1qf-2  0/9000060   Primary         OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-1  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

  4. Setzen Sie die Podinstanz pg-primary-cnpg-sryti1qf-1 als primäre Instanz mithilfe des folgenden Befehls zurück:

    kubectl cnpg promote $PG_PRIMARY_CLUSTER_NAME 1 --namespace $PG_NAMESPACE

  5. Überprüfen Sie mit folgendem Befehl, ob die Podinstanzen in ihren ursprünglichen Zustand vor dem ungeplanten Failovertest zurückgekehrt sind:

    kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

    Beispielausgabe

    Name                        Current LSN Rep role        Status  Node
--------------------------- ----------- --------        ------- -----------
pg-primary-cnpg-sryti1qf-1  0/9000060   Primary         OK      aks-postgres-32388626-vmss000000
pg-primary-cnpg-sryti1qf-2  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000001
pg-primary-cnpg-sryti1qf-3  0/9000060   Standby (sync)  OK      aks-postgres-32388626-vmss000002

Bereinigen von Ressourcen

  • Nachdem Sie die Überprüfung Der Bereitstellung abgeschlossen haben, löschen Sie alle Ressourcen, die Sie in dieser Anleitung erstellt haben, mithilfe des az group delete-Befehls.

    az group delete --resource-group $RESOURCE_GROUP_NAME --no-wait --yes

Nächste Schritte

In dieser Schrittanleitung wurde Folgendes vermittelt:

  • Verwenden Sie Azure CLI zum Erstellen eines AKS-Clusters mit mehreren Zonen.
  • Bereitstellen eines hochverfügbaren PostgreSQL-Clusters und einer Datenbank mithilfe des CNPG-Operators.
  • Richten Sie die Überwachung für PostgreSQL mithilfe von Prometheus und Grafana ein.
  • Stellen Sie einen Beispieldataset für die PostgreSQL-Datenbank bereit.
  • Simulieren Sie eine Clusterunterbrechung und einen PostgreSQL-Replikatfailover.
  • Führen Sie eine Sicherung und Wiederherstellung der PostgreSQL-Datenbank durch.

Weitere Informationen dazu, wie Sie AKS für Ihre Workloads verwenden können, finden Sie unter Was ist Azure Kubernetes Service (AKS)? Weitere Informationen zur Azure-Datenbank für PostgreSQL finden Sie unter Was ist Azure Database for PostgreSQL?

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Ken Kilty | Leitender TPM
  • Russell de Pina | Leiter TPM
  • Adrian Joian | Senior Customer Engineer
  • Jennifer Hayes | Senior Content Developer
  • Carol Smith | Senior Content Developer
  • Erin Schaffer | Inhaltsentwickler 2
  • Adam Sharif | Kundeningenieur 2

Anerkennung

Diese Dokumentation wurde gemeinsam mit EnterpriseDB, den Betreuern des CloudNativePG-Operators, entwickelt. Wir danken Gabriele Bartolini für die Überprüfung früherer Entwürfe dieses Dokuments und für das Anbieten technischer Verbesserungen.

  • Last updated on