Fehlerbehebung beim AlloyDB Omni Kubernetes-Operator

Wählen Sie eine Dokumentationsversion aus: 18.4.0

• Aktuelle Version (18.4.0)
• 18.4.0
• 18.3.0
• 18.1.0
• 17.10.0
• 17.9.0
• 17.7.0
• 17.5.0
• 16.14.0
• 16.13.0
• 16.11.0
• 16.9.0
• 16.8.0
• 16.3.0
• 15.18.0
• 15.17.0
• 15.15.0
• 15.13.0
• 15.12.0
• 15.7.1

Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem AlloyDB Omni Kubernetes-Operator beheben, einschließlich Problemumgehungen für bekannte Probleme.

Debugging-Informationen erfassen

In diesen Abschnitten wird beschrieben, wie Sie Logs und Konfigurationen für die Fehlerbehebung erfassen.

Logs von Operator-Pods abrufen

Führen Sie die folgenden Befehle aus, um Logs von den Operator-Pods abzurufen:

kubectl logs deployments/fleet-controller-manager -c fleet-manager -n alloydb-omni-system > alloydb-omni-system-fleet-controller-manager.out
kubectl logs deployments/local-controller-manager -c local-manager -n alloydb-omni-system > alloydb-omni-system-local-controller-manager.out

Datenbank-Pod-Logs abrufen

Führen Sie die folgenden Befehle aus, um Datenbank-Pod-Logs abzurufen:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl logs -c database ${DB_POD} -n DB_CLUSTER_NAMESPACE > ${DB_POD}.log
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -c database -n DB_CLUSTER_NAMESPACE > dbcluster_DB_CLUSTER_NAME.out

Die folgenden Logs sind Beispiele für erfolgreiche Datenbank-Systemdiagnosen:

I0813 11:01:49.210051      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196796      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196853      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.209824      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197013      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197093      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.210010      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197368      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197425      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.210416      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"

postgresql.log abrufen

Führen Sie den folgenden Befehl aus, um die postgresql.log abzurufen:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE -it ${DB_POD} -- cat /obs/diagnostic/postgresql.log > dbcluster_DB_CLUSTER_NAME_postgresql.log

YAML-Datei für DBInstance abrufen

Führen Sie den folgenden Befehl aus, um die YAML-Datei für die DBInstance abzurufen:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

Konfigurationen und Logs für HA-Szenarien abrufen

Führen Sie die folgenden Befehle aus, um Konfigurationen und Logs für Hochverfügbarkeitsszenarien abzurufen:

kubectl get replicationconfig.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > replicationconfig_DB_CLUSTER_NAME.yaml
kubectl get deletestandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > deletestandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > createstandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get failovers.alloydbomni.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > failovers_DB_CLUSTER_NAME.yaml

Pod- und STS-Status abrufen

Führen Sie die folgenden Befehle aus, um den Status von Pods und StatefulSets (STS) abzurufen:

DB_POD=$(kubectl get pod -n DB_CLUSTER_NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod ${DB_POD} -n DB_CLUSTER_NAMESPACE > pod_${DB_POD}.out
kubectl describe statefulset -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE > statefulset_DB_CLUSTER_NAME.out

Fehler finden

In diesen Abschnitten wird beschrieben, wie Sie Fehler erkennen.

Nach Fehlerstatus und Fehlercodes suchen

Den Fehlercode finden Sie in der YAML-Datei des DBClusters unter „Status“. Weitere Informationen finden Sie in der Dokumentation zu Fehlercodes.

Führen Sie den folgenden Befehl aus, um die YAML-Datei für den DBCluster abzurufen:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

Suchen Sie nach criticalIncidents. Dieser Abschnitt enthält den Fehlercode und einen Stacktrace.

Hier einige Beispiele für criticalIncidents:

status:
    certificateReference:
      certificateKey: ca.crt
      secretRef:
        name: dbs-al-cert-dr-mce
        namespace: dr
    conditions:
    -   lastTransitionTime: "2024-10-07T22:46:03Z"
    ...
    criticalIncidents:
    -   code: DBSE0304
      createTime: "2024-10-03T11:50:54Z"
      message: 'Healthcheck: Health check invalid result.'
      resource:
        component: healthcheck
        location:
          group: alloydbomni.internal.dbadmin.goog
          kind: Instance
          name: bc0f-dr-mce
          namespace: dr
          version: v1
      stackTrace:
      -   component: healthcheck
        message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
          = Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
          dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
          Lag is 384837.296269 seconds, wanted 35 seconds'

Sie können den Status auch abrufen, indem Sie bestimmte Felder im JSON-Format extrahieren:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.status.criticalIncidents}' | jq

Die Ausgabe sieht etwa so aus:

[
  {
    "code": "DBSE0085",
    "createTime": "2024-03-14T05:41:37Z",
    "message": "Platform: Pod is unschedulable.",
    "resource": {
      "component": "provisioning",
      "location": {
        "group": "alloydb.internal.dbadmin.goog",
        "kind": "Instance",
        "name": "b55f-testdbcluster",
        "namespace": "dbs-system",
        "version": "v1"
      }
    },
    "stackTrace": [
      {
        "component": "provisioning",
        "message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
      }
    ]
  }
]

Wenn sich die Fehlermeldung auf den Datenbank-Pod bezieht, prüfen Sie die Instanzen und Pod-Ressourcen im selben Namespace:

kubectl get instances.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > instance_DB_CLUSTER_NAME.yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme und Problemumgehungen für den AlloyDB Omni-Operator beschrieben. Eine vollständige Liste der Release-Ankündigungen, Fehlerkorrekturen und Sicherheitsupdates finden Sie in den Versionshinweisen.

Zertifikatsausstellung schlägt in cert-manager fehl

Der AlloyDB Omni-Operator verwendet cert-manager, um TLS-Zertifikate (Transport Layer Security) für den Operator und die Datenbankcluster bereitzustellen. In cert-manager-Version 1.21.2 und früheren Versionen kann eine bekannte Race-Bedingung (cert-manager-Problem #6331) dazu führen, dass die Zertifikatsausstellung fehlschlägt und ein einstündiger Backoff für Wiederholungsversuche eintritt.

Betroffene Versionen

AlloyDB Omni-Operator 1.0.0 und höher mit cert-manager 1.21.2 und niedriger.

Symptome

Wenn dieses Problem auftritt, können die folgenden Symptome auftreten:

• Eine DBCluster-Ressource bleibt in der Phase DBClusterWaitingForCertificate und die Erstellung oder das Upgrade des Datenbankclusters wird abgebrochen.
• Eine Helm-Installation des AlloyDB Omni-Operators schlägt fehl, weil eine Certificate-Ressource, z. B. local-serving-cert im Namespace alloydb-omni-system, nicht bereit ist.
• Die Statusbedingungen einer Certificate-Ressource enthalten die Nachricht CSR not signed by referenced private key mit dem Grund Failed oder ErrorKeyMatch.

Führen Sie den folgenden Befehl aus, um die Certificate-Ressourcen zu finden, die von diesem Problem betroffen sind:

kubectl get certificates.cert-manager.io --all-namespaces \
    -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.status.conditions[*].message}{"\n"}{end}' \
    | grep "CSR not signed by referenced private key"

In der Ausgabe werden der Namespace, der Name und die Statusbedingungsnachrichten jeder betroffenen Certificate-Ressource aufgeführt. Wenn Sie eine betroffene Certificate-Ressource im YAML-Format aufrufen, sieht das Feld status in etwa so aus:

status:
  conditions:
  - message: 'The certificate request has failed to complete and will be retried: Error generating certificate template: CSR not signed by referenced private key'
    reason: Failed
    status: "False"
    type: Issuing
  failedIssuanceAttempts: 1

Problemumgehung

Um Konflikte bei Controller-Updates zu vermeiden und die Wiederholungsverzögerung für fehlgeschlagene Zertifikatsanfragen von einer Stunde auf 15 Sekunden zu reduzieren, aktualisieren Sie cert-manager mit dem Feature Gate ServerSideApply und kürzeren Backoff-Dauern:

helm upgrade cert-manager oci://quay.io/jetstack/charts/cert-manager \
    --version CERT_MANAGER_VERSION \
    --namespace cert-manager \
    --reuse-values \
    --set featureGates="ServerSideApply=true" \
    --set "extraArgs={--certificate-request-minimum-backoff-duration=15s,--certificate-request-maximum-backoff-duration=5m}"

Ersetzen Sie Folgendes:

• CERT_MANAGER_VERSION: die Version von cert-manager, die in Ihrem Kubernetes-Cluster installiert ist, z. B. v1.21.2. Führen Sie den Befehl helm list --namespace cert-manager aus, um die installierte Version zu ermitteln.

Hinweis: Wenn Sie die Flags --set für die Schlüssel featureGates und extraArgs übergeben, werden ihre vorhandenen Werte im Helm-Release ersetzt, auch wenn Sie das Flag --reuse-values angeben. Wenn in Ihrem cert-manager-Release bereits andere Feature Gates oder zusätzliche Argumente konfiguriert sind, fügen Sie sie in die durch Kommas getrennten Listen ein. GKE-Autopilot-Cluster müssen auch das Flag --set global.leaderElection.namespace=cert-manager enthalten.

Prüfen Sie nach dem Neustart des cert-manager-Controllers, ob für alle Zertifikate in der Spalte READY der Wert True angezeigt wird:

kubectl get certificates.cert-manager.io --all-namespaces

Wenn die Installation des AlloyDB Omni-Operators aufgrund dieses Problems fehlgeschlagen ist, führen Sie die Installation noch einmal aus.

Upgrade der Nebenversion für die Wartung mit geringer Ausfallzeit wird auf einem sekundären Datenbankcluster nicht mehr fortgesetzt

Betroffene Versionen

AlloyDB Omni-Operator 1.8.0 und höher.

Symptome

Während eines Upgrades oder Downgrades einer Nebenversion eines sekundären Datenbankclusters für die rechenzentrumsübergreifende Replikation, der Stand-by-Instanzen mit Hochverfügbarkeit (HA) hat, wird der Vorgang nach dem Upgrade der ersten Stand-by-Instanz angehalten. Die DBCluster-Ressource bleibt im Status DBCUpgradeInProgress=True mit dem Grund DBCUpgradeFlowBegins.

Problemumgehung

1. Deaktivieren Sie die Wartung mit geringer Ausfallzeit (LDTM) auf dem sekundären Datenbankcluster, damit der AlloyDB Omni-Operator das Upgrade mit dem standardmäßigen rollierenden Upgrade-Workflow abschließt:

   kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       dbcluster.dbadmin.goog/enableLDTM=false \
       --namespace DB_CLUSTER_NAMESPACE \
       --overwrite
   

   Ersetzen Sie Folgendes:

   • DB_CLUSTER_NAME: der Name Ihrer sekundären DBCluster-Ressource.
   • DB_CLUSTER_NAMESPACE: der Namespace Ihrer sekundären DBCluster-Ressource.

