Een PostgreSQL-database-implementatie valideren en testen in Azure Kubernetes Service (AKS)

In dit artikel voert u verschillende test- en validatiestappen uit op een PostgreSQL-database die is geïmplementeerd op AKS. Dit omvat het verifiëren van de implementatie, het maken van verbinding met de database en het testen van failoverscenario's.

Als u PostgreSQL nog niet hebt geïmplementeerd, volgt u de stappen in Een maximaal beschikbare PostgreSQL-database implementeren in AKS met Azure CLI om te worden ingesteld. Vervolgens kunt u terugkeren naar dit artikel.

Belangrijk

Opensource-software wordt vermeld in AKS-documentatie en -voorbeelden. Software die u implementeert, is uitgesloten van AKS-serviceovereenkomsten, beperkte garantie en ondersteuning voor Azure. Wanneer u opensource-technologie naast AKS gebruikt, raadpleegt u de beschikbare ondersteuningsopties van de respectieve community's en projectonderhouders om een plan te ontwikkelen.

Microsoft neemt de verantwoordelijkheid voor het bouwen van de opensource-pakketten die we implementeren op AKS. Deze verantwoordelijkheid omvat het volledige eigendom van het bouw-, scan-, onderteken-, validatie- en hotfixproces, samen met controle over de binaire bestanden in container images. Zie Beveiligingsbeheer voor AKS- en AKS-ondersteuningsdekking voor meer informatie.

Het geïmplementeerde PostgreSQL-cluster controleren

Controleer of PostgreSQL is verdeeld over meerdere beschikbaarheidszones door de details van het AKS-knooppunt op te halen met behulp van de kubectl get opdracht.

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"}'

Uw uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer met de beschikbaarheidszone die voor elk knooppunt wordt weergegeven:

{
    "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"
}

Verbinding maken met PostgreSQL en een voorbeeldgegevensset maken

In deze sectie maakt u een tabel en voegt u enkele gegevens in de app-database in die is gemaakt in de CNPG-cluster-CRD die u eerder hebt geïmplementeerd. U gebruikt deze gegevens om de back-up- en herstelbewerkingen voor het PostgreSQL-cluster te valideren.

Maak een tabel en voeg gegevens in de app-database in met behulp van de volgende opdrachten:

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;

Typ \q om psql af te sluiten wanneer u klaar bent.

De uitvoer zou moeten lijken op de volgende voorbeelduitvoer.

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

Verbinding maken met alleen-lezen replica's van PostgreSQL

Maak verbinding met de PostgreSQL read-only replica's en valideer de voorbeeldset gegevens met behulp van de volgende opdrachten:

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

SELECT pg_is_in_recovery();

Voorbeelduitvoer

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

SELECT COUNT(*) FROM datasample;

Voorbeelduitvoer

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

PostgreSQL-back-ups op aanvraag en volgens schema instellen met behulp van Barman

Notitie

CloudNativePG zal naar verwachting de ondersteuning voor de eigen Barman Cloud afschaffen ten gunste van de Barman Cloud-invoegtoepassing in de komende release 1.29. De stappen in deze handleiding blijven vandaag werken, maar zijn van plan om naar de invoegtoepassing te migreren zodra deze is gestabiliseerd.

Controleer of het PostgreSQL-cluster toegang heeft tot het Azure-opslagaccount dat is opgegeven in het CNPG-cluster CRD en dat Working WAL archiving rapporteert met OK behulp van de volgende opdracht:

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

Voorbeelduitvoer

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:                -

Implementeer een back-up op aanvraag in Azure Storage, die gebruikmaakt van de integratie van de AKS-workloadidentiteit met behulp van het YAML-bestand met de kubectl apply opdracht.

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

Valideer de status van de back-up op aanvraag met behulp van de kubectl describe opdracht.

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

Voorbeelduitvoer

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

Controleer of het cluster een eerste herstelpunt heeft met behulp van de volgende opdracht:

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

Voorbeelduitvoer

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

Configureer een geplande back-up voor elk uur om 15 minuten na het uur met behulp van het YAML-bestand met de kubectl apply opdracht.

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

Valideer de status van de geplande back-up met behulp van de kubectl describe opdracht.

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

Bekijk de back-upbestanden die zijn opgeslagen in Azure Blob Storage voor het primaire cluster met behulp van de az storage blob list opdracht.

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

