AlloyDB Omni Kubernetes 운영자 문제 해결

문서 버전을 선택합니다.

이 페이지에서는 AlloyDB Omni Kubernetes 연산자 관련 문제를 해결하는 방법을 보여줍니다.

디버깅 정보 수집

이 섹션에서는 디버깅을 위해 로그와 구성을 수집하는 방법을 설명합니다.

연산자 포드에서 로그 가져오기

연산자 포드에서 로그를 가져오려면 다음 명령어를 실행합니다.

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

데이터베이스 포드 로그 가져오기

데이터베이스 포드 로그를 가져오려면 다음 명령어를 실행합니다.

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

다음 로그는 성공적인 데이터베이스 상태 점검 예시입니다.

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 가져오기

postgresql.log를 가져오려면 다음 명령어를 실행합니다.

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 파일 가져오기

DBInstance YAML 파일을 가져오려면 다음 명령어를 실행합니다.

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

HA 시나리오용 구성 및 로그 가져오기

고가용성(HA) 시나리오와 관련된 구성 및 로그를 가져오려면 다음 명령어를 실행합니다.

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

포드 및 STS 상태 가져오기

포드 및 StatefulSet(STS) 상태를 가져오려면 다음 명령어를 실행합니다.

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

오류 식별하기

이 섹션에서는 오류를 식별하는 방법을 설명합니다.

오류 상태 및 오류 코드 확인

오류 코드를 확인하려면 DBCluster YAML 파일의 상태 항목을 확인하세요. 자세한 내용은 오류 코드 문서를 참조하세요.

DBCluster YAML 파일을 가져오려면 다음 명령어를 실행합니다.

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

criticalIncidents항목을 확인합니다 이 섹션에는 오류 코드와 스택 트레이스가 포함되어 있습니다.

다음은 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'

JSON 형식으로 특정 필드를 추출하여 상태를 가져올 수도 있습니다.

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

출력은 다음과 비슷합니다.

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

오류 메시지가 데이터베이스 포드를 참조하는 경우 동일한 네임스페이스 내 인스턴스와 포드 리소스를 확인합니다.

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

메모리 문제 디버그

이 섹션에서는 메모리 문제를 디버그하는 방법을 설명합니다.

heapdump 실행 및 수집

이 기능은 문제 해결 목적으로만 사용 설정하세요. 완료 후에는 반드시 사용 중지해야 합니다.

heapdump를 수집하려면 다음 단계를 완료하세요.

  1. alloydb-omni-system 네임스페이스에서 fleet-controller-manager 및 local-controller-manager라는 이름의 연산자 배포를 수정합니다.
  2. 포드에 --pprof-address=:8642 인수를 추가합니다. 또는 다른 사용 가능한 포트를 지정할 수도 있습니다.
  3. 컨트롤러 포드가 다시 시작될 때까지 기다립니다.

  4. 앞서 지정한 포트를 포트 전달합니다. 예를 들면 다음과 같습니다.

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

  5. 다른 터미널에서 go tool pprof http://localhost:8642/debug/pprof/heap을 실행합니다. 8642가 아닌 다른 포트를 사용했다면 해당 포트로 변경하세요.

  6. 해당 주소에 연결한 뒤 문제 해결 명령어를 실행합니다. 예를 들면 top입니다.

  7. 문제 해결을 마쳤으면, 1단계에서 추가한 인수를 삭제하고 포드가 다시 시작될 때까지 기다려 원래 상태로 되돌립니다.

연산자가 감시 중인 리소스 수 확인

사용 중인 리소스를 파악하려면 다음 명령어를 실행하세요.

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

예를 들어 보안 비밀 수가 많으면 메모리 부족(OOM) 오류가 발생할 수 있습니다.

kubectl get secrets -A | wc -l

고급 HA 디버깅

이 섹션에서는 내부 구현 리소스를 참조합니다. 이러한 리소스는 언제든지 변경될 수 있으며 이전 버전과의 호환성은 보장되지 않습니다. 비프로덕션 데이터베이스의 경우에만 문제에 수동으로 수정사항을 적용하세요. 이 단계는 데이터베이스를 복구 불가능한 상태로 만들 수 있습니다.

AlloyDB Omni HA 설정은 세 단계로 구성됩니다.

  1. 대기에서 연결을 수신하도록 기본을 설정합니다.
  2. 대기를 초기화하고 기본에 연결합니다.
  3. 연결이 동기화되도록 기본 설정을 조정합니다.

2단계는 일반적으로 가장 시간이 오래 걸립니다. 데이터베이스 크기에 따라 몇 시간이 걸릴 수 있습니다.

복제를 수행하는 각 인스턴스에는 replicationconfig가 연결되어 있어야 합니다. 예를 들면 다음과 같습니다.

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

출력 예시:

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

Replication Config의 사양은 의도된 설정을 나타내고 상태는 데이터베이스에서 읽은 실제 상태를 반영합니다. 사양과 상태가 일치하지 않으면 컨트롤러가 여전히 변경사항을 적용하려고 시도하고 있거나 변경사항이 적용되지 않도록 방해하는 오류가 존재할 수 있습니다. 이러한 상황은 상태 필드에 반영됩니다.

대기 작업

대기의 워크플로를 추적하는 내부 작업은 다음 두 가지 집합이 있어야 합니다.

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

