Udostępnij przez

Wdrażanie bazy danych PostgreSQL o wysokiej dostępności w usłudze Azure Kubernetes Service (AKS)

W tym artykule wdrożysz bazę danych PostgreSQL o wysokiej dostępności na platformie AKS.

Important

Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Wdrażane oprogramowanie jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji i wsparcia 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 posiadanie pełnej kontroli nad procesem kompilacji, skanowania, podpisywania, weryfikacji i szybkich poprawek, a także nad plikami binarnymi w obrazach kontenerów. Aby uzyskać więcej informacji, zapoznaj się z Zarządzanie lukami w zabezpieczeniach dla usług AKS i zakres pomocy technicznej usługi AKS.

Utwórz sekret dla użytkownika aplikacji bootstrap

  1. Wygeneruj sekret do zweryfikowania wdrożenia PostgreSQL przez interakcyjne logowanie dla użytkownika aplikacji bootstrap przy użyciu polecenia kubectl create secret.

Important

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Przepływ uwierzytelniania opisany w tej procedurze wymaga wysokiego stopnia zaufania w aplikacji i niesie ze sobą ryzyko, które nie występują w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy, takie jak tożsamości zarządzane, nie są opłacalne.

PG_DATABASE_APPUSER_SECRET=$(echo -n | openssl rand -base64 16)

kubectl create secret generic db-user-pass \
    --from-literal=username=app \
     --from-literal=password="${PG_DATABASE_APPUSER_SECRET}" \
     --namespace $PG_NAMESPACE \
     --context $AKS_PRIMARY_CLUSTER_NAME

  1. Sprawdź, czy tajny klucz został pomyślnie utworzony przy użyciu polecenia kubectl get.

    kubectl get secret db-user-pass --namespace $PG_NAMESPACE --context $AKS_PRIMARY_CLUSTER_NAME

Ustawianie zmiennych środowiskowych dla klastra PostgreSQL

  • Wdróż narzędzie ConfigMap, aby skonfigurować operator CNPG przy użyciu następującego kubectl apply polecenia. Te wartości zastępują starszy ENABLE_AZURE_PVC_UPDATES przełącznik, który nie jest już wymagany, i pomagają w stopniowych aktualizacjach oraz przyspieszeniu ponownego nawiązywania połączeń replik. Przed przejściem tej konfiguracji do środowiska produkcyjnego sprawdź, czy wszystkie istniejące DRAIN_TAINTS ustawienia, na których polegasz, pozostają zgodne ze środowiskiem platformy Azure.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -f -
apiVersion: v1
kind: ConfigMap
metadata:
    name: cnpg-controller-manager-config
data:
    CLUSTERS_ROLLOUT_DELAY: '120'
    STANDBY_TCP_USER_TIMEOUT: '10'
EOF

Zainstaluj Prometheus PodMonitors

Prometheus scrapuje CNPG przy użyciu reguł zapisywania przechowywanych w przykładowym repozytorium CNPG na GitHubie. Ponieważ zarządzany przez operatora zasób PodMonitor jest wycofywany z użycia, utwórz i zarządzaj zasobem PodMonitor samodzielnie, aby dostosować go do swojego stosu monitorowania.

  1. Dodaj repozytorium Helm społeczności Prometheus przy użyciu polecenia helm repo add.

    helm repo add prometheus-community \
    https://prometheus-community.github.io/helm-charts

  2. Uaktualnij repozytorium Helm społeczności Prometheus i zainstaluj je w głównym klastrze za pomocą polecenia helm upgrade oraz flagi --install.

    helm upgrade --install \
    --namespace $PG_NAMESPACE \
    -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/docs/src/samples/monitoring/kube-stack-config.yaml \
    prometheus-community \
    prometheus-community/kube-prometheus-stack \
    --kube-context=$AKS_PRIMARY_CLUSTER_NAME

  3. Utwórz podMonitor dla klastra. Zespół CNPG przestarza PodMonitor zarządzany przez operatora, więc teraz Ty nim zarządzasz bezpośrednio.

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME
  namespace: ${PG_NAMESPACE}
  labels:
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Utwórz poświadczenie federacyjne