2. Prüfen Sie, ob das Upgrade abgeschlossen ist und die Ressource DBCluster die Phase DBClusterReady erreicht:

   kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       --namespace DB_CLUSTER_NAMESPACE
   

3. Aktivieren Sie die Wartung mit geringer Ausfallzeit für den sekundären Datenbankcluster wieder, damit die DBCluster-Ressource die Wartungsfunktion mit geringer Ausfallzeit beibehält, wenn sie zu einem primären Datenbankcluster hochgestuft wird:

   kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       dbcluster.dbadmin.goog/enableLDTM=true \
       --namespace DB_CLUSTER_NAMESPACE \
       --overwrite
   

Beim Monitoring-Agent treten nach dem Aktivieren der rechenzentrumsübergreifenden Replikation cgroups-Berechtigungsfehler auf

Betroffene Versionen

AlloyDB Omni-Operator 1.9.0.

Symptome

Nachdem Sie die rechenzentrumsübergreifende Replikation aktiviert haben, treten beim Monitoring-Agent Berechtigungsfehler in den Containerlogs auf, wenn versucht wird, cgroups-Informationen zu erfassen.

Problemumgehung

1. Listen Sie die Datenbank-Pods in Ihrem sekundären Datenbankcluster auf, um den Namen des nachgelagerten Datenbank-Pods zu finden:

   kubectl get pods \
       --selector alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database \
       --namespace DB_CLUSTER_NAMESPACE
   

   Ersetzen Sie Folgendes:

   • DB_CLUSTER_NAME: der Name Ihrer sekundären DBCluster-Ressource.
   • DB_CLUSTER_NAMESPACE: der Namespace Ihrer sekundären DBCluster-Ressource.

2. Löschen Sie den nachgelagerten Datenbank-Pod, damit der AlloyDB Omni-Operator den Pod neu erstellt und neu startet:

   kubectl delete pod DB_POD_NAME \
       --namespace DB_CLUSTER_NAMESPACE
   

   Ersetzen Sie DB_POD_NAME durch den Namen des Downstream-Datenbank-Pods aus dem vorherigen Schritt.

Datenbankcluster löst kontinuierlich automatische Failover aus

Wenn Ihre DBCluster-Ressource mehrere automatische Failover nacheinander erstellt, führen Sie die folgenden Prüfungen durch:

1. Listen Sie die Failover-Ressourcen für Ihre DBCluster auf und vergleichen Sie deren Erstellungszeitstempel:

   kubectl get failover.alloydbomni.dbadmin.goog \
       --selector failover.dbadmin.goog/dbcluster=DB_CLUSTER_NAME \
       --namespace DB_CLUSTER_NAMESPACE
   

   Ersetzen Sie Folgendes:

   • DB_CLUSTER_NAME: der Name Ihrer DBCluster-Ressource.
   • DB_CLUSTER_NAMESPACE: der Namespace Ihrer DBCluster-Ressource.

2. Stellen Sie eine Verbindung zum primären Datenbank-Pod in der Datenbank alloydbadmin her und prüfen Sie den Zustand der Datenbank:

   SELECT * FROM healthcheck;
   

   Prüfen Sie, ob der Zeitstempel der letzten Systemdiagnose aktuell ist und ob die Systemdiagnosen in den erwarteten Intervallen ausgeführt werden. Wenn die primäre Instanz fehlerhaft ist, prüfen Sie die Datei postgresql.log, um die Ursache des Fehlers zu ermitteln. Weitere Informationen zum Abrufen von Logs finden Sie unter Fehlerbehebung beim AlloyDB Omni Kubernetes-Operator.

Wenn Sie eine große Anzahl von Datenbankclustern in einem einzelnen Kubernetes-Cluster verwenden oder wenn Sie Datenbankcluster haben, die nicht ausreichend bereitgestellt sind, kann es bei automatischen Failover-Systemdiagnosen zu einer Zeitüberschreitung oder zu einem Verbindungsfehler kommen. Wenn Sie einen Fehler erhalten, der mit HealthCheckProber: health check for instance failed beginnt, finden Sie die empfohlenen Korrekturen unter Fehlerbehebung bei der Instanzreparatur. Sie können auch die folgenden Maßnahmen ergreifen, um automatische Failover zu reduzieren oder zu verhindern:

• Erhöhen Sie den Wert von autoFailoverTriggerThreshold, damit das automatische Failover seltener erfolgt. Weitere Informationen finden Sie unter Einstellungen für den automatischen Failover-Trigger anpassen.

• Automatisches Failover für Datenbankcluster deaktivieren. Weitere Informationen finden Sie unter Automatisches Failover deaktivieren.

Datenbankcluster bleibt im Failover- oder Switchover-Status hängen

