Debugging-Informationen erfassen
In diesen Abschnitten wird beschrieben, wie Sie Logs und Konfigurationen für das Debugging erfassen.
Logs aus Operator-Pods abrufen
Führen Sie die folgenden Befehle aus, um Logs von den Operator-Pods abzurufen:
kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system > alloydb-omni-system-fleet-controller-manager.out
kubectl logs deployments/local-controller-manager -c 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"
postgresql.log abrufen
Führen Sie den folgenden Befehl aus, um den 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
DBInstance-YAML-Datei 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 abzurufen, die sich speziell auf Szenarien mit hoher Verfügbarkeit (High Availability, HA) beziehen:
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
Sehen Sie sich die DBCluster-YAML-Datei unter dem Status an, um den Fehlercode zu ermitteln. Weitere Informationen finden Sie in der Dokumentation zu Fehlercodes.
Führen Sie den folgenden Befehl aus, um die DBCluster-YAML-Datei abzurufen:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml
Achten Sie auf 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
Arbeitsspeicherprobleme beheben
In diesen Abschnitten wird beschrieben, wie Sie Speicherprobleme beheben.
Ausführen und Heap-Dump erstellen
Aktivieren Sie diese Funktion nur zur Fehlerbehebung. Denken Sie daran, die Funktion danach wieder zu deaktivieren.
So erstellen Sie einen Heapdump:
- Ändern Sie die Operatorbereitstellung im Namespace
alloydb-omni-systemmit dem Namenfleet-controller-managerundlocal-controller-manager. - Fügen Sie dem Pod
--pprof-address=:8642oder einem anderen verfügbaren Port das folgende Argument hinzu. - Warten Sie, bis der Controller-Pod neu gestartet wurde.
Leiten Sie den vorherigen Port weiter. Beispiel:
kubectl port-forward FLEET_CONTROLLER_MANAGER_POD_NAME -n alloydb-omni-system 8642:8642Führen Sie in einem anderen Terminal
go tool pprof http://localhost:8642/debug/pprof/heapaus. Ändern Sie den Port so, dass er mit dem vorherigen Port übereinstimmt, wenn Sie8642nicht verwenden.Stellen Sie eine Verbindung zur Adresse her und führen Sie Befehle zur Fehlerbehebung aus. Beispiel:
top.Nach Abschluss der Fehlerbehebung machen Sie Schritt 1 rückgängig, indem Sie das Argument entfernen und warten, bis der Pod neu gestartet wird.
Anzahl der Ressourcen ermitteln, die vom Operator überwacht werden
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 hoch ist, kann dies beispielsweise zu einem OOM-Fehler (Out Of Memory) führen.
kubectl get secrets -A | wc -l
Erweiterte HA-Fehlerbehebung
In diesem Abschnitt wird auf Ressourcen verwiesen, 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. Wenn Sie diese Schritte ausführen, kann die Datenbank möglicherweise nicht mehr wiederhergestellt werden.
Die Einrichtung von AlloyDB Omni HA erfolgt in drei Phasen:
- Richten Sie die primäre Instanz so ein, dass sie eine Verbindung von der Standby-Instanz empfängt.
- Initialisieren Sie die Standby-Instanz und stellen Sie eine Verbindung zur primären Instanz her.
- Legen Sie die primären Einstellungen fest, um die Verbindung synchron zu gestalten.
Schritt 2 dauert in der Regel am längsten. Je nach Größe der Datenbank kann dies mehrere Stunden dauern.
Jeder Instanz, die repliziert wird, sollte ein replicationconfig zugeordnet 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 Zustand 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 Gruppen interner Jobs geben, die den Workflow eines Standby-Geräts verfolgen:
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
Wenn die Einrichtung anscheinend nicht weitergeht, sehen Sie sich die Jobs an, die sich auf den Datenbankcluster (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 auch 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 Bestätigung
Prüfen Sie zuerst, ob die primäre Instanz richtig eingerichtet ist. Für jeden Standby-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 auf „false“ gesetzt ist, wurde Schritt 3 noch nicht erreicht. Sehen Sie sich die Standby-Jobs an, um festzustellen, 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 falsch 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
Um zu prüfen, ob die Ressourcen im DB-Pod richtig eingerichtet sind, melden Sie sich als Administratornutzer alloydbadmin in der Datenbank an. 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 Replikations-Slots mit demselben Namen wie die Standby-Instanz. Das Fehlen eines Replikations-Slots deutet darauf hin, dass der erste Einrichtungsschritt nicht erfolgreich abgeschlossen wurde.
Wenn active nicht t (wahr) ist, bedeutet das, dass die Stand-by-Verbindung aus irgendeinem Grund nicht hergestellt wird (Netzwerk, Stand-by-Einrichtung nicht abgeschlossen usw.). Die Fehlersuche muss wahrscheinlich auf der Stand-by-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 diese nicht vorhanden ist, besteht keine aktive Verbindung. Der sync_state sollte sync lauten. Wenn es nicht sync ist, wurde der letzte Schritt der Einrichtung nicht abgeschlossen. Weitere Informationen finden Sie in den Logs oder Jobs.
Stand-by-Überprüfung
Das Standby-System sollte ein Replikationsprofil haben, das mit dem Profil des primären Systems ü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 vom Standby- zum primären Knoten besteht, gibt es zwei häufige Möglichkeiten:
- Der Standby-Modus wird noch eingerichtet.
- Beim Einrichten oder Verbinden des Standby-Modus ist ein Fehler aufgetreten.
Um zu prüfen, ob Option 1 zutrifft, rufen Sie die Datenbank-Pod-Logs ab und suchen Sie nach Log-Anweisungen mit dem Namen dbdaemon/setupPhysicalReplicationDownstream. Hier sind Beispiele für Protokolle einer erfolgreichen 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 Logs des Datenbank-Pods sowie die Logdatei in der Datenbank unter /obs/diagnostic/postgresql.log, um die Fehlerursache zu ermitteln. Ein häufiger Fehler ist, dass keine Netzwerkverbindung zwischen dem Standby- und dem primären Gerät besteht.
Manuelle Korrekturen
Am einfachsten lassen sich HA-Probleme beheben, indem Sie HA deaktivieren und dann wieder aktivieren. Dazu setzen Sie numberOfStandbys auf 0 und dann auf die gewünschte Zahl. Wenn Stand-bys deaktiviert bleiben, führe die folgenden Schritte aus, um die HA-Einrichtung manuell zurückzusetzen:
- Löschen Sie die Standby-Instanzen manuell.
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');Löschen Sie alle Replikationsprofile aus der primären Instanz, die Sie löschen möchten.
Wenn eine Instanz in letzter Zeit nicht abgeglichen wurde, können Sie den Annotationswert forceReconcile bearbeiten. Legen Sie einen beliebigen numerischen Wert fest. Das ist der Zeitstempel der letzten Aktualisierung der Anmerkung. Der einzige Zweck dieser Anmerkung 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 (erfordert Root-Zugriff):
obs/diagnostic/postgresql.logobs/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
Messwerte für Datenbanken und Datenbank-Pods 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 auf Port 9187 verfügbar. Um auf die Endpunkte zuzugreifen, müssen Sie den Pod-Namen für den Datenbank-Pod mit dem Label „DBCluster“ ermitteln 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 erfasst werden. Weitere Informationen finden Sie unter Prometheus Kubernetes Service Discovery-Konfiguration.