읽기 풀 쿼리 문제 해결

이 페이지에서는 PostgreSQL용 AlloyDB에서 읽기 풀 인스턴스에 전송하는 쿼리를 조사하고 디버그하는 기술을 설명합니다.

  • 읽기 풀의 구성 노드(IP 주소 포함)에 관한 자세한 목록을 확인합니다.
  • 디버깅을 위해 노드에 직접 연결
  • AlloyDB 로그를 검사하여 읽기 풀에 전송된 쿼리를 처리하는 특정 노드를 확인합니다.
  • 지정된 읽기 풀 노드의 모든 최근 활동에 관한 로그를 쿼리합니다.
  • 읽기 풀 노드와 연결된 Google Cloud 측정항목을 확인합니다.

이러한 기법을 함께 사용하면 읽기 풀에 대한 진단 및 디버깅 액세스 권한을 얻을 수 있습니다. 예를 들어 클러스터의 읽기 풀 중 하나가 장기 실행 쿼리를 처리하는 동안 비정상적인 양의 CPU를 사용하는 경우 이러한 기법을 사용하면 해당 쿼리를 처리하는 노드를 확인한 다음 해당 노드에 직접 연결하여 쿼리를 추가로 검사하거나 종료할 수 있습니다.

읽기 풀 노드의 세부정보 나열

일반적인 AlloyDB 사용 시에는 읽기 풀을 구성하는 노드의 ID 또는 주소를 알 필요가 없습니다. 하지만 필요한 경우 읽기 풀 인스턴스의 노드 목록을 볼 수 있습니다. 나열된 각 노드에는 후속 진단 및 디버깅에 유용한 다음 정보가 포함됩니다.

읽기 풀 노드의 내부 ID 문자열과 IP 주소를 보려면 인스턴스 세부정보 보기gcloud 관련 안내를 따르되 --view=FULL 명령줄 인수를 추가합니다.

gcloud

gcloud alloydb instances describe READ_POOL_ID \
 --region=REGION_ID \
 --cluster=CLUSTER_ID \
 --project=PROJECT_ID \
 --view=FULL

다음을 바꿉니다.

  • READ_POOL_ID: 읽기 풀의 ID입니다.
  • REGION_ID: 인스턴스의 리전 ID입니다.
  • CLUSTER_ID: 인스턴스 클러스터의 ID입니다.
  • PROJECT_ID: 인스턴스 프로젝트의 ID입니다.

출력에는 다음과 유사한 nodes 라벨이 지정된 섹션이 포함됩니다.

nodes:
- id: READ_POOL_INSTANCE_ID-edd4f6ed-hcfh
  ip: 10.90.80.57
  state: HEALTHY
  zoneId: us-central1-b
- id: READ_POOL_INSTANCE_ID-edd4f6ed-ldbm
  ip: 10.90.80.56
  state: HEALTHY
  zoneId: us-central1-c

각 항목의 idip 필드는 이 페이지에 설명된 다른 기법과 특히 관련이 있습니다.

  • ip 필드는 클러스터의 VPC 내 노드의 IP 주소를 표시합니다.

  • id 필드에는 노드의 전체 Google Cloud ID 문자열이 포함됩니다. 이 문자열의 마지막 4자만 노드의 로깅된 항목에 표시됩니다.

    예를 들어 이전 샘플 출력의 두 노드 중 첫 번째 노드와 관련된 로그 항목을 찾으려면 ID 문자열 hcfh를 사용하여 로그를 쿼리합니다.

노드에 직접 연결

노드의 IP 주소를 알면 PostgreSQL 서버에 직접 연결할 수 있습니다. 예를 들어 psql를 사용하여 클러스터의 VPC에 있는 VM에 연결하려면 psql 클라이언트 실행의 안내를 따르세요. 이 경우 읽기 풀 인스턴스의 IP 주소 대신 노드의 IP 주소를 제공합니다.

psql -h NODE_IP_ADDRESS -U USERNAME

로그에서 노드 활동 찾기

AlloyDB는 읽기 풀에서 처리하는 쿼리에 관한 로그 항목에 노드 ID를 포함합니다. 일반적으로 이러한 발견된 ID는 다음 두 가지 방법으로 사용할 수 있습니다.

  • 노드에 연결할 수 있도록 노드의 IP를 확인합니다.
  • 추가 로그 쿼리를 실행하여 노드의 최근 활동에 관해 자세히 알아봅니다.

알려진 쿼리를 처리하는 노드 확인

특정 읽기 풀이 장기 실행 쿼리를 처리하고 있음을 알고 있다면 로그 탐색기를 사용하여 해당 쿼리를 처리하는 특정 노드의 ID를 확인할 수 있습니다.