De uitvoer moet lijken op de volgende voorbeelduitvoer, ter bevestiging dat de back-up succesvol was.

[
  "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"
]

De back-up op aanvraag herstellen naar een nieuw PostgreSQL-cluster

In deze sectie herstelt u de back-up op aanvraag die u eerder hebt gemaakt met behulp van de CNPG-operator in een nieuw exemplaar met behulp van de bootstrapcluster-CRD. Een cluster met een enkele server wordt gebruikt vanwege de eenvoud. Houd er rekening mee dat de AKS-workloadidentiteit (via CNPG inheritFromAzureAD) toegang heeft tot de back-upbestanden en dat de naam van het herstelcluster wordt gebruikt om een nieuw Kubernetes-serviceaccount te genereren dat specifiek is voor het herstelcluster.

U maakt ook een tweede federatief referentiepunt om het nieuwe herstelcluster-serviceaccount toe te wijzen aan de bestaande UAMI met 'Opslag-Blob Data Bijdrager'-toegang tot de back-upbestanden in blobopslag.

Maak een tweede federatieve identiteitsreferentie met behulp van de az identity federated-credential create opdracht.

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

Herstel de back-up op aanvraag met behulp van cluster CRD met de kubectl apply opdracht.

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

Maak verbinding met het herstelde exemplaar en valideer vervolgens of de gegevensset die is gemaakt op het oorspronkelijke cluster waarop de volledige back-up is gemaakt aanwezig is met behulp van de volgende opdracht:
```
kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME_RECOVERED --namespace $PG_NAMESPACE
```
```
SELECT COUNT(*) FROM datasample;
```
Voorbeelduitvoer
```
 count
-------
     3
(1 row)

Type \q to exit psql
```

Verwijder het herstelde cluster met behulp van de volgende opdracht:

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

Verwijder de federatieve identiteitsreferentie met behulp van de az identity federated-credential delete opdracht.

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

Het PostgreSQL-cluster beschikbaar maken met behulp van een openbare load balancer

In deze sectie configureert u de benodigde infrastructuur om de PostgreSQL-eindpunten voor lezen/schrijven en alleen-lezen beschikbaar te maken met IP-bronbeperkingen voor het openbare IP-adres van uw clientwerkstation.

U haalt ook de volgende eindpunten op uit de CLUSTER-IP-service:

Eén primair eindpunt voor lezen/schrijven dat eindigt op *-rw.
Nul tot N (afhankelijk van het aantal replica's) alleen-lezen eindpunten die eindigen op *-ro.
Eén replicatie-eindpunt dat eindigt op *-r.

Haal de details van de Cluster IP-service op met behulp van de kubectl get opdracht.
```
kubectl get services \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME
```
Voorbeelduitvoer
```
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
```
Notitie

Er zijn drie services: namespace/cluster-name-ro toegewezen aan poort 5433 en namespace/cluster-name-rwnamespace/cluster-name-r toegewezen aan poort 5433. Het is belangrijk om te voorkomen dat u dezelfde poort gebruikt als het lees-/schrijfknooppunt van het PostgreSQL-databasecluster. Als u wilt dat toepassingen alleen toegang hebben tot de alleen-lezen replica van het PostgreSQL-databasecluster, stuurt u deze naar poort 5433. De laatste service wordt doorgaans gebruikt voor gegevensback-ups, maar kan ook fungeren als een alleen-lezen knooppunt.

Haal de servicedetails op met behulp van de kubectl get opdracht.

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

Configureer de load balancer-service met de volgende YAML-bestanden met behulp van de kubectl apply opdracht.

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

Haal de servicedetails op met behulp van de kubectl describe opdracht.

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

Openbare PostgreSQL-eindpunten valideren

In deze sectie controleert u of de Azure Load Balancer correct is ingesteld met behulp van het statische IP-adres dat u eerder hebt gemaakt en verbindingen omleidt naar de primaire lees-schrijf- en alleen-lezen-replica's en gebruikt u de psql CLI om verbinding te maken met beide.

Houd er rekening mee dat het primaire eindpunt voor lezen/schrijven is toegewezen aan TCP-poort 5432 en de alleen-lezen replica-eindpunten worden toegewezen aan poort 5433, zodat dezelfde PostgreSQL DNS-naam kan worden gebruikt voor lezers en schrijvers.

Notitie

U hebt de waarde nodig van het app-gebruikerswachtwoord voor postgreSQL-basisverificatie die eerder is gegenereerd en die is opgeslagen in de $PG_DATABASE_APPUSER_SECRET omgevingsvariabele.

Valideer de openbare PostgreSQL-eindpunten met behulp van de volgende psql opdrachten:

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();"

Voorbeelduitvoer

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();"

Voorbeelduitvoer

# Example output

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

Wanneer de PostgreSQL-functie succesvol is verbonden met het primaire eindpunt voor lezen/schrijven, retourneert deze f als false, waarmee wordt aangegeven dat de huidige verbinding beschrijfbaar is.

Wanneer u verbonden bent met een replica, retourneert de functie t voor waar, waarmee wordt aangegeven dat de database zich in herstel bevindt en alleen-lezen is.

Een niet-geplande failover simuleren

In deze sectie activeert u een plotselinge fout door de pod te verwijderen die de primaire database draait, waarmee u een plotselinge crash of verlies van netwerkconnectiviteit simuleert naar het knooppunt dat als host fungeert voor de PostgreSQL-hoofdnode.

Controleer de status van de actieve pod-exemplaren met behulp van de volgende opdracht:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Voorbeelduitvoer

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

Verwijder de primaire pod met behulp van de kubectl delete opdracht.

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

Controleer of het pg-primary-cnpg-sryti1qf-2 pod-exemplaar nu de primaire is met behulp van de volgende opdracht:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Voorbeelduitvoer

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

Stel het pg-primary-cnpg-sryti1qf-1 pod-exemplaar opnieuw in als de primaire instantie met behulp van de volgende opdracht:
```
kubectl cnpg promote $PG_PRIMARY_CLUSTER_NAME 1 --namespace $PG_NAMESPACE
```

Controleer of de pod-exemplaren zijn teruggekomen naar de oorspronkelijke status vóór de ongeplande failovertest met behulp van de volgende opdracht:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Voorbeelduitvoer

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

Hulpmiddelen opruimen

Wanneer u klaar bent met het controleren van uw implementatie, verwijdert u alle resources die u in deze handleiding hebt gemaakt met behulp van de az group delete opdracht.
```
az group delete --resource-group $RESOURCE_GROUP_NAME --no-wait --yes
```

Volgende stappen

In deze handleiding hebt u geleerd hoe u het volgende kunt doen:

Gebruik Azure CLI om een AKS-cluster met meerdere zones te maken.
Implementeer een postgreSQL-cluster en -database met hoge beschikbaarheid met behulp van de CNPG-operator.
Bewaking voor PostgreSQL instellen met Prometheus en Grafana.
Implementeer een voorbeeldgegevensset in de PostgreSQL-database.
Simuleer een onderbreking van een cluster en een PostgreSQL-replicafailover.
Voer een back-up en herstel uit van de PostgreSQL-database.

Zie Wat is Azure Kubernetes Service (AKS)? Zie Wat is Azure Database for PostgreSQL? voor meer informatie over Azure Database for PostgreSQL.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

Ken Kilty | Hoofd TPM
Russell de Pina | Principal TPM
Adrian Joian | Senior klanttechnicus
Jenny Hayes | Senior Content Developer
Carol Smith | Senior Content Developer
Erin Schaffer | Inhoudsontwikkelaar 2
Adam Sharif | Klanttechnicus 2

Erkenning

Deze documentatie is gezamenlijk ontwikkeld met EnterpriseDB, de onderhouders van de CloudNativePG-operator. We danken Gabriele Bartolini voor het bekijken van eerdere concepten van dit document en het aanbieden van technische verbeteringen.

Feedback

Is deze pagina nuttig?

Last updated on 2025-11-09

Delen via

Een PostgreSQL-database-implementatie valideren en testen in Azure Kubernetes Service (AKS)

Het geïmplementeerde PostgreSQL-cluster controleren

Verbinding maken met PostgreSQL en een voorbeeldgegevensset maken

Verbinding maken met alleen-lezen replica's van PostgreSQL

PostgreSQL-back-ups op aanvraag en volgens schema instellen met behulp van Barman

De back-up op aanvraag herstellen naar een nieuw PostgreSQL-cluster

Het PostgreSQL-cluster beschikbaar maken met behulp van een openbare load balancer

Openbare PostgreSQL-eindpunten valideren

Een niet-geplande failover simuleren

Hulpmiddelen opruimen

Volgende stappen

Bijdragers

Erkenning

Feedback

Aanvullende resources