W tej sekcji utworzysz poświadczenie tożsamości federacyjnej dla kopii zapasowej PostgreSQL, aby umożliwić CNPG używanie tożsamości obciążenia AKS do uwierzytelniania w docelowym koncie magazynu na potrzeby kopii zapasowych. Operator CNPG tworzy konto usługi Kubernetes o takiej samej nazwie jak klaster o nazwie używanej w manifeście wdrożenia klastra CNPG.

  1. Uzyskaj adres URL wystawcy OIDC klastra, używając polecenia az aks show.

    export AKS_PRIMARY_CLUSTER_OIDC_ISSUER="$(az aks show \
    --name $AKS_PRIMARY_CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

  2. Utwórz poświadczenia tożsamości federacyjnej przy użyciu polecenia az identity federated-credential create.

    az identity federated-credential create \
    --name $AKS_PRIMARY_CLUSTER_FED_CREDENTIAL_NAME \
    --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}" \
    --audience api://AzureADTokenExchange

Wdrażanie klastra PostgreSQL o wysokiej dostępności

W tej sekcji wdrożysz klaster PostgreSQL o wysokiej dostępności przy użyciu niestandardowej definicji zasobów klastra CPG (CRD).

Parametry CRD klastra

W poniższej tabeli przedstawiono właściwości klucza ustawione w manifeście wdrożenia YAML dla klastra CRD:

Property Definition
imageName Wskazuje obraz kontenera CloudNativePG operand. Użyj ghcr.io/cloudnative-pg/postgresql:18-system-trixie zgodnie z integracją kopii zapasowej pokazaną w tym przewodniku lub przełącz się na 18-standard-trixie przy korzystaniu z wtyczki Barman Cloud.
inheritedMetadata Specyficzny dla operatora CNPG. Operator CNPG stosuje metadane do każdego obiektu powiązanego z klastrem.
annotations Zawiera etykietę DNS wymaganą podczas uwidaczniania punktów końcowych klastra i włącza alpha.cnpg.io/failoverQuorum tryb failover oparty na kworum.
labels: azure.workload.identity/use: "true" Wskazuje, że usługa AKS powinna wprowadzać zależności tożsamości obciążenia do zasobników hostujących wystąpienia klastra PostgreSQL.
topologySpreadConstraints Wymagaj różnych stref i różnych węzłów z etykietą "workload=postgres".
resources Konfiguruje klasę Jakości usług (QoS) gwarantowanej. W środowisku produkcyjnym te wartości są kluczem do maksymalizacji użycia podstawowej maszyny wirtualnej węzła i różnią się w zależności od używanej jednostki SKU maszyny wirtualnej platformy Azure.
probes Zastępuje starszą startDelay konfigurację. Sondy początkowe i gotowości technologicznej pomagają zapewnić, że repliki są w dobrej kondycji, zanim zaczną obsługiwać ruch.
smartShutdownTimeout Umożliwia długotrwałym transakcjom na bezproblemowe zakończenie podczas aktualizacji zamiast używania agresywnych opóźnień zatrzymania.
bootstrap Specyficzny dla operatora CNPG. Inicjuje pustą bazę danych aplikacji.
storage Definiuje ustawienia PersistentVolume dla bazy danych. Dzięki dyskom zarządzanym platformy Azure uproszczona składnia przechowuje dane i WAL na tym samym woluminie 64 GiB, co umożliwia lepsze poziomy przepustowości na dyskach zarządzanych. Dostosuj, jeśli potrzebujesz oddzielnych woluminów WAL.
postgresql.synchronous minSyncReplicas / maxSyncReplicas Zamienia i umożliwia określenie synchronicznego zachowania replikacji przy użyciu nowszego schematu.
postgresql.parameters Specyficzny dla operatora CNPG. Ustawienia map dla postgresql.conf, pg_hba.confi pg_ident.conf. W przykładzie kładzie się nacisk na obserwowalność i domyślne wartości retencji WAL, które odpowiadają scenariuszowi tożsamości obciążenia usługi AKS, ale powinny być dostosowane do obciążenia.
serviceAccountTemplate Zawiera szablon wymagany do wygenerowania kont usług i mapowania poświadczeń tożsamości federacyjnej usługi AKS do interfejsu użytkownika w celu włączenia uwierzytelniania tożsamości obciążenia usługi AKS z zasobników hostających wystąpienia bazy danych PostgreSQL do zewnętrznych zasobów platformy Azure.
barmanObjectStore Specyficzny dla operatora CNPG. Konfiguruje pakiet narzędzi barman-cloud z wykorzystaniem tożsamości aplikacji AKS do uwierzytelniania w sklepie obiektów Azure Blob Storage.