Während eines Hochverfügbarkeits-Failovers oder ‑Switchovers isoliert der AlloyDB Omni-Operator die ehemalige primäre Instanz während der StopPrimary-Phase, indem er die PG_VERSION-Dateien in PG_VERSION.disabled umbenennt. Dies geschieht sowohl im Stamm-Datenverzeichnis unter /pgdata/db/PG_VERSION.disabled als auch in jedem Datenbankunterverzeichnis unter /pgdata/db/base/OID/PG_VERSION.disabled. Wenn das Failover oder der Switchover fehlschlägt, bevor die Stand-by-Instanz hochgestuft wird, und kein automatisches Rollback erfolgt oder fehlschlägt, bleibt die ehemalige primäre Instanz isoliert und die DBCluster-Ressource bleibt in einer laufenden oder fehlgeschlagenen Rollback-Phase hängen.

Betroffene Versionen

AlloyDB Omni-Operator 1.0.0 und höher.

Symptome

Wenn dieses Problem auftritt, können die folgenden Symptome auftreten:

• Das Feld status.phase der Ressource DBCluster bleibt in DBClusterFailoverInProgress, DBClusterSwitchoverInProgress, DBClusterFailoverRollbackFailed oder DBClusterSwitchoverRollbackFailed.
• Die Bedingung HAReady für die Ressource DBCluster hat den Wert status: "False" mit dem Grund FailoverInProgress oder SwitchoverInProgress.
• Die Ressource Failover (failovers.alloydbomni.dbadmin.goog) oder Switchover (switchovers.alloydbomni.dbadmin.goog) hat den Status Failed oder Failed_RollbackFailed.
• Das Feld status.internal.phase der Ressource Failover oder Switchover bleibt in einer Phase vor PromoteStandby, z. B. StopPrimary, oder bleibt eine Stunde oder länger in der Phase PromoteStandby, ohne die Stand-by-Instanz hochzustufen.
• Der primäre Datenbank-Pod kann PostgreSQL nicht starten und protokolliert einen Fehler, der darauf hinweist, dass die Datei PG_VERSION fehlt, weil PG_VERSION in /pgdata/db/PG_VERSION.disabled und /pgdata/db/base/OID/PG_VERSION.disabled in PG_VERSION.disabled umbenannt wurde.

• Wenn bei einer vorherigen manuellen Wiederherstellung nur die /pgdata/db/PG_VERSION-Datei auf oberster Ebene wiederhergestellt wurde, während PG_VERSION.disabled-Dateien in den /pgdata/db/base/OID/-Unterverzeichnissen verblieben sind, schlagen nachfolgende pg_basebackup-Vorgänge auf Stand-by-Instanzen mit dem folgenden Fehler in den PostgreSQL-Logs auf der primären Instanz fehl:

  XX000:ERROR: [basebackup.c:1549] invalid segment number 0 in file "PG_VERSION.disabled"
  

Problemumgehung

Warnung: Mit diesem Verfahren wird der Datenbankcluster auf die vorherige primäre Instanz zurückgesetzt. Führen Sie dieses Verfahren nur aus, wenn die Stand-by-Instanz nicht hochgestuft wurde und entweder beendet ist oder sich noch im Lesezugriff-Wiederherstellungsmodus befindet. Wenn das Failover oder der Switchover bereits die Phase PromoteStandby überschritten und die Stand-by-Instanz hochgestuft hat, kann ein Rollback zur ehemaligen primären Instanz zu Datenverlust führen. Stellen Sie stattdessen den Datenbankcluster aus einer Sicherung wieder her.

Führen Sie die folgenden Schritte aus, um die ehemalige primäre Instanz manuell zu entsperren und die DBCluster-Ressource wiederherzustellen:

1. Prüfen Sie die externen und internen Failover- oder Switchover-Ressourcen im Namespace Ihres Datenbankclusters, um deren Phase zu prüfen und die ehemalige primäre Instanz (oldPrimary) und die Ziel-Stand-by-Instanz (newPrimary) zu identifizieren:

   kubectl get failovers.alloydbomni.dbadmin.goog,switchovers.alloydbomni.dbadmin.goog,failovers.alloydbomni.internal.dbadmin.goog,instanceswitchovers.alloydbomni.internal.dbadmin.goog \
       --namespace DB_CLUSTER_NAMESPACE \
       -o yaml
   

   Ersetzen Sie DB_CLUSTER_NAMESPACE durch den Namespace Ihrer DBCluster-Ressource.

   Prüfen Sie, ob status.internal.phase nicht über PromoteStandby hinausgegangen ist. Wenn der Pod der Standby-Datenbank ausgeführt wird, prüfen Sie, ob PostgreSQL auf der Standby-Instanz noch im schreibgeschützten Wiederherstellungsmodus ist:

   kubectl exec -c database STANDBY_POD_NAME \
       --namespace DB_CLUSTER_NAMESPACE -- \
       psql -U alloydbadmin -d alloydbadmin -c "SELECT pg_is_in_recovery();"
   

   Ersetzen Sie STANDBY_POD_NAME durch den Namen des Stand-by-Datenbank-Pods im Format al-STANDBY_INSTANCE_NAME-0, wobei STANDBY_INSTANCE_NAME der Wert von status.internal.newPrimary ist.

   Prüfen Sie, ob die Abfrage t (true) zurückgibt oder ob der Pod der Standby-Datenbank beendet wurde. Nachdem Sie bestätigt haben, dass die Stand-by-Instanz nicht hochgestuft wurde, löschen Sie die Stand-by-Ressource Instance, um zu verhindern, dass sie während der Wiederherstellung hochgestuft wird:

   kubectl delete instances.alloydbomni.internal.dbadmin.goog STANDBY_INSTANCE_NAME \
       --namespace DB_CLUSTER_NAMESPACE
   

   Ersetzen Sie STANDBY_INSTANCE_NAME durch den Namen der Stand-by-Instance-Ressource aus dem Feld status.internal.newPrimary.

