Cloud SQL 문제 해결

이 페이지에는 지원되는 데이터베이스 엔진의 Cloud SQL 문제 해결 팁이 포함되어 있습니다. 일부 팁은 특정 데이터베이스 엔진에만 적용되는 반면 모든 데이터베이스 엔진에 공통으로 적용되는 팁도 있습니다.

특정 데이터베이스 엔진에 대한 문제 해결 팁은 해당 개별 페이지를 참조하세요.

질문 또는 문제가 다음 페이지 중 하나에서 이미 해결된 것인지 확인합니다.

이 페이지의 주제는 다음과 같습니다.

백업 및 복구

문제 문제 해결
현재 작업의 상태를 볼 수 없습니다. Google Cloud 콘솔은 작업 완료 시에만 성공 또는 실패를 보고합니다. 경고 또는 기타 업데이트를 표시하도록 설계되지 않았습니다.

gcloud sql operations list 명령어를 실행하여 특정 Cloud SQL 인스턴스의 모든 작업을 나열합니다.
주문형 백업 작업을 실행한 사용자를 확인하려고 합니다. 사용자 인터페이스에 작업을 시작한 사용자가 표시되지 않습니다.

로그를 살펴보고 텍스트를 기준으로 필터링하여 사용자를 찾습니다. 비공개 정보의 경우 감사 로그를 사용해야 할 수도 있습니다. 관련 로그 파일은 다음과 같습니다.

  • Cloud 감사 로그가 사용 설정되어 있고 이를 보는 데 필요한 권한이 있는 경우 cloudaudit.googleapis.com/activity를 사용할 수도 있습니다.
인스턴스가 삭제된 후에는 인스턴스를 백업할 수 없습니다.

인스턴스가 삭제된 후에는 데이터를 복구할 수 없습니다. 그러나 인스턴스가 복원되면 해당 백업도 복원됩니다. 삭제된 인스턴스를 복구하는 방법에 대한 자세한 내용은 복구 백업을 참조하세요.

내보내기 작업을 완료한 경우 새 인스턴스를 만든 다음 가져오기 작업을 수행하여 데이터베이스를 다시 만들 수 있습니다. 내보내기는 Cloud Storage에 쓰이고 여기에서 가져오기를 읽습니다.
자동 백업이 장시간 중단되고 취소할 수 없습니다. 데이터베이스 크기에 따라 백업에 오랜 시간이 걸릴 수 있습니다.

작업을 취소해야 하는 경우 고객지원에 인스턴스 force restart를 요청할 수 있습니다.
SQL 덤프 파일에 참조된 하나 이상의 사용자가 없으면 복원 작업이 실패할 수 있습니다. SQL 덤프를 복원하기 전에 객체를 소유하거나 덤프된 데이터베이스의 객체에 대한 권한이 부여된 모든 데이터베이스 사용자가 대상 데이터베이스에 있어야 합니다. 그렇지 않으면 복원 작업이 원래 소유권이나 권한으로 객체를 다시 만들지 못합니다.

SQL 덤프를 복원하기 전에 데이터베이스 사용자를 만듭니다.
자동 백업 보관 일수를 7일에서 30일 이상으로 늘리려고 합니다. 유지할 자동 백업 수를 구성할 수 있습니다. 자동 백업은 구성된 보관 값에 따라 정기적으로 프루닝됩니다. 따라서 복원할 수 있는 자동 백업은 현재 표시되는 백업뿐입니다.

백업을 무기한 보관하려면 자동 백업과 동일한 방식으로 삭제되지 않는 주문형 백업을 만들면 됩니다. 주문형 백업은 무기한 유지됩니다. 즉, 백업이나 백업이 속한 인스턴스가 삭제될 때까지 유지됩니다. 이러한 유형의 백업은 자동으로 삭제되지 않으므로 결제에 영향을 미칠 수 있습니다.
자동 백업에 실패했으며 이메일 알림을 받지 못했습니다. Cloud SQL에서 백업 상태를 알리도록 설정하려면 로그 기반 알림을 구성합니다.
인스턴스가 실패 및 백업 복원 상태 사이를 순환하며 반복적으로 실패합니다. 복원 후 데이터베이스에 대한 연결과 사용 시도가 실패합니다.
  • 개방형 연결이 너무 많을 수 있습니다. 끊어진 연결을 삭제하는 autovacuum 설정이 없는 상황에서 연결 중간에 발생하는 오류로 인해 너무 많은 연결이 생길 수 있습니다.
  • 커스텀 코드에서 몇 번 실패해도 중지되지 않는 재시도 로직을 사용하면 순환이 발생할 수 있습니다.
  • 트래픽이 너무 많을 수 있습니다. 연결 풀링과 기타 연결 권장사항을 따릅니다.

해결 방법:

  1. 데이터베이스가 autovacuum에 설정되었는지 확인합니다.
  2. 커스텀 코드에 설정된 연결 재시도 로직이 있는지 확인합니다.
  3. 데이터베이스가 복구될 때까지 트래픽을 줄였다가 천천히 다시 복구합니다.
백업/복원 작업을 수행할 때 데이터가 누락됐음을 발견합니다. 테이블이 로깅되지 않는 상태로 생성되었습니다. 예를 들면 다음과 같습니다.

CREATE UNLOGGED TABLE ....