Aby dodatkowo odizolować obciążenia PostgreSQL, możesz dodać znacznik (na przykład node-role.kubernetes.io/postgres=:NoSchedule) w węzłach płaszczyzny danych i zastąpić przykładowe wartości nodeSelector/tolerations wartościami zalecanymi przez CloudNativePG. Jeśli wybierzesz to podejście, oznacz węzły odpowiednio i potwierdź, że zasady autoskalowania AKS są zgodne z twoją topologią.

Parametry wydajności bazy danych PostgreSQL

Wydajność bazy danych PostgreSQL w dużym stopniu zależy od bazowych zasobów i obciążenia klastra. Poniższa tabela zawiera podstawowe wskazówki dla klastra z trzema węzłami działającego na węzłach Standard D4s v3 (16 GiB pamięci). Traktuj te wartości jako punkt początkowy i dostosuj je po zapoznaniu się z profilem obciążenia:

Property Zalecana wartość Definition
wal_compression lz4 Kompresuje pełnostronicowe zapisy w pliku WAL za pomocą określonej metody
max_wal_size 6 GB Ustawia rozmiar WAL, który wyzwala punkt kontrolny
checkpoint_timeout 15 minut Ustawia maksymalny czas między automatycznymi punktami kontrolnymi WAL
checkpoint_completion_target 0,9 Równoważy pracę punktu kontrolnego w ramach okna punktu kontrolnego
checkpoint_flush_after 2 MB Liczba stron, po których wcześniej wykonane operacje zapisu są opróżniane na dysk
wal_writer_flush_after 2 MB Ilość danych WAL zapisanych przez moduł zapisujący WAL, który wyzwala spłukanie
min_wal_size 2 GB Ustawia minimalny rozmiar, aby zmniejszyć "WAL".
max_slot_wal_keep_size 10 GB Górna granica dla WAL pozostało do obsługi slotów replikacji
shared_buffers 4 GB Ustawia liczbę pamięci udostępnionej używanych przez serwer (25% pamięci węzła w tym przykładzie)
effective_cache_size 12 GB Określa założenie planisty dotyczące całkowitego rozmiaru pamięci podręcznych danych
work_mem 1/256-owa część pamięci węzła Ustawia maksymalną ilość pamięci do użycia w obszarach roboczych zapytań
maintenance_work_mem 6.25% pamięci węzła Ustawia maksymalną ilość pamięci do użycia na potrzeby operacji konserwacji
autovacuum_vacuum_cost_limit 2400 Ilość kosztów próżni dostępna przed drzemką w przypadku autowakuum
random_page_cost 1.1 Ustawia szacowanie kosztu przez planistę dla niesekwencyjnie pobranej strony dysku
effective_io_concurrency 64 Określa liczbę równoczesnych żądań, które podsystem dysków może obsłużyć wydajnie
maintenance_io_concurrency 64 Wariant "effective_io_concurrency", który jest używany do prac konserwacyjnych

Wdrażanie bazy danych PostgreSQL

  1. Wdróż klaster PostgreSQL przy użyciu klastra CRD przy użyciu kubectl apply polecenia .

    cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME -n $PG_NAMESPACE -v 9 -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: $PG_PRIMARY_CLUSTER_NAME
  annotations:
    alpha.cnpg.io/failoverQuorum: "true"
spec:
  imageName: ghcr.io/cloudnative-pg/postgresql:18-system-trixie
  inheritedMetadata:
    annotations:
      service.beta.kubernetes.io/azure-dns-label-name: $AKS_PRIMARY_CLUSTER_PG_DNSPREFIX
    labels:
      azure.workload.identity/use: "true"

  instances: 3
  smartShutdownTimeout: 30

  probes:
    startup:
      type: streaming
      maximumLag: 32Mi
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 120
    readiness:
      type: streaming
      maximumLag: 0
      periodSeconds: 10
      failureThreshold: 6

  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        cnpg.io/cluster: $PG_PRIMARY_CLUSTER_NAME

  affinity:
    nodeSelector:
      workload: postgres

  resources:
    requests:
      memory: '8Gi'
      cpu: 2
    limits:
      memory: '8Gi'
      cpu: 2

  bootstrap:
    initdb:
      database: appdb
      owner: app
      secret:
        name: db-user-pass
      dataChecksums: true

  storage:
    storageClass: $POSTGRES_STORAGE_CLASS
    size: 64Gi

  postgresql:
    synchronous:
      method: any
      number: 1
    parameters:
      wal_compression: lz4
      max_wal_size: 6GB
      max_slot_wal_keep_size: 10GB
      checkpoint_timeout: 15min
      checkpoint_completion_target: '0.9'
      checkpoint_flush_after: 2MB
      wal_writer_flush_after: 2MB
      min_wal_size: 2GB
      shared_buffers: 4GB
      effective_cache_size: 12GB
      work_mem: 62MB
      maintenance_work_mem: 1GB
      autovacuum_vacuum_cost_limit: "2400"
      random_page_cost: "1.1"
      effective_io_concurrency: "64"
      maintenance_io_concurrency: "64"
      log_checkpoints: 'on'
      log_lock_waits: 'on'
      log_min_duration_statement: '1000'
      log_statement: 'ddl'
      log_temp_files: '1024'
      log_autovacuum_min_duration: '1s'
      pg_stat_statements.max: '10000'
      pg_stat_statements.track: 'all'
      hot_standby_feedback: 'on'
    pg_hba:
      - host all all all scram-sha-256

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

  backup:
    barmanObjectStore:
      destinationPath: "https://${PG_PRIMARY_STORAGE_ACCOUNT_NAME}.blob.core.windows.net/backups"
      azureCredentials:
        inheritFromAzureAD: true
    retentionPolicy: '7d'