2. Suchen Sie im Datenverzeichnis /pgdata/db auf dem primären Datenbank-Pod nach den Dateien PG_VERSION und PG_VERSION.disabled:

   kubectl exec -c database PRIMARY_POD_NAME \
       --namespace DB_CLUSTER_NAMESPACE -- \
       find /pgdata/db -type f -name "PG_VERSION*"
   

   Ersetzen Sie PRIMARY_POD_NAME durch den Namen des primären Datenbank-Pods im Format al-PRIMARY_INSTANCE_NAME-0, wobei PRIMARY_INSTANCE_NAME der Wert von status.internal.oldPrimary ist.

   Wenn weder PG_VERSION noch PG_VERSION.disabled in /pgdata/db vorhanden ist, kann das Datenbankdatenverzeichnis nicht wiederhergestellt werden und muss aus einer Sicherung wiederhergestellt werden.

   Wenn PG_VERSION.disabled-Dateien vorhanden sind, stellen Sie PG_VERSION sowohl im Stamm-Datenverzeichnis unter /pgdata/db/PG_VERSION.disabled als auch in jedem Datenbankunterverzeichnis unter /pgdata/db/base/OID/PG_VERSION.disabled wieder her. Mit dem folgenden Befehl wird jede PG_VERSION.disabled-Datei wieder in PG_VERSION umbenannt oder die PG_VERSION.disabled-Datei entfernt, wenn die entsprechende PG_VERSION-Datei bereits wiederhergestellt wurde:

   kubectl exec -c database PRIMARY_POD_NAME \
       --namespace DB_CLUSTER_NAMESPACE -- \
       sh -c 'find /pgdata/db -type f -name "PG_VERSION.disabled" | while read -r f; do
         target="${f%.disabled}"
         if [ -f "$target" ]; then rm -f "$f"; else mv "$f" "$target"; fi
       done'
   

3. Starten Sie den PostgreSQL-Dienst im primären Datenbank-Pod neu:

   kubectl exec -c database PRIMARY_POD_NAME \
       --namespace DB_CLUSTER_NAMESPACE -- \
       /scripts/supervisor/bin/supervisorctl.par \
       -c /scripts/supervisor/etc/supervisord.conf restart postgres
   

4. Löschen Sie den fehlgeschlagenen Failover- oder Switchover-Status mit einer der folgenden Optionen:

   • Option 1: Löschen Sie die Failover- oder Switchover-Ressourcen und starten Sie die Operator-Controller neu. Löschen Sie sowohl die externen als auch die internen Failover-Ressourcen und starten Sie die Deployments fleet-controller-manager und local-controller-manager im Namespace alloydb-omni-system neu, um In-Memory-Sperren aufzuheben:

     kubectl delete failovers.alloydbomni.dbadmin.goog FAILOVER_NAME \
         --namespace DB_CLUSTER_NAMESPACE
     kubectl delete failovers.alloydbomni.internal.dbadmin.goog INTERNAL_FAILOVER_NAME \
         --namespace DB_CLUSTER_NAMESPACE
     kubectl rollout restart deployment/fleet-controller-manager deployment/local-controller-manager \
         --namespace alloydb-omni-system
     

     Ersetzen Sie Folgendes:

     • FAILOVER_NAME: der Name der failovers.alloydbomni.dbadmin.goog-Ressource.
     • INTERNAL_FAILOVER_NAME: der Name der failovers.alloydbomni.internal.dbadmin.goog-Ressource.

     Wenn ein Switchover statt eines Failovers hängen bleibt, löschen Sie stattdessen die Ressourcen switchovers.alloydbomni.dbadmin.goog und instanceswitchovers.alloydbomni.internal.dbadmin.goog.

   • Option 2: Markieren Sie die Failover-Ressourcen als zurückgesetzt. Diese Option gilt nur für hängende Failover-Ressourcen. Wenn eine Switchover-Ressource hängen bleibt, verwenden Sie stattdessen Option 1. Bearbeiten Sie die Unterressource status sowohl für die Ressource failovers.alloydbomni.dbadmin.goog als auch für die Ressource failovers.alloydbomni.internal.dbadmin.goog:

     kubectl edit failovers.alloydbomni.dbadmin.goog FAILOVER_NAME \
         --namespace DB_CLUSTER_NAMESPACE \
         --subresource=status
     kubectl edit failovers.alloydbomni.internal.dbadmin.goog INTERNAL_FAILOVER_NAME \
         --namespace DB_CLUSTER_NAMESPACE \
         --subresource=status
     

     Legen Sie im Abschnitt status jeder Failover-Ressource endTime auf einen Zeitstempel nach createTime, internal.phase auf RollbackSucceeded und state auf Failed fest, wie im folgenden Beispiel gezeigt:

     apiVersion: alloydbomni.dbadmin.goog/v1
     kind: Failover
     status:
       createTime: "2026-09-01T22:07:42Z"
       endTime: "2026-09-01T22:07:50Z"
       internal:
         attempt: 0
         lastPhaseChangeTime: "2026-09-01T22:07:39Z"
         newPrimary: 4274-dbcluster-sample
         newPrimaryZone: ""
         oldPrimary: dafd-dbcluster-sample
         phase: RollbackSucceeded
       observedGeneration: 2
       reconciled: true
       startTime: "2026-09-01T22:07:39Z"
       state: Failed
     