설정이 멈춘 것처럼 보이면, 데이터베이스 클러스터(DBC)와 관련된 작업을 확인하세요. 해당 작업에는 현재 설정이 어떤 상태에 있는지 설명하는 오류 메시지가 포함되어 있을 수 있습니다. 작업은 완료된 후 일정 시간이 지나면 자동으로 정리되므로 현재 실행 중인 작업이 없다면 아무 작업도 표시되지 않을 수 있습니다.

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

출력은 다음과 비슷합니다.

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"

기본 확인

가장 먼저 확인해야 할 것은 기본 인스턴스가 올바르게 설정되었는지입니다. 각 대기 인스턴스에 대해 복제 프로필이 있어야 합니다. 사양과 상태에서 isSynchronous가 true이면 설정이 완료된 것입니다. 사양과 상태에서 isSynchronous가 false이면 아직 3단계에 도달하지 못한 상태입니다. 대기 작업을 확인하여 실행 중인 작업이 있는지, 오류 메시지가 있는지 확인하세요.

  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

disableHealthcheck 주석이 false인지 확인합니다. 이 값은 장애 조치 또는 전환 중일 때만 사용 중지하도록 설계되었습니다.

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"

쿼리

DB 포드의 리소스가 올바르게 설정되었는지 확인하려면 alloydbadmin 관리자로 데이터베이스에 로그인합니다. 그런 후 다음 쿼리를 실행합니다.

복제 슬롯

\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

양호한 상태는 대기 인스턴스와 이름이 동일한 복제 슬롯이 존재하는 경우입니다. 복제 슬롯이 없다는 것은 첫 번째 설정 단계가 성공적으로 완료되지 않았음을 의미합니다.

active가 t(true)가 아니라면 이는 대기가 어떤 이유로든 연결되지 않는다는 뜻입니다(예: 네트워킹 문제, 대기 설정 미완료 등). 이 경우 디버깅은 대기 측에서 계속 진행해야 할 가능성이 큽니다.

복제 통계

\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

이 항목이 존재하지 않는다면 활성 연결이 없다는 의미입니다. sync_state는 sync여야 합니다. sync가 아니라면 설정의 마지막 단계가 완료되지 않았다는 뜻입니다. 자세한 내용은 로그나 작업을 확인하면 알 수 있습니다.

대기 확인

대기는 기본과 동일한 복제 프로필을 가져야 합니다.

  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

대기가 기본에 연결하지 못한 경우 두 가지 일반적인 원인이 있습니다.

  1. 대기가 아직 설정 중입니다.
  2. 대기가 설정 중이거나 연결을 시도하는 과정에서 오류가 발생했습니다.

옵션 1이 발생하는지 확인하려면 데이터베이스 포드 로그를 확인하고 dbdaemon/setupPhysicalReplicationDownstream이라는 로그 구문을 찾으세요. 다음은 설정이 성공적으로 완료된 로그 예시입니다.

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"

연결 오류가 발생한 경우 DB 포드의 로그와 데이터베이스의 로그 파일 /obs/diagnostic/postgresql.log를 확인하여 연결 시 어떤 오류가 발생했는지 확인합니다. 일반적인 오류 중 하나는 대기와 기본 간에 네트워크 연결이 없다는 것입니다.

수동 수정

HA 문제를 해결하는 가장 쉬운 방법은 numberOfStandbys를 0으로 설정해 HA를 사용 중지한 뒤 원하는 개수로 다시 설정하여 HA를 다시 사용 설정하는 것입니다. 대기가 사용 중지된 상태에서 멈춰 있으면 다음 단계를 따라 수동으로 HA 설정을 재설정하여 비워야 합니다.

  1. 대기 인스턴스를 수동으로 삭제합니다.

  2. 기본 데이터베이스에 연결합니다. 현재 복제 슬롯을 쿼리한 후 삭제하려는 대기의 복제 슬롯을 삭제합니다.

    select pg_drop_replication_slot('REPLICATION_SLOT_NAME');

  3. 기본 인스턴스에서 삭제하려는 복제 프로필을 삭제합니다.

인스턴스가 최근에 조정되지 않았다면 forceReconcile 주석 값을 수정할 수 있습니다. 이 값을 임의의 숫자 값(해당 주석이 마지막으로 업데이트된 시점의 타임스탬프)으로 설정하세요. 이 주석의 유일한 목적은 업데이트 가능한 필드를 제공해 새로운 조정을 강제로 적용하는 것입니다.

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"

데이터베이스 엔진 및 감사 로그 수집

데이터베이스 엔진 로그와 감사 로그는 데이터베이스 포드 내부의 파일로 제공됩니다(루트 액세스 필요).

  • 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

데이터베이스 컨테이너에 연결된 경우:

ls -l /obs/diagnostic/

출력 예시:

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

데이터베이스 및 데이터베이스 포드 측정항목 수집

AlloyDB Omni 연산자는 AlloyDB Omni 엔진과 이를 호스팅하는 포드에 대한 기본 측정항목 집합을 제공합니다. 이 측정항목은 포트 9187에서 제공되는 Prometheus 엔드포인트로 통해 확인할 수 있습니다. 엔드포인트에 액세스하려면 DBCluster 라벨을 사용하여 데이터베이스 포드의 포드 이름을 식별하고 다음과 같이 포트 전달을 시작해야 합니다.

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

데이터베이스 포드 측정항목 액세스

다른 터미널에서 다음을 실행합니다.

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

모니터링에 대한 자세한 내용은 AlloyDB Omni 모니터링을 참조하세요.

Prometheus를 구성하여 Kubernetes 클러스터에서 측정항목을 스크래핑할 수도 있습니다. 자세한 내용은 Prometheus Kubernetes 서비스 검색 구성을 참조하세요.