EOF

Uwaga / Notatka

Przykładowy manifest używa ghcr.io/cloudnative-pg/postgresql:18-system-trixie obrazu, ponieważ współdziała z podstawową integracją platformy Barman Cloud pokazaną później. Gdy będziesz gotowy do przełączenia się na wtyczkę Barman Cloud, zaktualizuj spec.imageName do ghcr.io/cloudnative-pg/postgresql:18-standard-trixie i postępuj zgodnie z wskazówkami dotyczącymi konfiguracji wtyczki zanim ponownie wdrożysz klaster.

Important

Przykładowy pg_hba wpis zezwala na dostęp bez protokołu TLS. Jeśli zachowasz tę konfigurację, udomentuj implikacje dotyczące zabezpieczeń twojego zespołu i preferuj szyfrowane połączenia wszędzie tam, gdzie to możliwe.

  1. Sprawdź, czy podstawowy klaster PostgreSQL został pomyślnie utworzony przy użyciu kubectl get polecenia . Klaster CNPG CRD określił trzy instancje, które można zweryfikować, wyświetlając uruchomione zasobniki, gdy każda instancja jest włączona i dołączona do replikacji. Bądź cierpliwy, ponieważ może upłynąć trochę czasu, aż wszystkie trzy wystąpienia zostaną dołączone do klastra w trybie online.

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

    Przykładowe dane wyjściowe

    NAME                         READY   STATUS    RESTARTS   AGE
pg-primary-cnpg-r8c7unrw-1   1/1     Running   0          4m25s
pg-primary-cnpg-r8c7unrw-2   1/1     Running   0          3m33s
pg-primary-cnpg-r8c7unrw-3   1/1     Running   0          2m49s

Important

Jeśli używasz lokalnego urządzenia NVMe z usługą Azure Container Storage, a zasobnik pozostanie w stanie inicjowania z błędem wielokrotnego dołączania, zasobnik nadal wyszukuje wolumin w utraconym węźle. Po uruchomieniu zasobnika, przechodzi do stanu CrashLoopBackOff, ponieważ CNPG tworzy nową replikę na nowym węźle bez danych i nie może znaleźć katalogu pgdata. Aby rozwiązać ten problem, należy zniszczyć wystąpienie, którego dotyczy problem, i utworzyć nowe. Uruchom następujące polecenie:

kubectl cnpg destroy [cnpg-cluster-name] [instance-number]

Sprawdź, czy uruchomiono narzędzie Prometheus PodMonitor

Ręcznie utworzony PodMonitor łączy konfigurację pobierania kube-prometheus-stack z wcześniej wdrożonymi zasobnikami CNPG.

Zweryfikuj, czy PodMonitor działa, przy użyciu polecenia kubectl get.

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.monitoring.coreos.com \
    $PG_PRIMARY_CLUSTER_NAME \
    --output yaml

Przykładowe dane wyjściowe

kind: PodMonitor
metadata:
  labels:
    cnpg.io/cluster: pg-primary-cnpg-r8c7unrw
  name: pg-primary-cnpg-r8c7unrw
  namespace: cnpg-database
spec:
  podMetricsEndpoints:
  - port: metrics
  selector:
    matchLabels:
      cnpg.io/cluster: pg-primary-cnpg-r8c7unrw