이러한 테이블은 백업에서 복원에 포함되지 않습니다.

  • 로깅되지 않은 테이블의 콘텐츠는 HA 인스턴스의 장애 조치 시 유실됩니다.
  • 로깅되지 않은 테이블은 postgres 비정상 종료 시 유실됩니다.
  • 로깅되지 않은 테이블은 읽기 복제본에 복제되지 않습니다.
  • 로깅되지 않은 테이블은 백업 복원 중에 자동으로 완전 삭제됩니다.

해결 방법은 백업을 통해 이러한 테이블을 복원하고 싶다면 로깅되지 않은 테이블을 사용하지 않는 것입니다. 이미 로깅되지 않은 테이블이 있는 데이터베이스에서 복원하는 경우 데이터베이스를 파일로 덤프하고 해당 테이블에 대하여 SET LOGGED로 ALTER TABLE하여 덤프된 파일을 수정한 후 데이터를 다시 로드할 수 있습니다.

클론

문제 문제 해결
constraints/sql.restrictAuthorizedNetworks 오류와 함께 클론이 실패합니다. 클론 작업이 Authorized Networks 구성에 의해 차단되었습니다. Google Cloud 콘솔의 연결 섹션에서 공개 IP 주소에 Authorized Networks가 구성되어 있으며 보안 고려사항으로 인해 클론이 허용되지 않습니다.

가능하면 Cloud SQL 인스턴스에서 모든 Authorized Networks 항목을 삭제합니다. 그렇지 않으면 Authorized Networks 항목 없이 복제본을 만듭니다.
오류 메시지: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Google Cloud 콘솔을 사용하여 비공개 IP 주소로 인스턴스를 클론하려고 하지만 사용할 할당된 IP 범위를 지정하지 않았고 소스 인스턴스가 지정된 범위로 생성되지 않습니다. 따라서 클론된 인스턴스는 무작위 범위로 생성됩니다.

gcloud를 사용하여 인스턴스를 클론하고
--allocated-ip-range-name 매개변수의 값을 제공합니다. 자세한 내용은 비공개 IP로 인스턴스 클론을 참조하세요.

연결

문제 문제 해결
Aborted connection. 문제 원인:
  • 네트워킹 불안정.
  • TCP 연결 유지 명령어에 대한 응답이 없습니다. 클라이언트 또는 서버가 응답하지 않으며 과부하되었을 수 있습니다.
  • 데이터베이스 엔진 연결 수명이 초과되어 서버에서 연결을 종료했습니다.

애플리케이션은 네트워크 장애를 허용하고 연결 풀링 및 재시도와 같은 권장사항을 따라야 합니다. 대부분의 연결 풀러는 이러한 오류를 포착합니다(가능한 경우). 그렇지 않으면 애플리케이션이 다시 시도하거나 정상적으로 실패해야 합니다.

연결을 다시 시도하려면 다음 방법을 사용하는 것이 좋습니다.

  1. 지수 백오프. 재시도 간격을 기하급수적으로 늘립니다.
  2. 무작위 백오프도 추가합니다.

이러한 방법을 조합하면 제한을 줄일 수 있습니다.
FATAL: database 'user' does not exist. gcloud sql connect --user가 기본 postgres 사용자에서만 작동합니다.

기본 사용자와 연결한 후 사용자를 변경합니다.
연결된 사용자를 확인하려는 경우 데이터베이스에 로그인하고 아래 명령어를 실행합니다.


SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20

인스턴스 만들기

문제 문제 해결
오류 메시지: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID]. Cloud SQL 인스턴스를 다시 만들어 보세요.
오류 메시지: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID. 비공개 IP 주소를 사용하여 인스턴스를 만들면 Service Networking API를 사용하여 적시에 서비스 계정이 생성됩니다. 최근에 Service Networking API를 사용 설정한 경우 서비스 계정이 생성되지 않고 인스턴스 만들기가 실패할 수 있습니다. 이 경우 서비스 계정이 시스템 전체에 전파될 때까지 기다리거나 필요한 권한을 수동으로 추가해야 합니다.

내보내기

문제 문제 해결
HTTP Error 409: Operation failed because another operation was already in progress. 인스턴스에 대기 중인 작업이 이미 있습니다. 한 번에 하나의 작업만 허용됩니다. 현재 작업이 완료된 후 요청을 시도하세요.
HTTP Error 403: The service account does not have the required permissions for the bucket. 버킷이 있고 내보내기를 수행하는 Cloud SQL 인스턴스의 서비스 계정에 버킷으로 내보낼 수 있는 Storage Object Creator 역할(roles/storage.objectCreator)이 있는지 확인합니다. Cloud Storage에 대한 IAM 역할을 참조하세요.
CSV 내보내기에 성공했지만 SQL 내보내기에 실패했습니다. CSV 형식과 SQL 형식은 내보내기 방식이 서로 다릅니다. SQL 형식은 전체 데이터베이스를 내보내며 완료하는 데 더 오래 걸릴 수 있습니다. CSV 형식은 내보내기에 포함할 데이터베이스 요소를 정의할 수 있습니다.

CSV 내보내기를 사용하여 필요한 항목만 내보냅니다.
내보내기가 너무 오래 걸림 Cloud SQL은 동시 동기 작업을 지원하지 않습니다.