5. Aktualisieren Sie die Unterressource status der Ressource DBCluster, um latestFailoverStatus zu löschen und phase auf DBClusterReconciling festzulegen:

   kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       --namespace DB_CLUSTER_NAMESPACE \
       --subresource=status \
       --type=merge \
       --patch '{"status":{"latestFailoverStatus":null,"phase":"DBClusterReconciling"}}'
   

   Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihrer DBCluster-Ressource.

   Wenn die Bedingung HAReady in status.conditions den Abgleich weiterhin verhindert, weil das Feld reason auf FailoverInProgress oder SwitchoverInProgress gesetzt ist, bearbeiten Sie die Unterressource status der Ressource DBCluster und entfernen Sie entweder den Eintrag für die Bedingung HAReady aus status.conditions, damit der AlloyDB Omni-Operator ihn während des Abgleichs neu erstellt, oder setzen Sie das Feld reason auf einen gültigen, nicht leeren CamelCase-Wert wie ClusterReady:

   kubectl edit dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       --namespace DB_CLUSTER_NAMESPACE \
       --subresource=status
   

6. Prüfen Sie, ob der AlloyDB Omni-Operator die Stand-by-Instanz abgleicht und die DBCluster-Ressource in die Phase DBClusterReady zurückgibt:

   kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME \
       --namespace DB_CLUSTER_NAMESPACE
   

Speicherprobleme beheben

In diesen Abschnitten wird beschrieben, wie Sie Speicherprobleme beheben.

Heap-Dump ausführen und erstellen

Aktivieren Sie diese Funktion nur zur Fehlerbehebung. Denken Sie daran, die Option danach wieder zu deaktivieren.

So erstellen Sie einen Heap-Dump:

1. Ändern Sie die Operatorbereitstellung im Namespace alloydb-omni-system mit dem Namen fleet-controller-manager und local-controller-manager.
2. Fügen Sie dem Pod --pprof-address=:8642 oder einem anderen verfügbaren Port das folgende Argument hinzu.
3. Warten Sie, bis der Controller-Pod neu gestartet wurde.

4. Leiten Sie den vorherigen Port weiter. Beispiel:

   kubectl port-forward FLEET_CONTROLLER_MANAGER_POD_NAME -n alloydb-omni-system 8642:8642
   

5. Führen Sie in einem anderen Terminal go tool pprof http://localhost:8642/debug/pprof/heap aus. Ändern Sie den Port so, dass er mit dem vorherigen Port übereinstimmt, wenn Sie 8642 nicht verwenden.

6. Stellen Sie eine Verbindung zur Adresse her und führen Sie Befehle zur Fehlerbehebung aus. Beispiel: top.

7. Machen Sie nach Abschluss der Fehlerbehebung Schritt 1 rückgängig, indem Sie das Argument entfernen und warten, bis der Pod neu gestartet wurde.

Anzahl der Ressourcen ermitteln, die der Operator überwacht

Führen Sie die folgenden Befehle aus, um die verwendeten Ressourcen zu ermitteln:

kubectl get backuprepositories -A  | wc -l
kubectl get failovers -A  | wc -l
kubectl get instancebackupplans -A  | wc -l
kubectl get instancebackups -A  | wc -l
kubectl get instancerestores -A  | wc -l
kubectl get instances -A  | wc -l
kubectl get instanceswitchovers -A  | wc -l
kubectl get lrojobs -A  | wc -l
kubectl get replicationconfigs -A  | wc -l
kubectl get sidecars -A  | wc -l
kubectl get deployments -A  | wc -l
kubectl get statefulsets -A  | wc -l
kubectl get certificates.cert-manager.io -A  | wc -l
kubectl get issuers.cert-manager.io -A  | wc -l
kubectl get configmaps -A  | wc -l
kubectl get persistentvolumeclaims -A  | wc -l
kubectl get persistentvolumes -A  | wc -l
kubectl get pods -A  | wc -l
kubectl get secrets -A  | wc -l
kubectl get services -A  | wc -l
kubectl get storageclasses.storage.k8s.io -A  | wc -l

Wenn die Anzahl der Secrets beispielsweise hoch ist, kann dies zu einem OOM-Fehler (Out Of Memory) führen.

kubectl get secrets -A | wc -l

Erweiterte HA-Fehlerbehebung

In diesem Abschnitt werden Ressourcen aufgeführt, die interne Implementierungen sind. Diese können sich jederzeit ändern und es gibt keine Verpflichtungen zur Abwärtskompatibilität. Wenden Sie manuelle Korrekturen nur auf Probleme in Nicht-Produktionsdatenbanken an. Diese Schritte können dazu führen, dass die Datenbank nicht mehr wiederhergestellt werden kann.

Die Einrichtung der AlloyDB Omni-Hochverfügbarkeit umfasst drei Phasen:

1. Richten Sie die primäre Instanz so ein, dass sie eine Verbindung von der Standby-Instanz empfängt.
2. Initialisieren Sie die Stand-by-Instanz und verbinden Sie sie mit der primären Instanz.
3. Legen Sie die primären Einstellungen fest, um die Verbindung synchron zu machen.

Schritt 2 ist in der Regel der langsamste. Je nach Größe der Datenbank kann dies mehrere Stunden dauern.

An jede replizierende Instanz sollte ein replicationconfig angehängt sein. Beispiel:

kubectl get replicationconfigs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

Beispielausgabe:

NAME                 PARENT     TYPE       ROLE         READY   HEALTHY   SYNC_U   SYNC_D   SLOT_LOG   SLOT_REPLAY
cd58-adb--58ea-adb   cd58-adb   Physical   Upstream     True    True      true
ds-58ea-adb          58ea-adb   Physical   Downstream   True    True               true

Die Spezifikation der Replikationskonfiguration gibt die beabsichtigten Einstellungen an, während der Status den tatsächlichen Status widerspiegelt, der aus der Datenbank gelesen wird. Wenn die Spezifikation und der Status nicht übereinstimmen, versucht der Controller weiterhin, die Änderung anzuwenden, oder es liegt ein Fehler vor, der verhindert, dass die Änderung angewendet wird. Dies würde sich in den Statusfeldern widerspiegeln.

Standby-Jobs

Es sollte zwei Sätze interner Jobs geben, die den Workflow eines Stand-by-Geräts verfolgen:

• createstandbyjobs.alloydbomni.internal.dbadmin.goog
• deletestandbyjobs.alloydbomni.internal.dbadmin.goog

Wenn die Einrichtung hängen bleibt, sehen Sie sich die Jobs im Zusammenhang mit dem Datenbankcluster (DBC) an. Der Job enthält möglicherweise Fehlermeldungen, die den Status der Einrichtung erklären. Jobs werden einige Zeit nach Abschluss automatisch bereinigt. Wenn keine Jobs ausgeführt werden, werden möglicherweise keine Jobs angezeigt.

kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

Die Ausgabe sieht etwa so aus:

apiVersion: alloydbomni.dbadmin.gdc.goog/v1
  kind: CreateStandbyJob
  metadata:
    creationTimestamp: "2024-11-05T03:34:26Z"
    finalizers:
    -   createstandbyjob.dbadmin.goog/finalizer
    generation: 1804
    labels:
      dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
    name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
    namespace: db
    resourceVersion: "11819071"
    uid: 1f24cedf-b326-422f-9405-c96c8720cd90
  spec:
    attempt: 3
    cleanup: false
    currentStep: SetupSynchronous
    currentStepTime: "2024-11-05T03:45:31Z"
    metadata:
      dbc: foo-ha-alloydb1-clone1
      primaryInstance: ac00-foo-ha-alloydb1-clone1
      retryError: 'etcdserver: leader changed'
      standbyInstance: 6036-foo-ha-alloydb1-clone1
    requeueTime: "2024-11-05T18:33:03Z"
    startTime: "2024-11-05T03:36:56Z"

Primäre Bestätigung

Als Erstes müssen Sie prüfen, ob die primäre Instanz richtig eingerichtet ist. Für jeden Stand-by-Server sollte ein Replikationsprofil vorhanden sein. Wenn isSynchronous in der Spezifikation und im Status „true“ ist, sollte die Einrichtung abgeschlossen sein. Wenn isSynchronous in der Spezifikation und im Status „false“ ist, wurde Schritt 3 noch nicht erreicht. Sehen Sie sich die Standby-Jobs an, um zu prüfen, ob Jobs ausgeführt werden und ob Fehlermeldungen vorliegen.

  replication:
    profiles:
    -   isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      password:
        name: ha-rep-pw-dbcluster-sample
        namespace: default
      passwordResourceVersion: "896080"
      role: Upstream
      type: Physical
      username: alloydbreplica

Prüfen Sie, ob die Annotation disableHealthcheck „false“ ist. Sie sollte nur während eines Failovers oder Switchovers deaktiviert werden.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Abfragen

Melden Sie sich als Administrator alloydbadmin in der Datenbank an, um zu prüfen, ob die Ressourcen im Datenbank-Pod richtig eingerichtet sind. Führen Sie dann die folgenden Abfragen aus:

Replikationsslot

\x on
select * from pg_replication_slots;

-[ RECORD 1 ]-------+---------------------------------------------
slot_name           | d85d_dbcluster_sample
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | t
active_pid          | 250
xmin                | 16318
catalog_xmin        |
restart_lsn         | 0/CA657F0
confirmed_flush_lsn |
wal_status          | reserved
safe_wal_size       |
two_phase           | f

Ein guter Zustand ist das Vorhandensein eines Replikationsslots mit demselben Namen wie die Stand-by-Instanz. Wenn kein Replikations-Slot vorhanden ist, wurde der erste Einrichtungsschritt nicht erfolgreich abgeschlossen.

Wenn active nicht t (true) ist, bedeutet das, dass die Standby-Instanz aus irgendeinem Grund keine Verbindung herstellt (Netzwerk, Standby-Instanz schließt die Einrichtung nicht ab usw.) und das Debugging wahrscheinlich auf der Standby-Seite fortgesetzt werden muss.

Replikationsstatistiken

\x on
select * from pg_stat_replication;

-[ RECORD 1 ]----+----------------------------------------------------------------
pid              | 250
usesysid         | 16385
usename          | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr      | 10.54.79.196
client_hostname  | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port      | 24914
backend_start    | 2024-10-30 21:44:26.408261+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/CA64DA8
write_lsn        | 0/CA64DA8
flush_lsn        | 0/CA64DA8
replay_lsn       | 0/CA64DA8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 2
sync_state       | sync
reply_time       | 2024-11-04 22:08:04.370838+00

