Weryfikowanie i testowanie wdrożenia bazy danych PostgreSQL w usłudze Azure Kubernetes Service (AKS)

W tym artykule wykonasz różne kroki testowania i walidacji bazy danych PostgreSQL wdrożonej w usłudze AKS. Obejmuje to weryfikowanie wdrożenia, nawiązywanie połączenia z bazą danych i testowanie scenariuszy trybu failover.

Jeśli jeszcze nie wdrożono bazy danych PostgreSQL, wykonaj kroki opisane w artykule Wdrażanie bazy danych PostgreSQL o wysokiej dostępności w usłudze AKS przy użyciu interfejsu wiersza polecenia platformy Azure , aby się skonfigurować, a następnie możesz wrócić do tego artykułu.

Ważne

Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Oprogramowanie, które wdrażasz, jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji i wsparcia technicznego Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.

Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje pełną odpowiedzialność za proces kompilacji, skanowania, podpisywania, weryfikacji oraz wdrażania poprawek, a także kontrolę nad plikami binarnymi w obrazach kontenerów. Aby uzyskać więcej informacji, zobacz Zarządzanie lukami w zabezpieczeniach dla usług AKS i zakres wsparcia technicznego dla AKS.

Sprawdzanie wdrożonego klastra PostgreSQL

Sprawdź, czy PostgreSQL jest rozłożony na wiele stref dostępności, uzyskując szczegóły dotyczące węzłów AKS za pomocą polecenia kubectl get.

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

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe ze strefą dostępności wyświetlaną dla każdego węzła:

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

Nawiązywanie połączenia z bazą danych PostgreSQL i tworzenie przykładowego zestawu danych

W tej sekcji utworzysz tabelę i wstawisz dane do bazy danych aplikacji, która została utworzona w CNPG Cluster CRD, który wdrożyłeś wcześniej. Te dane służą do weryfikowania operacji tworzenia kopii zapasowych i przywracania dla klastra PostgreSQL.

Utwórz tabelę i wstaw dane do bazy danych aplikacji przy użyciu następujących poleceń:

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;

Wpisz polecenie \q , aby zakończyć działanie narzędzia psql po zakończeniu.

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

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

Połącz z replikami PostgreSQL w trybie tylko do odczytu

Połącz się z replikami tylko do odczytu bazy danych PostgreSQL i zweryfikuj przykładowy zestaw danych przy użyciu następujących poleceń:

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

SELECT pg_is_in_recovery();

Przykładowe dane wyjściowe

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

SELECT COUNT(*) FROM datasample;

Przykładowe dane wyjściowe

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

Konfigurowanie kopii zapasowych na żądanie i zaplanowanych kopii zapasowych PostgreSQL przy użyciu narzędzia Barman

Uwaga

Oczekuje się, że usługa CloudNativePG wycofa natywną obsługę platformy Barman Cloud na rzecz wtyczki Barman Cloud w nadchodzącej wersji 1.29. Kroki opisane w tym przewodniku nadal działają dzisiaj, ale zaplanuj migrację do wtyczki po ustabilizowaniu.

Sprawdź, czy klaster PostgreSQL może uzyskać dostęp do konta usługi Azure Storage określonego w CRLD klastra CNPG i że Working WAL archiving raportuje jako OK przy użyciu następującego polecenia:

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

Przykładowe dane wyjściowe

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

Wdrożenie kopii zapasowej na żądanie do usługi Azure Storage, wykorzystującej integrację tożsamości obciążenia usługi AKS, za pomocą pliku YAML z poleceniem kubectl apply.

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

Zweryfikuj stan kopii zapasowej na żądanie przy użyciu kubectl describe polecenia .

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

Przykładowe dane wyjściowe

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

Sprawdź, czy klaster ma pierwszy punkt możliwości odzyskiwania, używając następującego polecenia:

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

Przykładowe dane wyjściowe

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

Skonfiguruj zaplanowaną kopię zapasową co godzinę 15 minut po godzinie przy użyciu pliku YAML za pomocą polecenia .

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

Zweryfikuj stan zaplanowanej kopii zapasowej przy użyciu kubectl describe polecenia .

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

Wyświetl pliki kopii zapasowej dla klastra podstawowego, przechowywane w magazynie obiektów blob platformy Azure, przy użyciu polecenia az storage blob list.

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

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe, sprawdzanie poprawności kopii zapasowej zakończyło się pomyślnie:

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

Przywracanie kopii zapasowej na żądanie do nowego klastra PostgreSQL