내보내기 오프로딩을 사용합니다. 상위 수준의 내보내기 오프로드에서 Cloud SQL은 소스 인스턴스에서 내보내기를 실행하는 대신 오프로드 인스턴스를 가동하여 내보내기를 수행합니다. 내보내기 오프로드를 사용하면 소스 인스턴스의 성능을 향상하고 내보내기를 실행하는 중에 관리 작업 차단을 해제할 수 있는 등 여러 가지 이점이 있습니다. 내보내기 오프로드를 사용하면 오프로드 인스턴스를 불러오는 데 걸리는 시간에 따라 총 지연 시간이 늘어날 수 있습니다. 일반적으로 적절한 크기의 내보내기에서는 지연 시간이 중요하지 않습니다. 그러나 내보내기가 충분히 작으면 지연 시간이 증가될 수 있습니다.
확장 프로그램 생성 오류 덤프 파일에 지원되지 않는 확장 프로그램에 대한 참조가 있습니다.

덤프 파일을 수정하여 참조를 삭제합니다.
pg_dumpall 사용 오류 pg_dumpall 유틸리티를 --global 플래그와 함께 사용하려면 수퍼유저 역할이 필요하지만 이 역할은 Cloud SQL에서 지원되지 않습니다. 사용자 이름이 포함된 내보내기 작업을 수행하는 동안 오류가 발생하지 않도록 하려면 --no-role-passwords 플래그도 사용합니다.
내보내기 전에 내보내기 작업이 타임아웃되면 Could not receive data from client: Connection reset by peer. 오류 메시지가 표시됩니다. Cloud Storage가 특정 기간(일반적으로 약 7분) 내에 데이터를 수신하지 않으면 연결이 재설정됩니다. 초기 내보내기 쿼리를 실행하는 데 시간이 너무 오래 걸릴 수 있습니다.

pg_dump 도구를 사용하여 직접 내보냅니다.
내보내기를 자동화하려고 합니다. Cloud SQL은 내보내기를 자동화하는 방법을 제공하지 않습니다.

백업 자동화에 대한 이 문서와 마찬가지로 Cloud Scheduler, Pub/Sub, Cloud Functions와 같은 Google Cloud 제품을 사용하여 자체 자동 내보내기 시스템을 빌드할 수 있습니다.

외부 기본

문제 문제 해결
Lost connection to MySQL server during query when dumping table. 소스를 사용할 수 없거나 덤프가 너무 큰 패킷을 포함하고 있을 수 있습니다.

외부 기본 프로젝트를 연결할 수 있는지 확인합니다. 소스 인스턴스에서 net_read_timeout 및 net_write_timeout 플래그의 값을 수정하여 오류를 중지할 수도 있습니다. 이러한 플래그에 허용되는 값에 대한 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

관리형 가져오기 마이그레이션에 mysqldump 플래그를 사용하는 방법에 대한 자세한 내용은 허용되는 기본 초기 동기화 플래그를 참조하세요.
초기 데이터 마이그레이션이 성공했지만 복제 중인 데이터가 없습니다. 한 가지 가능한 근본 원인은 소스 데이터베이스에서 복제 플래그를 정의하여 일부 또는 전체 데이터베이스 변경사항이 복제되지 않기 때문일 수 있습니다.

binlog-do-db, binlog-ignore-db, replicate-do-db, replicate-ignore-db와 같은 복제 플래그가 충돌 방식으로 설정되어 있지 않은지 확인합니다.

기본 인스턴스에서 show master status 명령어를 실행하여 현재 설정을 확인합니다.
초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다. 해결 방법:

  • Google Cloud Console의 Cloud Monitoring 섹션에서 복제본 인스턴스의 복제 측정항목을 확인합니다.
  • MySQL IO 스레드 또는 SQL 스레드의 오류는 mysql.err log 파일의 Cloud Logging에서 확인할 수 있습니다.
  • 이 오류는 복제본 인스턴스에 연결할 때도 찾을 수 있습니다. SHOW SLAVE STATUS 명령어를 실행하고 출력에서 다음 필드를 확인합니다.
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. 복제본 인스턴스의 데이터 디스크가 가득 찼습니다.

복제본 인스턴스의 디스크 크기를 늘립니다. 수동으로 디스크 크기를 늘리거나 스토리지 자동 증가를 사용 설정할 수 있습니다.

외부 복제본

문제 문제 해결
오류 메시지: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires. 기본 Cloud SQL 인스턴스에는 자동 백업 및 바이너리 로그와 point-in-time recovery가 사용 설정되어 있으므로 복제본이 따라잡을 수 있을 만큼 충분한 로그가 있어야 합니다. 그러나 이 경우에는 바이너리 로그가 존재하더라도 복제본은 어떤 행부터 읽을지 알 수 없습니다.

올바른 플래그 설정을 사용하여 새 덤프 파일을 만들고 이 파일을 사용하여 외부 복제본을 구성합니다.

  1. Compute Engine 인스턴스를 통해 mysql 클라이언트에 연결합니다.
  2. mysqldump를 실행하고 --master-data=1 및 --flush-privileges 플래그를 사용합니다.

    중요: --set-gtid-purged=OFF 플래그를 포함하지 마세요.

    자세히 알아보기

  3. 방금 만든 덤프 파일에 SET @@GLOBAL.GTID_PURGED='...' 줄이 포함되어 있는지 확인합니다.
  4. 덤프 파일을 Cloud Storage 버킷에 업로드하고 덤프 파일을 사용하여 복제본을 구성합니다.

플래그

문제 문제 해결

고가용성

문제 문제 해결
수동 장애 조치에 대한 측정항목을 찾을 수 없습니다. 자동 장애 조치만 측정항목에 포함됩니다.
Cloud SQL 인스턴스 리소스(CPU 및 RAM) 사용량이 거의 100%여서 고가용성 인스턴스가 다운됩니다. 인스턴스 머신 크기가 부하에 비해 너무 작습니다.