Wenn diese nicht vorhanden ist, besteht keine aktive Verbindung. Der sync_state sollte sync lauten. Wenn der Wert nicht sync ist, wurde der letzte Schritt der Einrichtung nicht abgeschlossen. Weitere Details finden Sie in den Logs/Jobs.

Stand-by-Überprüfung

Die Standby-Instanz sollte ein Replikationsprofil haben, das mit dem Profil der primären Instanz übereinstimmt:

  replication:
    profiles:
    -   host: 10.54.79.210
      isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      passwordResourceVersion: "896080"
      port: 5432
      role: Downstream
      type: Physical
      username: alloydbreplica

Wenn keine Verbindung von der Standby- zur primären Instanz besteht, gibt es zwei gängige Möglichkeiten:

1. Die Standby-Instanz wird noch eingerichtet.
2. Beim Einrichten oder Verbinden der Standby-Datenbank tritt ein Fehler auf.

Wenn Sie prüfen möchten, ob Option 1 zutrifft, rufen Sie die Logs des Datenbank-Pods ab und suchen Sie nach Logberichten mit dem Namen dbdaemon/setupPhysicalReplicationDownstream. Im Folgenden finden Sie Beispiele für erfolgreiche Einrichtungslogs:

I1104 22:42:42.604871     103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590     103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403     103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440     103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749     103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783     103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565     103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621     103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689     103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838     103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732     103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"

Wenn ein Verbindungsfehler auftritt, prüfen Sie die DB-Pod-Logs sowie die Logdatei in der Datenbank unter /obs/diagnostic/postgresql.log, um zu sehen, welcher Fehler beim Verbindungsaufbau auftritt. Ein häufiger Fehler ist, dass keine Netzwerkverbindung zwischen dem Standby- und dem primären System besteht.

Manuelle Korrekturen

Die einfachste Möglichkeit, HA-Probleme zu beheben, besteht darin, HA zu deaktivieren und dann wieder zu aktivieren. Setzen Sie dazu numberOfStandbys auf 0 und dann auf die gewünschte Anzahl zurück. Wenn Stand-by-Instanzen deaktiviert bleiben, führen Sie die folgenden Schritte aus, um die Hochverfügbarkeitseinrichtung manuell zurückzusetzen, sodass sie leer ist:

1. Löschen Sie die Stand‑by-Instanzen manuell.

2. Stellen Sie eine Verbindung zur primären Datenbank her. Fragen Sie die aktuellen Replikationsslots ab und löschen Sie alle Replikationsslots von Stand-by-Instanzen, die Sie löschen möchten:

   select pg_drop_replication_slot('REPLICATION_SLOT_NAME');
   

3. Löschen Sie alle Replikationsprofile aus der primären Instanz, die Sie löschen möchten.

Wenn eine Instanz vor Kurzem nicht abgeglichen wurde, können Sie den Wert der Annotation forceReconcile bearbeiten. Legen Sie einen beliebigen numerischen Wert fest. Das ist der Zeitstempel der letzten Aktualisierung der Annotation. Der einzige Zweck dieser Annotation besteht darin, ein Feld bereitzustellen, das wir aktualisieren können, um einen neuen Abgleich zu erzwingen.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Wenn eine DBCluster-Ressource in DBClusterFailoverInProgress, DBClusterSwitchoverInProgress, DBClusterFailoverRollbackFailed oder DBClusterSwitchoverRollbackFailed hängen bleibt, weil die primäre Instanz mit PG_VERSION.disabled-Dateien isoliert ist, finden Sie weitere Informationen unter Datenbankcluster bleibt in einem Failover- oder Switchover-Zustand hängen.

Datenbank-Engine- und Audit-Logs erfassen

Die Datenbank-Engine-Logs und Audit-Logs sind als Dateien im Datenbank-Pod verfügbar (erfordert Root-Zugriff):

• obs/diagnostic/postgresql.log
• obs/diagnostic/postgresql.audit

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE ${DB_POD} -it -- /bin/bash

Wenn Sie mit dem Datenbankcontainer verbunden sind:

ls -l /obs/diagnostic/

Beispielausgabe:

drwx--S--- 2 postgres postgres    4096 Aug 13 10:22 archive
-rw------- 1 postgres postgres  256050 Aug 13 13:25 postgresql.internal
-rw------- 1 postgres postgres 1594799 Aug 13 13:25 postgresql.log

Datenbank- und Datenbank-Pod-Messwerte erfassen

Der AlloyDB Omni-Operator bietet eine Reihe von grundlegenden Messwerten für die AlloyDB Omni-Engine und den Pod, auf dem sie gehostet wird. Die Messwerte sind als Prometheus-Endpunkte an Port 9187 verfügbar. Für den Zugriff auf die Endpunkte müssen Sie den Pod-Namen für den Datenbank-Pod mithilfe des DBCluster-Labels identifizieren und die Portweiterleitung so starten:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward -n DB_CLUSTER_NAMESPACE ${DB_POD} 9187:9187

Auf Datenbank-Pod-Messwerte zugreifen

In einem anderen Terminal:

curl http://localhost:9187/metrics | grep HELP

Weitere Informationen zum Monitoring finden Sie unter AlloyDB Omni überwachen.

Sie können Prometheus auch so konfigurieren, dass die Messwerte in Ihrem Kubernetes-Cluster extrahiert werden. Weitere Informationen finden Sie in der Prometheus-Konfiguration für die Kubernetes-Service Discovery.