디버깅 정보 수집
이 섹션에서는 디버깅을 위해 로그와 구성을 수집하는 방법을 설명합니다.
운영자 포드에서 로그 가져오기
운영자 포드에서 로그를 가져오려면 다음 명령어를 실행합니다.
kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system
데이터베이스 포드 로그 가져오기
데이터베이스 포드 로그를 가져오려면 다음 명령어를 실행합니다.
kubectl logs al-<id-instance-name>-0 -n db
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster-name -c database -n db
다음 로그는 성공적인 데이터베이스 상태 점검의 예시입니다.
I1106 16:17:28.826188 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:28.826295 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:34.810447 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:34.834844 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:38.825843 30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:38.825959 30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
postgresql.log 가져오기
postgresql.log를 가져오려면 다음 명령어를 실행합니다.
kubectl exec -it al-id-instance-name-0 -n db -c database -- cat /obs/diagnostic/postgresql.log
DBInstance YAML 파일 가져오기
DBInstance YAML 파일을 가져오려면 다음 명령어를 실행합니다.
kubectl get dbclusters.a <dbcluster-name> -n db -o yaml
HA 시나리오의 구성 및 로그 가져오기
고가용성 (HA) 시나리오와 관련된 구성 및 로그를 가져오려면 다음 명령어를 실행합니다.
kubectl get replicationconfig -n <namespace>
kubectl get deletestandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get createstandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get failovers.alloydbomni.dbadmin.goog -n <namespace> -o yaml
포드 및 STS 상태 가져오기
포드 및 StatefulSet (STS) 상태를 가져오려면 다음 명령어를 실행합니다.
kubectl describe pod -n <namespace> <pod-name>
kubectl describe statefulset -n <namespace> al-<id-instance-name>
오류 식별
이 섹션에서는 오류를 식별하는 방법을 설명합니다.
오류 상태 및 오류 코드 확인
오류 코드를 확인하려면 상태 아래의 DBCluster YAML 파일을 확인하세요. 자세한 내용은 오류 코드 문서를 참고하세요.
DBCluster YAML 파일을 가져오려면 다음 명령어를 실행합니다.
kubectl get dbclusters.a <dbcluster-name> -n <dbcluster-namespace> -o 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 dbcluster.${DBTYPE:?} -n "${PROJECT:?}" "${DBCLUSTER:?}" -o json -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.a dbcluster_name -n dbcluster_namespace -o yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster_name -l alloydbomni.internal.dbadmin.goog/task-type=database -n dbcluster_namespace
메모리 문제 디버그
이 섹션에서는 메모리 문제를 디버그하는 방법을 설명합니다.
실행하고 힙 덤프 가져오기
문제 해결 목적으로만 이 기능을 사용 설정하세요. 나중에 사용 중지해야 합니다.
힙덤프를 생성하려면 다음 단계를 완료하세요.
alloydb-omni-system네임스페이스에서 이름이fleet-controller-manager및local-controller-manager인 연산자 배포를 수정합니다.- 포드
--pprof-address=:8642또는 사용 가능한 다른 포트에 다음 인수를 추가합니다. - 컨트롤러 포드가 다시 시작될 때까지 기다립니다.
앞의 포트를 포트 전달합니다. 예를 들면 다음과 같습니다.
kubectl port-forward -n alloydb-omni-system fleet-controller-manager-pod-name 8642:8642다른 터미널에서
go tool pprof http://localhost:8642/debug/pprof/heap를 실행합니다.8642을 사용하지 않는 경우 앞의 포트와 일치하도록 포트를 변경합니다.주소에 연결하고 문제 해결 명령어를 실행합니다. 예를 들면
top입니다.문제 해결을 완료한 후 인수를 삭제하고 포드가 다시 시작될 때까지 기다려 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 설정에는 세 단계가 있습니다.
- 대기에서 연결을 수신하도록 기본을 설정합니다.
- 대기 데이터베이스를 초기화하고 기본 데이터베이스에 연결합니다.
- 연결을 동기화하도록 기본 설정을 지정합니다.
2단계가 일반적으로 가장 느립니다. 데이터베이스 크기에 따라 몇 시간이 걸릴 수 있습니다.
각 인스턴스 복제 인스턴스에는 replicationconfig가 연결되어 있어야 합니다. 예를 들면 bash
❯ k get replicationconfigs.alloydbomni.internal.dbadmin.goog
NAME PARENT TYPE ROLE READY HEALTHY
9f47-dbcluster-sample--7576-dbcluster-sample 9f47-dbcluster-sample Physical Upstream True True
ds-7576-dbcluster-sample 7576-dbcluster-sample Physical Downstream True True입니다.
이 예에서는 다음과 같이 정의됩니다.
- 인스턴스
9f47-dbcluster-sample가 실제 업스트림으로 구성됩니다. - 인스턴스
7576-dbcluster-sample이 실제 다운스트림으로 구성됩니다.
복제 구성의 사양은 의도된 설정을 나타내고 상태는 데이터베이스에서 읽은 실제 상태를 반영합니다. 사양과 상태가 일치하지 않으면 컨트롤러가 여전히 변경사항을 적용하려고 시도하고 있거나 변경사항이 적용되지 않도록 하는 오류가 있는 것입니다. 이 내용은 상태 필드에 반영됩니다.
대기 작업
대기 모드의 워크플로를 추적하는 내부 작업이 두 세트 있어야 합니다.
createstandbyjobs.alloydbomni.internal.dbadmin.googdeletestandbyjobs.alloydbomni.internal.dbadmin.goog
설정이 멈춘 것 같으면 데이터베이스 클러스터(DBC)와 관련된 작업을 확인합니다. 작업에 설정이 어떤 상태인지 설명하는 오류 메시지가 있을 수 있습니다. 작업은 완료된 후 어느 정도 시간이 지나면 자동으로 정리되므로 진행 중인 작업이 없으면 작업이 표시되지 않을 수 있습니다.
k get createstandbyjob
출력은 다음과 비슷합니다.
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로 데이터베이스에 로그인합니다. 그런 다음 다음 쿼리를 실행합니다.
복제 슬롯
alloydbadmin=# 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가 참이 아니면 대기 모드가 어떤 이유로 연결되지 않는다는 의미입니다 (네트워킹, 대기 모드에서 설정 완료 안 됨 등). 대기 모드 측에서 디버깅을 계속해야 할 수 있습니다.
복제 통계
alloydbadmin=# 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이 발생하는지 확인하려면 데이터베이스 포드 로그를 가져와 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 설정을 수동으로 재설정하여 비워야 합니다.
- 대기 인스턴스를 수동으로 삭제합니다.
기본 데이터베이스에 연결합니다. 현재 복제 슬롯을 쿼리하고 삭제할 대기 복제본의 복제 슬롯을 삭제합니다.
select pg_drop_replication_slot('<replication_slot_name_here>');삭제하려는 기본 인스턴스에서 복제 프로필을 삭제합니다.
인스턴스가 최근에 조정되지 않은 경우 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.logobs/diagnostic/postgresql.audit
export NAMESPACE=dbcluster-namespace
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER} -l alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
kubectl exec -n ${NAMESPACE} ${DBPOD} -it -- /bin/bash
$ ls -la /obs/diagnostic/
-rw------- 1 postgres postgres 98438 Sep 25 20:15 postgresql.audit
-rw------- 1 postgres postgres 21405058 Sep 25 20:24 postgresql.log
데이터베이스 및 데이터베이스 포드 측정항목 수집
AlloyDB Omni 연산자는 AlloyDB Omni 엔진과 이를 호스팅하는 포드에 관한 기본 측정항목 집합을 제공합니다. 측정항목은 포트 9187에서 사용할 수 있는 Prometheus 엔드포인트로 제공됩니다. 엔드포인트에 액세스하려면 다음과 같이 DBCluster 및 task-type 라벨을 사용하여 데이터베이스 포드와 데이터베이스 모니터링 포드의 포드 이름을 식별해야 합니다.
export NAMESPACE=default
export DBCLUSTER=dbcluster-sample
export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
export MONITORINGPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=monitoring -o jsonpath='{.items[0].metadata.name}'`
AlloyDB Omni 데이터베이스 측정항목 액세스
kubectl port-forward -n ${NAMESPACE} ${MONITORINGPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
데이터베이스 포드 측정항목 액세스
kubectl port-forward -n ${NAMESPACE} ${DBPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP
Kubernetes 클러스터에서 측정항목을 스크래핑하도록 Prometheus를 구성할 수도 있습니다. 자세한 내용은 Prometheus Kubernetes 서비스 검색 구성을 참고하세요.