인스턴스를 수정하여 더 큰 머신 크기로 업그레이드하면 CPU와 메모리가 늘어납니다.

가져오기

문제 문제 해결
HTTP Error 409: Operation failed because another operation was already in progress. 인스턴스에 대기 중인 작업이 이미 있습니다. 한 번에 하나의 작업만 허용됩니다. 현재 작업이 완료된 후 요청을 시도하세요.
가져오기 작업이 너무 오래 걸립니다. 활성 연결이 너무 많으면 가져오기 작업을 방해할 수 있습니다.

사용하지 않는 작업을 종료합니다. Cloud SQL 인스턴스의 CPU 및 메모리 사용량을 확인하여 사용 가능한 리소스가 충분한지 확인합니다. 가져오기에 최대 리소스를 보장하는 가장 좋은 방법은 작업을 시작하기 전에 인스턴스를 다시 시작하는 것입니다.

다시 시작하면 다음과 같은 결과가 발생합니다.

  • 모든 연결이 끊깁니다.
  • 리소스를 소비할 수 있는 모든 태스크가 종료됩니다.
덤프 파일에 참조된 하나 이상의 사용자가 없으면 가져오기 작업이 실패할 수 있습니다. 덤프 파일을 가져오기 전에 객체를 소유하거나 덤프된 데이터베이스의 객체에 대한 권한이 부여된 모든 데이터베이스 사용자가 대상 데이터베이스에 있어야 합니다. 그렇지 않으면 가져오기 작업이 원래 소유권이나 권한으로 객체를 다시 만들지 못합니다.

가져오기 전에 데이터베이스 사용자를 만듭니다.
테이블이 존재하지 않는다는 오류와 함께 가져오기 작업이 실패합니다. 테이블은 다른 테이블의 외래 키 종속 항목을 가질 수 있으며, 작업 순서에 따라 이러한 테이블 중 하나 이상이 가져오기 작업 도중에는 아직 존재하지 않을 수 있습니다.

해결 방법:

덤프 파일의 시작 부분에 다음 줄을 추가합니다.


SET FOREIGN_KEY_CHECKS=0;

또한 덤프 파일의 끝 부분에 다음 줄을 추가합니다.


SET FOREIGN_KEY_CHECKS=1;

이러한 설정은 가져오기 작업이 진행되는 동안 데이터 무결성 검사를 비활성화하고 데이터가 로드된 후 다시 활성화합니다. 덤프 파일을 만드는 동안 데이터가 이미 검증되었으므로 데이터베이스의 데이터 무결성에는 영향이 없습니다.

Vertex AI와 통합

문제 문제 해결
오류 메시지: Google ML integration API is supported only on Postgres version 12 or above. Cloud SQL에서 Vertex AI 통합을 사용 설정하려면 PostgreSQL용 Cloud SQL 데이터베이스 버전 12 이상이 필요합니다. 데이터베이스를 이 버전으로 업그레이드하려면 데이터베이스 주 버전 인플레이스 업그레이드를 참조하세요.
오류 메시지: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. 인스턴스의 머신 유형에 공유 코어를 선택한 경우 Cloud SQL에서 Vertex AI 통합을 사용 설정할 수 없습니다. 머신 유형을 전용 코어로 업그레이드합니다. 자세한 내용은 머신 유형을 참조하세요.
오류 메시지: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. Cloud SQL에서 Vertex AI 통합을 사용 설정하려면 인스턴스의 유지보수 버전이 R20240130 이상이어야 합니다. 인스턴스를 이 버전으로 업그레이드하려면 셀프서비스 유지보수를 참조하세요.
오류 메시지: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. cloudsql.enable_google_ml_integration 데이터베이스 플래그가 사용 중지됩니다. Cloud SQL은 Vertex AI와 통합할 수 없습니다.

이 플래그를 사용 설정하려면 gcloud sql instances patch 명령어를 사용합니다.

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

INSTANCE_NAME을 기본 Cloud SQL 인스턴스의 이름으로 바꿉니다.
오류 메시지: Failed to connect to remote host: Connection refused. Cloud SQL과 Vertex AI 간의 통합이 사용 설정되지 않습니다. 이 통합을 사용 설정하려면 gcloud sql instances patch 명령어를 사용합니다.

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

INSTANCE_NAME을 기본 Cloud SQL 인스턴스의 이름으로 바꿉니다.
오류 메시지: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. Vertex AI API가 사용 설정되지 않습니다. 이 API 사용 설정에 대한 자세한 내용은 Vertex AI와 데이터베이스 통합 사용 설정을 참조하세요.
오류 메시지: Permission 'aiplatform.endpoints.predict' denied on resource. Vertex AI 권한은 Cloud SQL 인스턴스가 있는 프로젝트의 Cloud SQL 서비스 계정에 추가되지 않습니다. 서비스 계정에 이러한 권한을 추가하는 방법에 대한 자세한 내용은 Vertex AI와 데이터베이스 통합 사용 설정을 참조하세요.
오류 메시지: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. Vertex AI에 머신러닝 모델 또는 LLM이 존재하지 않습니다.
오류 메시지: Resource exhausted: grpc: received message larger than max. Cloud SQL이 Vertex AI에 전달하는 요청 크기가 요청당 gRPC 한도인 4MB를 초과합니다.
오류 메시지: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. Cloud SQL이 Vertex AI에 요청을 전송하려고 시도하지만 인스턴스는 한 리전에 있지만 Vertex AI 엔드포인트는 다른 리전에 있습니다. 이 문제를 해결하려면 인스턴스와 엔드포인트가 모두 동일한 리전에 있어야 합니다.
오류 메시지: The Vertex AI endpoint isn't formatted properly. Vertex AI 엔드포인트의 형식이 올바르지 않습니다. 자세한 내용은 온라인 예측에 비공개 엔드포인트 사용을 참조하세요.
오류 메시지: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. Cloud SQL이 Vertex AI에 전달하는 요청 수가 프로젝트별 모델당 리전별 분당 요청 1,500개 한도를 초과합니다.

