Risolvere i problemi relativi all'operatore AlloyDB Omni Kubernetes

Select a documentation version:

Questa pagina mostra come risolvere i problemi relativi all'operatore Kubernetes di AlloyDB Omni.

Raccogliere informazioni di debug

Queste sezioni descrivono come raccogliere log e configurazioni per il debug.

Recuperare i log dai pod dell'operatore

Per recuperare i log dai pod dell'operatore, esegui questi comandi:

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

Recuperare i log dei pod del database

Per recuperare i log dei pod del database, esegui questi comandi:

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

I seguenti log sono esempi di controlli dell'integrità del database riusciti:

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"

Recuperare il file postgresql.log

Per recuperare il file postgresql.log, esegui questo comando:

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

Recuperare il file YAML DBInstance

Per recuperare il file YAML DBInstance, esegui questo comando:

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

Recuperare configurazioni e log per scenari HA

Per recuperare configurazioni e log specifici per gli scenari di alta affidabilità (HA), esegui questi comandi:

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

Recuperare gli stati di pod e STS

Per recuperare gli stati di pod e StatefulSet (STS), esegui questi comandi:

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

Identificare gli errori

Queste sezioni descrivono come identificare gli errori.

Cercare lo stato di errore e i codici di errore

Per identificare il codice di errore, controlla il file YAML DBCluster nello stato. Per ulteriori informazioni, consulta la documentazione sui codici di errore.

Per recuperare il file YAML DBCluster, esegui questo comando:

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

Cerca criticalIncidents. Questa sezione contiene il codice di errore e un'analisi dello stack.

Di seguito sono riportati esempi di 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'

Puoi anche recuperare lo stato estraendo campi specifici in formato JSON:

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

L'output è simile al seguente:

[
  {
    "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"
      }
    ]
  }
]

Se il messaggio di errore si riferisce al pod del database, controlla le istanze e le risorse dei pod nello stesso spazio dei nomi:

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

Risolvere gli errori di emissione dei certificati in cert-manager

L'operatore AlloyDB Omni utilizza cert-manager per eseguire il provisioning dei certificati Transport Layer Security (TLS) per l'operatore e i cluster di database. Nelle versioni 1.21.2 e precedenti di cert-manager, una race condition nota (problema di cert-manager n. 6331) potrebbe causare l'errore di emissione dei certificati e l'inserimento di un backoff di un'ora per i nuovi tentativi.

Sintomi

Quando si verifica questo problema, potresti notare i seguenti sintomi:

  • Una risorsa DBCluster rimane nella fase DBClusterWaitingForCertificate, e la creazione o l'upgrade del cluster di database va in timeout.
  • L'installazione Helm dell'operatore AlloyDB Omni non riesce perché una risorsa Certificate, come local-serving-cert nello spazio dei nomi alloydb-omni-system, non è pronta.
  • Le condizioni di stato di una risorsa Certificate includono il messaggio CSR not signed by referenced private key con il motivo Failed o ErrorKeyMatch.

Per trovare le risorse Certificate interessate da questo problema, esegui questo comando:

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"

L'output elenca lo spazio dei nomi, il nome e i messaggi delle condizioni di stato di ogni risorsa Certificate interessata. Se visualizzi una risorsa Certificate interessata in formato YAML, il relativo campo status è simile al seguente:

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

Soluzione alternativa

Per evitare conflitti di aggiornamento del controller e ridurre il ritardo dei nuovi tentativi per le richieste di certificati non riuscite da un'ora a 15 secondi, esegui l'upgrade di cert-manager con il feature gate ServerSideApply e le durate di backoff ridotte:

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}"

Sostituisci CERT_MANAGER_VERSION con la versione di cert-manager installata nel cluster Kubernetes, ad esempio v1.21.2. Per trovare la versione installata, esegui il comando helm list --namespace cert-manager. Ad esempio, v1.12.2.