W tej sekcji przywrócisz utworzoną wcześniej kopię zapasową na żądanie przy użyciu operatora CNPG do nowej instancji za pomocą bootstrap Cluster CRD. Jeden klaster wystąpień jest używany dla uproszczenia. Należy pamiętać, że tożsamość obciążenia usługi AKS (za pośrednictwem cnPG inheritFromAzureAD) uzyskuje dostęp do plików kopii zapasowych i że nazwa klastra odzyskiwania jest używana do generowania nowego konta usługi Kubernetes specyficznego dla klastra odzyskiwania.

Utworzysz również drugie poświadczenie federacyjne, aby zamapować nowe konto usługi klastra odzyskiwania na istniejące UAMI z dostępem "Współautor danych obiektu blob usługi Storage" do plików kopii zapasowych w magazynie obiektów blob.

Utwórz drugie poświadczenie tożsamości federacyjnej, używając polecenia az identity federated-credential create.

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

Przywróć kopię zapasową na żądanie przy użyciu CRD klastra za pomocą polecenia kubectl apply.

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

Połącz się z odzyskanym wystąpieniem, a następnie sprawdź, czy zestaw danych utworzony w oryginalnym klastrze, w którym wykonano pełną kopię zapasową, jest obecny przy użyciu następującego polecenia:
```
kubectl cnpg psql $PG_PRIMARY_CLUSTER_NAME_RECOVERED --namespace $PG_NAMESPACE
```
```
SELECT COUNT(*) FROM datasample;
```
Przykładowe dane wyjściowe
```
 count
-------
     3
(1 row)

Type \q to exit psql
```

Usuń odzyskany klaster przy użyciu następującego polecenia:

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

Usuń poświadczenia tożsamości federacyjnej za pomocą polecenia az identity federated-credential delete.

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

Uwidacznianie klastra PostgreSQL przy użyciu publicznego modułu równoważenia obciążenia

W tej sekcji skonfigurujesz niezbędną infrastrukturę do publicznego uwidocznienia punktów końcowych PostgreSQL do odczytu i zapisu oraz tylko do odczytu, z ograniczeniami źródła adresów IP do publicznego adresu IP stacji roboczej klienta.

Również pobierasz następujące punkty końcowe z usługi IP klastra.

Jeden podstawowy punkt końcowy odczytu i zapisu kończący się ciągiem *-rw.
Zero do N (w zależności od liczby replik) punktów końcowych tylko z odczytem, które kończą się na *-ro.
Jeden punkt końcowy replikacji kończący się ciągiem *-r.

Uzyskaj szczegóły usługi IP klastra za pomocą polecenia kubectl get.
```
kubectl get services \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    --namespace $PG_NAMESPACE \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME
```
Przykładowe dane wyjściowe
```
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
```
Uwaga

Istnieją trzy usługi: namespace/cluster-name-ro zamapowane na port 5433, namespace/cluster-name-rwi namespace/cluster-name-r zamapowane na port 5433. Należy unikać używania tego samego portu co węzeł odczytu/zapisu klastra bazy danych PostgreSQL. Jeśli chcesz, aby aplikacje uzyskiwały dostęp tylko do repliki bazy danych PostgreSQL w trybie tylko do odczytu, skieruj je do portu 5433. Ostateczna usługa jest zwykle używana do tworzenia kopii zapasowych danych, ale może również działać jako węzeł tylko do odczytu.

Pobierz szczegóły usługi przy użyciu kubectl get polecenia .

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

Skonfiguruj usługę modułu równoważenia obciążenia przy użyciu następujących plików YAML przy użyciu kubectl apply polecenia .

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

Pobierz szczegóły usługi przy użyciu kubectl describe polecenia .

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

Weryfikowanie publicznych punktów końcowych PostgreSQL

W tej sekcji sprawdzisz, czy usługa Azure Load Balancer jest prawidłowo skonfigurowana przy użyciu statycznego adresu IP utworzonego wcześniej, rozsyłając połączenia do podstawowych replik do odczytu i zapisu oraz replik tylko do odczytu, a także użyjesz interfejsu wiersza polecenia psql do nawiązywania połączenia z obiema replikami.

Należy pamiętać, że podstawowy punkt końcowy do odczytu i zapisu mapuje się na port TCP 5432, a punkty końcowe repliki dostępne tylko do odczytu mapują się na port 5433, aby umożliwić użycie tej samej nazwy DNS PostgreSQL dla odczytu i zapisu.

Uwaga

Potrzebna jest wartość hasła użytkownika aplikacji dla podstawowego uwierzytelniania postgreSQL wygenerowanego wcześniej i przechowywanego w zmiennej środowiskowej $PG_DATABASE_APPUSER_SECRET .

Zweryfikuj publiczne punkty końcowe PostgreSQL przy użyciu następujących psql poleceń:

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