연결된 서버

오류 메시지 문제 해결
Msg 7411, Level 16, State 1, Line 25

Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS. 		DataAccess 옵션이 사용 중지되었습니다. 다음 명령어를 실행하여 데이터 액세스를 사용 설정합니다.

EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

LINKED_SERVER_NAME을 연결된 서버의 이름으로 바꿉니다.

Access to the remote server is denied because no login-mapping exists. (Microsoft SQL Server, Error: 7416) 암호화된 연결을 설정하는 동안 이 문제가 발생하면 연결된 서버에 액세스할 때 사용자 ID를 제공하는 다른 방법을 시도해야 합니다. 이렇게 하려면 다음 명령을 실행합니다. 

EXEC master.dbo.sp_addlinkedserver
   @server = N'LINKED_SERVER_NAME',
   @srvproduct= N'',
   @provider= N'SQLNCLI',
   @datasrc= N'TARGET_SERVER_ID',
   @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID'

다음을 바꿉니다.

  • LINKED_SERVER_NAME을 연결된 서버의 이름으로 바꿉니다.
  • TARGET_SERVER_ID를 대상 서버의 이름 또는 대상 서버의 IP 주소 및 포트 번호로 바꿉니다.
  • USER_ID를 사용자 로그인으로 바꿉니다.

로깅

문제 문제 해결
감사 로그를 찾을 수 없음 데이터 액세스 로그는 작업이 사용자가 만든 데이터를 생성 또는 수정하거나 읽는 인증된 사용자 주도 API 호출인 경우 또는 작업이 리소스의 구성 파일 또는 메타데이터에 액세스하는 경우에만 작성됩니다.
로그에 작업 정보가 없음 작업에 대한 자세한 정보를 찾으려 합니다.

예를 들어 사용자가 삭제되었는데 누가 삭제했는지 알 수 없습니다. 로그는 작업이 시작되었음을 표시하지만 그 이상의 정보를 제공하지 않습니다. 이와 같은 자세한 개인 식별 정보(PII)를 로깅하려면 감사 로깅을 사용 설정해야 합니다.
일부 로그는 SQL Server용 Cloud SQL 인스턴스의 error.log 로그에서 필터링됩니다. 필터링된 로그는 타임스탬프가 없는 AD 로그를 포함하며 다음을 포함합니다. Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1] 이러한 로그는 잠재적으로 혼란을 야기할 수 있으므로 필터링됩니다.
Logging이 디스크 공간을 많이 사용함 디스크 공간을 사용하는 로그 파일에는 재실행 로그, 일반 로그, 바이너리 로그가 있습니다.

데이터베이스에 연결하고 다음 명령어를 실행하여 각 유형에 대한 세부정보를 확인합니다.


SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
로그 파일을 읽기 어려움 로그를 json 또는 텍스트로 보는 것이 좋습니다.gcloud logging read 명령어를 Linux 후처리 명령어와 함께 사용하여 로그를 다운로드할 수 있습니다.

로그를 JSON으로 다운로드하려면 다음 명령어를 실행합니다.


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json

로그를 TEXT로 다운로드하려면 다음 명령어를 실행합니다.


gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
PostgreSQL 로그에서 쿼리 로그를 찾을 수 없음 pgaudit 플래그를 사용 설정해야 합니다.
  1. 터미널에서 데이터베이스에 연결합니다. 
    
gcloud sql connect INSTANCE_NAME
  2. 다음 명령어를 실행하여 확장 프로그램을 만듭니다. 
    
CREATE EXTENSION pgaudit;
  3. 데이터베이스를 종료하고 터미널에서 다음 명령어를 실행합니다. 
    
gcloud sql instances patch INSTANCE_NAME \
--database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all

인스턴스 관리

문제 문제 해결
MySQL을 다시 시작 후 성능이 저하됩니다. Cloud SQL은 InnoDB 버퍼 풀의 데이터 캐싱을 허용합니다. 그러나 다시 시작 후에는 이 캐시가 항상 비어 있으며 모든 읽기에서 데이터를 가져오려면 백엔드를 왕복해야 합니다. 따라서 캐시가 채워질 때까지 쿼리가 예상보다 느릴 수 있습니다.
비정상 종료 복구가 느립니다. 대량의 general_log가 누적되었을 수 있습니다. general_log가 대량으로 누적되지 않도록 하여 비정상 종료 복구 시간을 단축시킬 수 있습니다. general_log를 사용 설정한 경우 테이블을 자르고 짧은 기간 동안에만 general_log를 사용 설정합니다.