Dopo il riavvio del controller cert-manager, verifica che tutti i certificati mostrino True nella colonna READY:

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

Se l'installazione dell'operatore AlloyDB Omni non è riuscita a causa di questo problema, esegui di nuovo l'installazione.

Eseguire il debug dei problemi di memoria

Queste sezioni descrivono come eseguire il debug dei problemi di memoria.

Eseguire e acquisire un heapdump

Attiva questa funzionalità solo per la risoluzione dei problemi. Ricorda di disattivarla in seguito.

Per acquisire un heapdump, completa questi passaggi:

  1. Modifica il deployment dell'operatore nello spazio dei nomi alloydb-omni-system con i nomi fleet-controller-manager e local-controller-manager.
  2. Aggiungi il seguente argomento al pod --pprof-address=:8642 o a qualsiasi altra porta disponibile.
  3. Attendi il riavvio del pod del controller.

  4. Esegui il port forwarding della porta precedente. Ad esempio:

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

  5. In un altro terminale, esegui go tool pprof http://localhost:8642/debug/pprof/heap. Se non utilizzi 8642, modifica la porta in modo che corrisponda alla porta precedente.

  6. Connettiti all'indirizzo ed esegui i comandi per la risoluzione dei problemi. Ad esempio: top.

  7. Al termine della risoluzione dei problemi, annulla il passaggio 1 rimuovendo l'argomento e attendendo il riavvio del pod.

Determinare il numero di risorse monitorate dall'operatore

Per comprendere le risorse in uso, esegui questi comandi:

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

Ad esempio, se il numero di secret è elevato, può verificarsi un errore di memoria insufficiente (OOM).

kubectl get secrets -A | wc -l

Debug avanzato di HA

Questa sezione fa riferimento a risorse che sono implementazioni interne. Queste sono soggette a modifiche in qualsiasi momento e non hanno impegni di compatibilità con le versioni precedenti. Applica le correzioni manuali ai problemi solo sui database non di produzione. Questi passaggi potrebbero rendere il database non recuperabile.

La configurazione HA di AlloyDB Omni prevede tre fasi:

  1. Configura l'istanza principale in modo che riceva una connessione dall'istanza di standby.
  2. Inizializza l'istanza di standby e connettila all'istanza principale.
  3. Imposta le impostazioni principali per rendere sincrona la connessione.

Il passaggio 2 è in genere il più lento. A seconda delle dimensioni del database, potrebbe richiedere diverse ore.

Ogni istanza di replica deve avere un replicationconfig collegato. Ad esempio:

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

Output di esempio:

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

La specifica della configurazione della replica indica le impostazioni previste, mentre lo stato riflette lo stato effettivo letto dal database. Se esiste una mancata corrispondenza tra la specifica e lo stato, il controller sta ancora tentando di applicare la modifica oppure si è verificato un errore che impedisce l'applicazione della modifica. Questo si rifletterà nei campi di stato.

Job di standby

Dovrebbero essere presenti due set di job interni che tengono traccia del flusso di lavoro di un'istanza di standby:

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

Se la configurazione sembra bloccata, visualizza i job relativi al cluster di database (DBC). Il job potrebbe contenere messaggi di errore che spiegano lo stato della configurazione. I job vengono puliti automaticamente dopo un po' di tempo dal completamento, quindi potresti non visualizzare alcun job se non ce ne sono in corso.

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

L'output è simile al seguente:

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"

Verifica principale

La prima cosa da verificare è che l'istanza principale sia configurata correttamente. Dovrebbe essere presente un profilo di replica per ogni istanza di standby. Se isSynchronous è true nella specifica e nello stato, la configurazione dovrebbe essere completata. Se isSynchronous è false nella specifica e nello stato, significa che non è ancora stato raggiunto il passaggio 3. Visualizza i job di standby per verificare se sono in esecuzione e se contengono messaggi di errore.

  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

Verifica che l'annotazione disableHealthcheck sia false. È progettata per essere disattivata solo durante un failover o uno switchover.

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"