Jeśli używasz Azure Monitor dla zarządzanego Prometheus, musisz dodać kolejny monitor pod przy użyciu niestandardowej nazwy grupy. Zarządzany Prometheus nie przejmuje niestandardowych definicji zasobów (CRD) ze społeczności Prometheus. Oprócz nazwy grupy identyfikatory CRD są takie same. Ten projekt umożliwia monitorowanie zasobników dla Managed Prometheus równocześnie z monitorami zasobników korzystającymi ze społecznościowego CRD. Jeśli nie używasz zarządzanego rozwiązania Prometheus, możesz pominąć tę sekcję. Utwórz nowy monitor zasobnika:

cat <<EOF | kubectl apply --context $AKS_PRIMARY_CLUSTER_NAME --namespace $PG_NAMESPACE -f -
apiVersion: azmonitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-cluster-metrics-managed-prometheus
  namespace: ${PG_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"
    cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
spec:
  selector:
    matchLabels:
      azure.workload.identity/use: "true"
      cnpg.io/cluster: ${PG_PRIMARY_CLUSTER_NAME}
  podMetricsEndpoints:
    - port: metrics
EOF

Zweryfikuj, czy monitor podu został utworzony (zwróć uwagę na różnicę w nazwie grupy).

kubectl --namespace $PG_NAMESPACE \
    --context $AKS_PRIMARY_CLUSTER_NAME \
    get podmonitors.azmonitoring.coreos.com \
    -l cnpg.io/cluster=$PG_PRIMARY_CLUSTER_NAME \
    -o yaml

Opcja A — obszar roboczy usługi Azure Monitor

Po wdrożeniu klastra Postgres i monitora kontenera można wyświetlić metryki przy użyciu portalu Azure w obszarze roboczym usługi Azure Monitor.

Zrzut ekranu przedstawiający metryki klastra Postgres w obszarze roboczym usługi Azure Monitor w witrynie Azure Portal.

Opcja B — zarządzana Grafana

Alternatywnie po wdrożeniu monitorów klastra Postgres i zasobnika można utworzyć pulpit nawigacyjny metryk w wystąpieniu Zarządzany Grafana utworzonym przez skrypt wdrożenia, aby zwizualizować metryki wyeksportowane do obszaru roboczego usługi Azure Monitor. Dostęp do aplikacji Managed Grafana można uzyskać za pośrednictwem witryny Azure Portal. Przejdź do zarządzanej instancji Grafana utworzonej przez skrypt wdrożenia i wybierz link Endpoint, jak pokazano poniżej.

Zrzut ekranu przedstawiający metryki klastra Postgres w zarządzanym wystąpieniu Grafana na platformie Azure, w portalu Azure.

Wybranie linku Punkt końcowy powoduje otwarcie nowego okna przeglądarki, w którym można tworzyć pulpity nawigacyjne w zarządzanej instancji Grafana. Postępując zgodnie z instrukcjami konfigurowania źródła danych usługi Azure Monitor, możesz dodać wizualizacje, aby utworzyć pulpit nawigacyjny metryk z klastra Postgres. Po skonfigurowaniu połączenia ze źródłem danych w menu głównym wybierz opcję Źródła danych. Powinien zostać wyświetlony zestaw opcji źródła danych dla połączenia ze źródłem danych, jak pokazano poniżej:

Zrzut ekranu przedstawiający opcje źródła danych usługi Azure Monitor w witrynie Azure Portal.

Na opcji Zarządzany Prometheus wybierz opcję utworzenia pulpitu nawigacyjnego, aby otworzyć edytor. Po otwarciu okna edytora wybierz opcję Dodaj wizualizację, a następnie wybierz opcję Zarządzany Prometheus, aby przeglądać metryki z klastra Postgres. Po wybraniu metryki, którą chcesz wizualizować, wybierz przycisk Uruchom zapytania, aby pobrać dane wizualizacji, jak pokazano poniżej:

Zrzut ekranu przedstawiający pulpit nawigacyjny zarządzanego rozwiązania Prometheus z metrykami klastra Postgres.

Wybierz ikonę Zapisz, aby dodać panel do pulpitu nawigacyjnego. Możesz dodać inne panele, wybierając przycisk Dodaj w edytorze pulpitu nawigacyjnego i powtarzając ten proces, aby zwizualizować inne metryki. Dodając wizualizacje metryk, powinieneś mieć coś, co wygląda tak:

Zrzut ekranu przedstawiający zapisany pulpit nawigacyjny Managed Prometheus w Azure Portal.

Wybierz ikonę Zapisz, aby zapisać pulpit nawigacyjny.

Dalsze kroki

Testowanie i weryfikowanie bazy danych PostgreSQL

Contributors

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

  • Last updated on