데이터베이스에 연결하고 쿼리를 실행하여 일반 로그의 크기를 확인할 수 있습니다.

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;
스토리지를 사용하는 항목을 확인하려 합니다. 예를 들어 데이터베이스는 3GB만 사용하고 있지만 스토리지에서는 14GB가 사용 중이라고 표시할 수 있습니다. 테이블에서 사용하지 않는 공간 대부분은 바이너리 로그 또는 임시 파일에서 사용됩니다.

해결 방법:

  • MySQL 명령줄 인터페이스에서 SHOW BINARY LOGS; 명령어를 사용하여 바이너리 로그가 차지하는 스토리지를 확인할 수 있습니다.
  • 임시 테이블이 상당량의 저장공간을 차지할 수도 있습니다. 임시 공간 사용량을 확인하려면 SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G 명령어를 사용하세요.
  • SHOW VARIABLES LIKE 'innodb_log_file%'; 명령어를 사용하면 재실행 로그 크기를 확인할 수 있습니다.
  • general_log가 사용 설정된 경우 SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log; 명령어를 사용하여 이 로크 크기를 확인할 수 있습니다.
  • 필요한 경우 API를 사용하여 로그 테이블을 자를 수 있습니다. 자세한 내용은 instances.truncateLog 참조 페이지를 확인하세요.
  • 느린 쿼리 로그 설정 및 구성에 대해 자세히 알아보세요.
쿼리가 차단됩니다. 쿼리가 MySQL 데이터베이스를 잠가 이후 모든 쿼리의 차단/제한 시간이 발생할 가능성이 있습니다.

데이터베이스에 연결하고 다음 쿼리를 실행합니다.

SHOW PROCESSLIST.

목록의 첫 번째 항목이 잠금 항목이고 이후 항목은 대기 상태일 수 있습니다.

SHOW INNODB STATUS 쿼리도 유용할 수 있습니다.
바이너리 로그를 수동으로 삭제할 수 없습니다. 바이너리 로그를 수동으로 삭제할 수 없습니다. 일반적으로 약 7일 후에 관련된 자동 백업과 함께 자동으로 삭제됩니다.
임시 파일에 대한 정보를 찾으려고 합니다. 이름이 ibtmp1인 파일은 임시 데이터 저장용으로 사용됩니다. 이 파일은 데이터베이스를 다시 시작하면 초기화됩니다. 임시 파일 사용량에 대한 정보를 확인하려면 데이터베이스에 연결하고 다음 쿼리를 실행합니다.

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G
테이블 크기를 알아보려고 합니다. 데이터베이스에서 이 정보를 확인할 수 있습니다.

데이터베이스에 연결하고 다음 쿼리를 실행합니다.

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;
mysqld에서 신호 11을 받았습니다. 연결이 너무 많이 생성되지 않도록 쿼리를 리팩터링합니다. 그래도 문제가 해결되지 않으면 고객지원에 문의하세요. 신호 11은 일반적으로 MySQL 소프트웨어 문제를 나타냅니다.

InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. 페이지 클리너가 인스턴스의 변화 속도를 따라잡지 못합니다. 1초에 한 번 페이지가 버퍼 풀을 스캔하여 버퍼 풀에서 디스크로 플러시할 더티 페이지가 있는지 검사합니다. 표시되는 경고에서는 플러시할 더티 페이지가 많다는 것과 이러한 배치를 디스크에 플러시하는 데 1초 넘게 걸린다는 것을 설명합니다.

가능한 경우 인스턴스를 샤딩합니다. 여러 개의 작은 Cloud SQL 인스턴스를 사용하는 것이 하나의 큰 인스턴스를 사용하는 것보다 더 효과적입니다.
현재 실행 중인 쿼리를 확인하려는 경우 데이터베이스에 연결하고 다음 쿼리를 실행합니다.

SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;

특정 필드에 사용 중인 단위를 확인하려는 경우 데이터베이스에 연결하고 자체 FIELD_NAME을 사용하여 다음 쿼리를 실행합니다.

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'.
데이터베이스 설정의 현재 값을 찾는 경우 데이터베이스에 연결하고 자체 SETTING_NAME을 사용하여 다음 쿼리를 실행합니다.

SHOW SETTING_NAME;

SHOW ALL;을 실행하여 모든 설정을 확인합니다.
차단된 백그라운드 프로세스를 중지하려고 합니다. 사용자는 pg_signal_backend 역할이 있어야 합니다.

다음 명령어를 실행합니다.

  1. 
      GRANT pg_signal_backend TO USERNAME;
  2. 차단되거나 중단된 프로세스의 프로세스 ID를 확인합니다. 
    
      SELECT pid, usename, state, query FROM pg_stat_activity;
  3. 다음 명령어를 사용하여 실행 중 또는 비활성 프로세스를 중지합니다. 
    
      SELECT pg_cancel_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
      
      
    
      SELECT pg_terminate_backend(pid)
            FROM pg_stat_activity
            WHERE usename = 'USERNAME';
인스턴스가 트랜잭션 ID를 100% 가까이 소비함 내부 모니터링에서 인스턴스가 트랜잭션 ID를 100% 가까이 소비하고 있음을 경고합니다. 쓰기를 차단할 수 있는 트랜잭션 래핑을 피하는 것이 좋습니다.

autovacuum 작업이 차단되었거나 워크로드를 감당할 수 있을 만큼 신속하게 트랜잭션 ID를 확보하지 못할 수 있습니다.

트랜잭션 래핑 문제로 인한 서비스 중단을 방지하려면 TXID 래핑을 다루는 다음 셀프서비스 도움말을 검토하세요.

