Fehlerbehebung beim AlloyDB Omni Kubernetes-Operator

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem AlloyDB Omni Kubernetes-Operator beheben.

Debugging-Informationen erfassen

In diesen Abschnitten wird beschrieben, wie Sie Logs und Konfigurationen zur 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 Systemdiagnosen der Datenbank:

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"

Die Datei postgresql.log abrufen

Führen Sie den folgenden Befehl aus, um die Datei 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

Die YAML-Datei DBInstance abrufen

Führen Sie den folgenden Befehl aus, um die YAML-Datei 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 Protokolle abzurufen, die speziell für Szenarien mit Hochverfügbarkeit (HA) gelten:

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 Pod- und StatefulSet-Status (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 finden.

Nach Fehlerstatus und Fehlercodes suchen

Prüfen Sie die YAML-Datei DBCluster unter dem Status, um den Fehlercode zu ermitteln. Weitere Informationen finden Sie in der Dokumentation zu Fehlercodes.

Führen Sie den folgenden Befehl aus, um die YAML-Datei 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.

Die folgenden Beispiele zeigen 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

Fehler bei der Zertifikatsausstellung in cert-manager beheben

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üher kann eine bekannte Race-Bedingung (cert-manager-Problem #6331) dazu führen, dass die Zertifikatsausstellung fehlschlägt und ein Backoff von einer Stunde für Wiederholungsversuche eintritt.

Symptome

Wenn dieses Problem auftritt, können folgende Symptome auftreten:

  • Eine DBCluster Ressource bleibt in der Phase DBClusterWaitingForCertificate, und die Erstellung oder Aktualisierung des Datenbankclusters überschreitet das Zeitlimit.
  • 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 Meldung 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 Statusmeldungen der einzelnen betroffenen Certificate-Ressourcen aufgeführt. Wenn Sie eine betroffene Certificate-Ressource im YAML-Format aufrufen, sieht das Feld status 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 der Controlleraktualisierung zu vermeiden und die Wiederholungsverzögerung für fehlgeschlagene Zertifikatsanfragen von einer Stunde auf 15 Sekunden zu reduzieren, führen Sie ein Upgrade von cert-manager mit dem Feature Gate ServerSideApply und reduzierten Backoff-Dauern durch:

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 CERT_MANAGER_VERSION durch 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. Beispiel: v1.12.2.

Nachdem der cert-manager-Controller neu gestartet wurde, prüfen Sie, ob in der Spalte READY für alle Zertifikate True angezeigt wird:

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

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

Arbeitsspeicherprobleme beheben

In diesen Abschnitten wird beschrieben, wie Sie Arbeitsspeicherprobleme beheben.

Heapdump ausführen und erstellen

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

So erstellen Sie einen Heapdump:

  1. Ändern Sie die Operatorbereitstellung im Namespace alloydb-omni-system mit dem Namen fleet-controller-manager und local-controller-manager.
  2. Fügen Sie das folgende Argument zum Pod --pprof-address=:8642 oder zu einem anderen verfügbaren Port 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 nicht 8642 verwenden.

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

  7. Nachdem Sie die Fehlerbehebung abgeschlossen haben, machen Sie 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 referenziert, die interne Implementierungen sind. Diese können jederzeit geändert werden und es gibt keine Zusagen 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 wiederhergestellt werden kann.

Die HA-Einrichtung von AlloyDB Omni besteht aus 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 Standby-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 er mehrere Stunden dauern.

Jede Instanz, die repliziert wird, muss eine replicationconfig haben. 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 wurde. Wenn es eine Diskrepanz zwischen der Spezifikation und dem Status gibt, versucht der Controller weiterhin, die Änderung anzuwenden, oder es liegt ein Fehler vor, der verhindert, dass die Änderung angewendet wird. Dies wird in den Statusfeldern widergespiegelt.

Standby-Jobs

Es sollten zwei Gruppen interner Jobs vorhanden sein, die den Workflow einer Standby-Instanz verfolgen:

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

Wenn die Einrichtung nicht voranzugehen scheint, rufen Sie die Jobs auf, die sich auf den Datenbankcluster (Database Cluster, DBC) beziehen. Der Job enthält möglicherweise Fehlermeldungen, die den Status der Einrichtung erläutern. Jobs werden einige Zeit nach Abschluss automatisch bereinigt. Wenn also keine Jobs ausgeführt werden, werden möglicherweise keine 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 Instanz überprüfen

Als Erstes müssen Sie prüfen, ob die primäre Instanz richtig eingerichtet ist. Für jede Standby-Instanz muss ein Replikationsprofil vorhanden sein. Wenn isSynchronous in der Spezifikation und im Status auf „true“ gesetzt ist, sollte die Einrichtung abgeschlossen sein. Wenn isSynchronous in der Spezifikation und im Status auf „false“ gesetzt ist, wurde Schritt 3 noch nicht erreicht. Rufen Sie die Standby-Jobs auf, um zu sehen, ob Jobs ausgeführt werden und ob Fehlermeldungen vorhanden sind.

  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 auf „false“ gesetzt 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 Administratornutzer 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. Das Fehlen eines Replikationsslots deutet darauf hin, dass der erste Einrichtungsschritt nicht erfolgreich abgeschlossen wurde.

Wenn active nicht t (true) ist, stellt die Standby-Instanz aus irgendeinem Grund keine Verbindung her (Netzwerk, Standby-Instanz schließt die Einrichtung nicht ab usw.). Die Fehlerbehebung muss wahrscheinlich auf der Standby-Seite fortgesetzt werden.

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 dies nicht vorhanden ist, gibt es keine aktive Verbindung. sync_state sollte sync sein. Wenn es nicht sync ist, wurde der letzte Einrichtungsschritt nicht abgeschlossen. Weitere Informationen finden Sie in den Logs / Jobs.

Standby-Instanz überprüfen

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-Instanz zur primären Instanz besteht, gibt es zwei häufige Möglichkeiten:

  1. Die Standby-Instanz wird noch eingerichtet.
  2. Bei der Einrichtung oder beim Verbindungsversuch der Standby-Instanz ist ein Fehler aufgetreten.

Prüfen Sie, ob Option 1 zutrifft. Rufen Sie dazu die Datenbank-Pod-Logs auf und suchen Sie nach Log-Anweisungen mit dem Namen dbdaemon/setupPhysicalReplicationDownstream. Die folgenden Beispiele zeigen Logs für eine erfolgreiche Einrichtung:

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 Datenbank-Pod-Logs sowie die Logdatei in der Datenbank unter /obs/diagnostic/postgresql.log und sehen Sie nach, welcher Fehler beim Verbindungsversuch auftritt. Ein häufiger Fehler ist, dass keine Netzwerkverbindung zwischen der Standby-Instanz und der primären Instanz besteht.

Manuelle Korrekturen

Die einfachste Möglichkeit, HA-Probleme zu beheben, besteht darin, HA zu deaktivieren und dann wieder zu aktivieren, indem Sie numberOfStandbys auf 0 setzen und dann auf die gewünschte Anzahl zurücksetzen. Wenn Standby-Instanzen nicht deaktiviert werden können, führen Sie die folgenden Schritte aus, um die HA-Einrichtung manuell auf leer zurückzusetzen:

  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 Standby-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 seit Kurzem nicht mehr abgeglichen wurde, können Sie den Wert der Annotation forceReconcile bearbeiten. Setzen Sie ihn auf einen beliebigen numerischen Wert, der dem Zeitstempel der letzten Aktualisierung dieser Annotation entspricht. 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"

Datenbank-Engine- und Audit-Logs erfassen

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

  • 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 eine Verbindung zum Datenbankcontainer besteht:

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 grundlegender Messwerte für die AlloyDB Omni-Engine und den Pod, auf dem sie gehostet wird. Die Messwerte sind als Prometheus-Endpunkte verfügbar, die über Port 9187 erreichbar sind. Um auf die Endpunkte zuzugreifen, müssen Sie den Pod-Namen für den Datenbank-Pod mit dem Label DBCluster ermitteln und die Portweiterleitung wie folgt 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 zur Überwachung finden Sie unter AlloyDB Omni überwachen.

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