이 기법은 pgAudit 확장 프로그램을 사용 설정한 읽기 풀 인스턴스에서만 작동합니다.

  1. 로그 탐색기로 이동합니다.

    로그 탐색기로 이동

  2. 쿼리 빌더에서 쿼리 편집기 필드에 resource.labels.instance_id="READ_POOL_ID"를 추가하고 READ_POOL_ID을 읽기 풀 인스턴스의 이름으로 바꿉니다.

  3. 조사 중인 SQL 문을 전체 또는 일부로 쿼리 편집기 필드에 추가합니다. 예를 들면 select id from MyTable입니다. 이 입력은 대소문자를 구분하지 않습니다.

  4. 쿼리 실행을 클릭합니다.

  5. 로그 탐색기의 컨트롤을 사용하여 필요에 따라 쿼리를 조정하고 다시 실행하여 가장 관련성 높은 결과로 필터링합니다.

  6. 결과 목록에서 로그 항목을 클릭하여 표시를 펼칩니다.

  7. 항목의 펼쳐진 디스플레이에서 labels 필드를 클릭합니다.

  8. labels 아래에서 NODE_ID의 값을 확인합니다.

결과는 쿼리를 처리하는 노드의 4자리 식별자입니다.

로그 항목에 언급된 노드에 연결

기록된 활동을 기반으로 특정 노드의 PostgreSQL 서버에 직접 연결하려면 다음 단계를 따르세요.

  1. 로깅된 노드의 4자리 ID 문자열을 확인합니다. 이 ID는 로그 항목의 NODE_ID 필드에서 확인할 수 있습니다.

  2. 읽기 풀의 노드를 나열합니다.

  3. 이 목록에서 첫 번째 단계에서 확인한 4자리 문자로 끝나는 ID 문자열이 있는 노드를 찾습니다. 나열된 노드 중 일치하는 노드가 없을 수도 있습니다.

  4. 일치하는 노드를 찾으면 일치하는 IP 주소를 사용하여 해당 노드의 PostgreSQL 서버에 연결합니다.

    그렇지 않고 이전 단계에 나열된 읽기 풀의 노드 중 로깅된 노드와 일치하는 ID가 없는 경우 읽기 풀이 원래 로그 항목 이후 경과한 시간 동안 해당 노드를 지원 중단한 것입니다. 이는 노드 일시성에 관한 참고사항에 설명된 대로 AlloyDB 읽기 풀의 정상적인 동작입니다. 이 경우 해당 노드에 직접 연결할 수 없습니다.

노드의 PostgreSQL 서버에 연결하면 pg_stat_activity와 같은 표준 PostgreSQL 모니터링 기법을 사용하여 노드의 현재 프로세스를 자세히 조사하고 필요에 따라 조정할 수 있습니다.

노드에 관한 로그 항목 더보기

특정 ID의 노드에 관해 로깅된 최근 활동을 보려면 다음 단계를 따르세요.

  1. 로그 탐색기로 이동합니다.

    로그 탐색기로 이동

  2. 로그 탐색기 쿼리 빌더labels.NODE_ID=NODE_ID를 추가하고 NODE_ID를 노드의 4자리 ID 문자열로 바꿉니다.

  3. 쿼리 실행을 클릭하여 선택한 시간 범위 내 해당 노드의 모든 활동을 보거나 쿼리를 조정하여 더 세부적으로 필터링합니다.

  4. 검색 결과를 세분화하려면 필요한 경우 이전 단계를 반복합니다.

노드 측정항목 모니터링

AlloyDB 시스템 통계 대시보드에서 개별 노드와 연결된 측정항목을 볼 수 있습니다. 사용 가능한 노드 측정항목에 관한 자세한 내용은 시스템 통계 측정항목 참조를 참고하세요.

특정 읽기 풀 인스턴스와 연결된 노드 ID를 알아보려면 읽기 풀 노드의 세부정보 나열을 참고하세요.

이러한 측정항목과 기타 AlloyDB 측정항목에 관한 전체 참조 문서는 'Google Cloud 측정항목'의 alloydb을 참고하세요.

노드의 일시성에 관한 참고사항

일시적인 조사나 디버깅 목적으로 노드에 안전하게 연결할 수 있지만 읽기 풀을 사용하는 애플리케이션은 항상 클러스터가 인스턴스 목록에 표시하는 IP 주소를 사용하여 인스턴스 수준에서 이러한 풀에 연결해야 합니다.

AlloyDB는 읽기 풀의 노드를 교체 가능한 임시 리소스로 취급합니다. 서비스는 읽기 풀 인스턴스의 부하 분산 및 응답성을 유지하기 위해 필요한 빈도로 읽기 풀의 노드 목록을 변경합니다. 읽기 풀 인스턴스가 아닌 읽기 풀 노드에 직접 연결되는 애플리케이션은 AlloyDB가 인스턴스의 노드 목록을 업데이트할 때마다 데이터베이스 연결이 갑자기 끊길 위험이 있습니다.

항상 애플리케이션이 인스턴스 수준에서 읽기 풀에 연결되도록 하고 AlloyDB가 쿼리를 적절한 노드로 효율적으로 라우팅하도록 하세요.

다음 단계