일반 조정 관련 조언은 PostgreSQL의 청소 작업 최적화, 모니터링, 문제 해결을 참조하세요.
임시 스토리지가 자동 스토리지를 늘림 자동 스토리지가 사용 설정되었습니다.

다시 시작하면 임시 파일은 삭제되지만 스토리지는 줄어들지 않습니다. 인스턴스 크기는 고객지원에서만 재설정할 수 있습니다.
데이터가 자동으로 삭제됨 환경에서 스크립트가 실행되고 있을 가능성이 높습니다.

삭제 시점의 로그를 살펴보고 대시보드 또는 다른 자동화된 프로세스에서 실행 중인 악성 스크립트가 있는지 확인합니다.
인스턴스를 삭제할 수 없음 ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request 오류 메시지가 표시되거나 인스턴스의 플래그 상태가 INSTANCE_RISKY_FLAG_CONFIG일 수 있습니다.

다음과 같이 설명할 수 있습니다.

  • 다른 작업이 진행 중입니다. Cloud SQL 작업은 동시에 실행되지 않습니다. 다른 작업이 완료될 때까지 기다립니다.
  • INSTANCE_RISKY_FLAG_CONFIG 경고는 하나 이상의 beta 플래그가 사용될 때마다 트리거됩니다. 위험한 플래그 설정을 삭제하고 인스턴스를 다시 시작합니다.
큰 임시 데이터 크기로 인해 인스턴스가 중단됨 시스템은 쿼리와 부하에 따라 한 번에 여러 개의 임시 테이블을 만들 수 있습니다.

서비스 다시 시작 이외의 방법으로는 ibtmp1 파일을 축소할 수 없습니다.

한 가지 완화 옵션은 ROW_FORMAT=COMPRESSED로 임시 테이블을 만들어 임시 파일 디렉터리의 file-per-table 테이블스페이스에 저장하는 것입니다. 하지만 단점은 각 임시 테이블의 file-per-table 테이블스페이스를 만들고 삭제하는 것과 관련된 성능 비용입니다.
업그레이드 중 치명적인 오류 발생 로그에 더 많은 정보가 표시될 수 있지만 어떤 경우에도 인스턴스를 강제로 다시 만들려면 고객지원이 필요할 수 있습니다.
디스크 공간 부족 후 다시 시작할 때 인스턴스가 중단됨 스토리지 자동 증가 기능이 사용 설정되지 않았습니다.

인스턴스의 스토리지가 부족하고 스토리지 자동 증가 기능이 사용 설정되지 않은 경우 인스턴스가 오프라인 상태가 됩니다. 이 문제를 방지하려면 인스턴스를 수정하여 스토리지 자동 증가를 사용 설정하면 됩니다.
온프레미스 기본 인스턴스가 멈췄습니다. Google Cloud는 Cloud SQL에 없는 인스턴스를 지원할 수 없습니다.
다시 시작 시 종료가 느림 인스턴스가 종료될 때 60초 이내에 종료되지 않는 연결로 인해 비정상 종료가 발생합니다.

60초 미만 지속되는 연결을 유지하면 데이터베이스 명령 프롬프트의 연결을 포함한 대부분의 비정상 종료를 방지할 수 있습니다. 이러한 연결을 몇 시간 또는 며칠 동안 열어두면 종료가 비정상적으로 될 수 있습니다.
사용자를 삭제할 수 없음 사용자에게 종속된 객체가 데이터베이스에 있을 수 있습니다. 이러한 객체를 삭제하거나 다른 사용자에게 다시 할당해야 합니다.

사용자에게 종속된 객체를 찾은 후 이 객체를 삭제하거나 다른 사용자에게 다시 할당합니다.
특정 쿼리가 느리게 실행됨 쿼리는 여러 가지 이유로 느려질 수 있지만 주로 데이터베이스의 특정 부분이 원인입니다. Cloud SQL과 관련될 수 있는 한 가지 이유는 소스(작성자 또는 리더) 리소스와 대상(Cloud SQL) 리소스가 서로 다른 리전에 있는 경우의 네트워크 지연 시간입니다.

특히 일반 성능 팁을 참조하세요.

데이터베이스 삽입, 업데이트 또는 삭제 속도가 느리다면 다음과 같은 조치를 취하는 것이 좋습니다.

  • 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.
  • 리더 및 데이터베이스의 위치를 확인합니다. 지연 시간은 쓰기 성능보다 읽기 성능에 더 많은 영향을 미칩니다.

지연 시간을 줄이려면 소스 리소스와 대상 리소스를 동일한 리전에 두는 것이 좋습니다.
메모리 부족이라고 표시되지만 모니터링 차트에는 표시되지 않음 인스턴스가 실패하고 Out of memory를 보고하지만 Google Cloud 콘솔이나 Cloud Monitoring 차트에는 여전히 메모리가 남아 있는 것으로 표시됩니다.

워크로드 외에도 활성 연결 수 및 내부 오버헤드 프로세스와 같이 메모리 사용량에 영향을 줄 수 있는 다른 요소가 있습니다. 이러한 요소가 항상 모니터링 차트에 반영되는 것은 아닙니다.

인스턴스에 워크로드와 일부 추가 오버헤드를 처리할 수 있는 오버헤드가 충분한지 확인합니다.
삭제된 인스턴스 복구 인스턴스를 삭제하면 백업을 포함한 인스턴스의 모든 데이터가 영구 삭제됩니다.