Przykładowe dane wyjściowe

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

Przykładowe dane wyjściowe

# Example output

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

Po pomyślnym nawiązaniu połączenia z podstawowym punktem końcowym odczytu i zapisu funkcja PostgreSQL zwraca fwartość false, co oznacza, że bieżące połączenie jest możliwe do zapisu.

Po nawiązaniu połączenia z repliką funkcja zwraca ttrue, co wskazuje, że baza danych jest w odzyskiwaniu i tylko do odczytu.

Zasymuluj nieplanowane przełączenie awaryjne

W tej sekcji wywołujesz nagłą awarię, usuwając zasobnik uruchamiający podstawowy węzeł, co symuluje nagły krach lub utratę łączności sieciowej z węzłem hostującym podstawowy węzeł PostgreSQL.

Sprawdź stan działających instancji podów przy użyciu następującego polecenia:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Przykładowe dane wyjściowe

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

Usuń główny pod za pomocą polecenia kubectl delete.

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

Sprawdź, czy instancja pg-primary-cnpg-sryti1qf-2 poda jest teraz główną, używając następującego polecenia:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Przykładowe dane wyjściowe

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

Zresetuj instancję pod pg-primary-cnpg-sryti1qf-1 jako główną przy użyciu następującego polecenia:
```
kubectl cnpg promote $PG_PRIMARY_CLUSTER_NAME 1 --namespace $PG_NAMESPACE
```

Sprawdź, czy wystąpienia zasobników zostały zwrócone do stanu pierwotnego przed nieplanowanym testem trybu failover przy użyciu następującego polecenia:

kubectl cnpg status $PG_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE

Przykładowe dane wyjściowe

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

Czyszczenie zasobów

Po zakończeniu przeglądania wdrożenia usuń wszystkie zasoby utworzone w tym przewodniku przy użyciu polecenia az group delete.
```
az group delete --resource-group $RESOURCE_GROUP_NAME --no-wait --yes
```

Następne kroki

W tym przewodniku z instrukcjami przedstawiono następujące zagadnienia:

Użyj interfejsu wiersza polecenia platformy Azure, aby utworzyć klaster usługi AKS z wieloma strefami.
Wdróż klaster i bazę danych PostgreSQL o wysokiej dostępności przy użyciu operatora CNPG.
Konfigurowanie monitorowania bazy danych PostgreSQL przy użyciu rozwiązań Prometheus i Grafana.
Wdróż przykładowy zestaw danych w bazie danych PostgreSQL.
Symulacja przerwania klastra i przełączenia awaryjnego repliki PostgreSQL.
Wykonaj kopię zapasową i przywracanie bazy danych PostgreSQL.

Aby dowiedzieć się więcej na temat korzystania z usługi AKS dla obciążeń, zobacz Co to jest usługa Azure Kubernetes Service (AKS)? Aby dowiedzieć się więcej o usłudze Azure Database for PostgreSQL, zobacz Co to jest usługa Azure Database for PostgreSQL?

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:

Ken Kilty | Główny TPM
Russell de Pina | Główny Menedżer Programu Technicznego (TPM)
Adrian Joian | Starszy inżynier klienta
Jenny Hayes | Starszy deweloper zawartości
Carol Smith | Starszy deweloper zawartości
Erin Schaffer | Content Developer 2
Adam Sharif | Inżynier klienta 2

Potwierdzenie

Ta dokumentacja została opracowana wspólnie z bazą danych EnterpriseDB, opiekunami operatora CloudNativePG. Dziękujemy Gabriele Bartolini za przejrzenie wcześniejszych wersji tego dokumentu i oferowanie ulepszeń technicznych.

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-11-09

Udostępnij przez

Weryfikowanie i testowanie wdrożenia bazy danych PostgreSQL w usłudze Azure Kubernetes Service (AKS)

Sprawdzanie wdrożonego klastra PostgreSQL

Nawiązywanie połączenia z bazą danych PostgreSQL i tworzenie przykładowego zestawu danych

Połącz z replikami PostgreSQL w trybie tylko do odczytu

Konfigurowanie kopii zapasowych na żądanie i zaplanowanych kopii zapasowych PostgreSQL przy użyciu narzędzia Barman

Przywracanie kopii zapasowej na żądanie do nowego klastra PostgreSQL

Uwidacznianie klastra PostgreSQL przy użyciu publicznego modułu równoważenia obciążenia

Weryfikowanie publicznych punktów końcowych PostgreSQL

Zasymuluj nieplanowane przełączenie awaryjne

Czyszczenie zasobów

Następne kroki

Współautorzy

Potwierdzenie

Sprzężenie zwrotne

Dodatkowe źródła