Query

Per verificare che le risorse nel pod DB siano configurate correttamente, accedi al database come utente amministratore alloydbadmin. Quindi, esegui le seguenti query:

Slot di replica

\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

Uno stato corretto è la presenza di uno slot di replica con lo stesso nome dell'istanza in standby. L'assenza di uno slot di replica indica che il primo passaggio di configurazione non è stato completato correttamente.

Se active non è t (true), significa che l'istanza di standby non si connette per qualche motivo (rete, configurazione di standby non completata e così via) e probabilmente il debug dovrà continuare sul lato di standby.

Statistiche di replica

\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

Se non esiste, significa che non esiste una connessione attiva. sync_state deve essere sync. Se non è sync, significa che l'ultimo passaggio della configurazione non è stato completato. La visualizzazione dei log / job dovrebbe fornire maggiori dettagli.

Verifica di standby

L'istanza di standby deve avere un profilo di replica che corrisponda allo stesso profilo dell'istanza principale:

  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

Se non esiste una connessione dall'istanza di standby all'istanza principale, esistono due possibilità comuni:

  1. L'istanza di standby è ancora in fase di configurazione.
  2. L'istanza di standby riceve un errore durante la configurazione o il tentativo di connessione.

Per verificare se si sta verificando l'opzione 1, recupera i log dei pod del database e cerca le istruzioni di log denominate dbdaemon/setupPhysicalReplicationDownstream. Di seguito sono riportati esempi di log di configurazione riusciti:

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"

Se si verifica un errore di connessione, controlla i log dei pod DB e il file di log sul database all'indirizzo /obs/diagnostic/postgresql.log e verifica qual è l'errore durante il tentativo di connessione. Un errore comune è che non esiste una connettività di rete tra l'istanza di standby e l'istanza principale.

Correzioni manuali

Il modo più semplice per risolvere i problemi di HA è disattivare e poi riattivare HA impostando numberOfStandbys su 0 e poi reimpostandolo sul numero desiderato. Se le istanze di standby rimangono disattivate, segui questi passaggi per reimpostare manualmente la configurazione HA in modo che sia vuota:

  1. Elimina manualmente le istanze in standby.

  2. Connettiti al database principale. Esegui una query sugli slot di replica attuali ed elimina gli slot di replica delle istanze di standby che vuoi eliminare:

    select pg_drop_replication_slot('REPLICATION_SLOT_NAME');

  3. Elimina i profili di replica dall'istanza principale che vuoi eliminare.

Se una riconciliazione di un'istanza non è stata eseguita di recente, puoi modificare il valore dell'annotazione forceReconcile. Imposta un valore numerico qualsiasi, ovvero il timestamp dell'ultimo aggiornamento dell'annotazione. L'unico scopo di questa annotazione è fornire un campo che possiamo aggiornare per forzare una nuova riconciliazione.

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"

Raccogliere i log motore del database e gli audit log

I log motore del database e gli audit log sono disponibili come file all'interno del pod del database (che richiede l'accesso root):

  • 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

Quando ti connetti al container del database:

ls -l /obs/diagnostic/

Output di esempio:

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

Raccogliere le metriche dei pod del database e del database

L'operatore AlloyDB Omni fornisce un insieme di metriche di base per il motore AlloyDB Omni e il pod che lo ospita. Le metriche sono disponibili come endpoint Prometheus sulla porta 9187. Per accedere agli endpoint, devi identificare il nome del pod per il pod del database utilizzando l'etichetta DBCluster e avviare il port forwarding come segue:

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

Accedere alle metriche dei pod del database

In un altro terminale:

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

Per ulteriori informazioni sul monitoraggio, consulta Monitorare AlloyDB Omni.

Puoi anche configurare Prometheus per estrarre le metriche nel cluster Kubernetes. Per i dettagli, consulta la configurazione di Service Discovery di Kubernetes di Prometheus.