데이터를 보존하려면 인스턴스를 삭제하기 전에 Cloud Storage로 내보내기를 수행합니다.

Cloud SQL 관리자 역할은 인스턴스를 삭제할 수 있는 권한을 포함합니다. 실수로 삭제하지 않도록 방지하려면 필요한 경우에만 이 역할을 부여하세요.
기존 Cloud SQL 인스턴스의 이름을 바꾸려는 경우 기존 인스턴스의 이름 변경은 지원되지 않습니다.

새 인스턴스를 만들면 목표를 달성할 수 있습니다.

  • 이름을 바꾸려는 인스턴스를 클론하고 클론된 인스턴스에 새 이름을 설정하면 됩니다. 그러면 수동으로 데이터를 가져올 필요 없이 새 인스턴스를 만들 수 있습니다. 새 인스턴스를 만들 때와 마찬가지로 클론된 인스턴스에는 새 IP 주소가 지정됩니다.
  • 인스턴스에서 Cloud Storage 버킷으로 데이터를 내보내고 원하는 이름으로 새 인스턴스를 만든 후 데이터를 새 인스턴스로 가져올 수 있습니다.

두 경우 모두 작업이 완료되면 기존 인스턴스를 삭제하시면 됩니다. 성능에 영향을 미치지 않고 플래그, 머신 유형, 스토리지 크기, 메모리와 같은 인스턴스 구성 설정을 다시 실행할 필요가 없으므로 클론 경로를 사용하는 것을 권장합니다.
인스턴스를 삭제하는 중에 오류 발생 인스턴스에 삭제 보호가 사용 설정된 경우 인스턴스 삭제 계획을 확인합니다. 그런 다음 인스턴스를 삭제하기 전에 삭제 보호를 사용 중지합니다.

복제

문제 문제 해결
생성 시 읽기 복제본이 복제를 시작하지 않음 로그 파일에 더 구체적인 오류가 있을 수 있습니다. Cloud Logging의 로그를 검사하여 실제 오류를 찾으세요.
읽기 복제본을 만들 수 없음 - invalidFlagValue 오류 요청의 플래그 중 하나가 잘못되었습니다. 명시적으로 제공한 플래그 또는 기본값으로 설정된 플래그일 수 있습니다.

먼저 max_connections 플래그의 값이 기본 값보다 크거나 같은지 확인하세요.

max_connections 플래그가 적절하게 설정된 경우 Cloud Logging에서 로그를 검사하여 실제 오류를 확인하세요.
읽기 복제본을 만들 수 없음 - 알 수 없는 오류 로그 파일에 더 구체적인 오류가 있을 수 있습니다. Cloud Logging의 로그를 검사하여 실제 오류를 찾으세요.

오류가 set Service Networking service account as servicenetworking.serviceAgent role on consumer project이면 Service Networking API를 사용 중지했다가 다시 사용 설정합니다. 이렇게 하면 프로세스를 계속 진행하는 데 필요한 서비스 계정이 생성됩니다.
디스크가 가득 참 복제본을 만드는 동안 기본 인스턴스 디스크 크기가 가득 찰 수 있습니다. 기본 인스턴스를 수정하여 더 큰 디스크 크기로 업그레이드합니다.
복제본 인스턴스가 너무 많은 메모리를 사용하고 있습니다. 복제본은 임시 메모리를 사용하여 자주 요청되는 읽기 작업을 캐시하므로 기본 인스턴스보다 더 많은 메모리를 사용할 수 있습니다.

복제본 인스턴스를 다시 시작하여 임시 메모리 공간을 회수합니다.
복제가 중지됨 최대 스토리지 한도에 도달했고 스토리지 자동 증가가 사용 설정되지 않았습니다.

인스턴스를 수정하여 automatic storage increase를 사용 설정합니다.
긴 복제 지연 시간이 지속적으로 발생함 쓰기 부하가 너무 높아 복제본이 처리할 수 없습니다. 복제본의 SQL 스레드가 IO 스레드를 따라잡을 수 없는 경우 복제 지연이 발생합니다. 일부 쿼리 또는 워크로드로 인해 특정 스키마에서 일시적이거나 영구적인 복제 지연이 발생할 수 있습니다. 복제 지연이 발생하는 일반적인 원인은 다음과 같습니다.
  • 복제본에 대한 쿼리의 속도가 느립니다. 문제를 찾아 수정하세요.
  • 모든 테이블에 고유/기본 키가 있어야 합니다. 테이블에 고유/기본 키가 없으면 업데이트할 때마다 복제본에서 전체 테이블 검사를 수행해야 합니다.
  • DELETE ... WHERE field < 50000000과 같은 쿼리의 경우 복제본에 다수의 업데이트가 쌓이게 되므로 행 기준 복제에서 복제 지연이 발생합니다.

가능한 솔루션은 다음과 같습니다.

  • 인스턴스를 수정하여 복제본 크기를 늘립니다.
  • 데이터베이스의 부하를 줄입니다.
  • 읽기 트래픽을 읽기 복제본으로 보냅니다.
  • 테이블 색인을 생성합니다.
  • 느린 쓰기 쿼리를 식별하고 수정합니다.
  • 복제본을 다시 만듭니다.
제한 시간으로 인해 복제본을 만들지 못했습니다. 기본 인스턴스에서 커밋되지 않은 장기 실행 트랜잭션으로 인해 읽기 복제본을 만들지 못할 수 있습니다.

실행 중인 모든 쿼리를 중지한 후 복제본을 다시 만듭니다.