Debugging-Informationen erfassen
In diesen Abschnitten wird beschrieben, wie Sie Logs und Konfigurationen für das Debugging 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 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
Logs von Datenbank-Pods abrufen
Führen Sie die folgenden Befehle aus, um Logs von Datenbank-Pods 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 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 DBInstance-YAML-Datei 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 speziell für Szenarien mit hoher Verfügbarkeit (High Availability, 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
Um den Fehlercode zu ermitteln, prüfen Sie die DBCluster-YAML-Datei unter dem Status. 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
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
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:
- Ändern Sie die Operatorbereitstellung im Namespace
alloydb-omni-systemmit dem Namenfleet-controller-managerundlocal-controller-manager. - Fügen Sie das folgende Argument zum Pod hinzu:
--pprof-address=:8642oder zu einem anderen verfügbaren Port. - 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 Sie nicht8642verwenden.Stellen Sie eine Verbindung zur Adresse her und führen Sie Befehle zur Fehlerbehebung aus. Beispiel:
top.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 beispielsweise die Anzahl der Secrets 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 erwähnt, die interne Implementierungen sind. Diese können jederzeit geändert werden 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 wiederhergestellt werden kann.
Die AlloyDB Omni-HA-Einrichtung besteht aus drei Phasen:
- Richten Sie die primäre Datenbank so ein, dass sie eine Verbindung von der Standby-Datenbank empfängt.
- Initialisieren Sie die Standby-Datenbank und verbinden Sie sie mit der primären Datenbank.
- 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.
Jeder Instanz, die repliziert wird, sollte eine 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 Zustand 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-Datenbank verfolgen:
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
Wenn die Einrichtung ins Stocken gerät, sehen Sie sich die Jobs an, 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 Überprüfung
Als Erstes müssen Sie prüfen, ob die primäre Datenbank richtig eingerichtet ist. Für jede Standby-Datenbank 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 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 Anmerkung 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
Um zu prüfen, ob die Ressourcen im Datenbank-Pod richtig eingerichtet sind, melden Sie sich als Administrator 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 Replikationsslots mit demselben Namen wie die Standby-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-Datenbank aus
irgendeinem Grund keine Verbindung her (Netzwerk, Standby-Datenbank 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 Details finden Sie in den Logs / Jobs.
Standby-Überprüfung
Die Standby-Datenbank sollte ein Replikationsprofil haben, das mit dem Profil der primären Datenbank ü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-Datenbank zur primären Datenbank besteht, gibt es zwei häufige Möglichkeiten:
- Die Standby-Datenbank wird noch eingerichtet.
- Bei der Einrichtung oder beim Verbindungsversuch der Standby-Datenbank 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. 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- und der primären Datenbank 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-Datenbanken deaktiviert bleiben, führen Sie 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-Datenbanken, 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 seit Kurzem nicht mehr abgeglichen wurde, können Sie den Wert der Anmerkung forceReconcile bearbeiten. Setzen Sie ihn auf einen beliebigen numerischen Wert, der dem Zeitstempel der letzten Aktualisierung dieser Anmerkung entspricht. 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 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 an Port 9187 verfügbar. Um auf die Endpunkte zuzugreifen, müssen Sie den Pod-Namen für den Datenbank-Pod mit dem DBCluster-Label 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-Dienstermittlung.