Cloud SQL 인스턴스 문제 진단

이 페이지에서는 Cloud SQL 인스턴스로 작업할 때 가장 자주 발생하는 문제의 목록과 해결 방법을 설명합니다. 알려진 문제 페이지, 문제 해결, 지원 페이지도 검토하세요.

로그 보기

최근 작업 정보를 확인하려면 Cloud SQL 인스턴스 작업 로그 또는 MySQL 오류 로그를 확인하면 됩니다.

인스턴스가 응답하지 않음

인스턴스가 연결에 더 이상 응답하지 않거나 성능이 저하된 경우 인스턴스가 작업 가이드라인에 부합하는지 확인합니다. 이 가이드라인에 부합하지 않으면 Cloud SQL SLA가 적용되지 않습니다.

연결 문제

애플리케이션이 연결을 올바르게 종료하는지 확인

'Aborted connection nnnn to db:'가 포함된 오류가 표시되는 경우 이는 일반적으로 애플리케이션이 연결을 올바르게 중지하지 않았음을 의미합니다. 네트워크 문제로 인해 이 오류가 발생할 수도 있습니다. 이 오류는 Cloud SQL 인스턴스에 문제가 있음을 의미하지 않습니다.

연결 관리 권장사항 예시는 연결 관리를 참조하세요.

인증서가 만료되었는지 확인

인스턴스가 SSL을 사용하도록 구성된 경우 Cloud Console의 Cloud SQL 인스턴스 페이지로 이동하여 인스턴스를 엽니다. 인스턴스의 연결 페이지를 열고 서버 인증서가 유효한지 확인합니다. 만료된 경우 새 인증서를 추가하고 새 인증서로 순환시켜야 합니다. 자세히 알아보기

연결 권한이 있는지 확인

연결이 실패하면 연결이 승인되었는지 확인합니다.

  • 예를 들어 온프레미스 환경에서 mysql 클라이언트를 사용해 연결하는 등 IP 주소를 사용하여 연결하는 데 문제가 있는 경우 연결 시 사용하는 IP 주소에 Cloud SQL 인스턴스 연결이 승인되었는지 확인합니다.

    비공개 IP 주소를 사용하는 Cloud SQL 인스턴스에 대한 연결은 RFC 1918 주소 범위에서 자동으로 승인됩니다. 이에 따라 모든 비공개 클라이언트가 프록시를 통하지 않고 데이터베이스에 액세스할 수 있습니다. RFC 1918 이외의 주소 범위는 승인된 네트워크로 구성되어야 합니다.

    Cloud SQL은 기본적으로 VPC에서 RFC 1918 이외의 서브넷 경로를 학습하지 않습니다. RFC 1918 이외의 경로를 내보내려면 네트워크 피어링을 Cloud SQL로 업데이트해야 합니다. 예를 들면 다음과 같습니다.

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

  • 현재 IP 주소를 확인합니다.

  • gcloud sql connect 명령어를 사용하여 인스턴스에 연결합니다. 이 명령어는 잠시 동안 IP 주소를 승인합니다. Cloud SDK와 mysql 클라이언트가 설치된 환경에서 이 명령어를 실행할 수 있습니다. Cloud Shell에서도 이 명령어를 실행할 수 있습니다. Cloud Shell은 Google Cloud Console에서 제공되며 Cloud Shell에 Cloud SDK와 mysql 클라이언트가 사전 설치되어 있습니다. Cloud Shell에서는 Cloud SQL에 연결하는 데 사용할 수 있는 Compute Engine 인스턴스를 제공합니다.
  • 모든 IP 주소가 인스턴스에 연결되도록 일시적으로 허용합니다. IPv4의 경우 0.0.0.0/0을 승인합니다(IPv6의 경우 ::/0 승인).

연결 방법 확인

연결 시 다음과 같은 오류 메시지가 표시되는 경우

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)

비밀번호를 제공하고 있는지 확인하세요.

연결 시 다음과 같은 오류 메시지가 표시되는 경우

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)

올바른 비밀번호를 사용하고 있는지와 인스턴스가 요구할 경우 SSL을 통해 연결하고 있는지 확인합니다.

연결 시작 방법 결정

다음 명령어를 실행하여 현재 연결에 대한 정보를 확인할 수 있습니다.

SHOW PROCESSLIST;

1.2.3.4와 같은 IP 주소가 표시된 연결은 IP를 사용하여 연결됩니다. cloudsqlproxy~1.2.3.4가 표시된 연결은 Cloud SQL 프록시를 사용하거나 App Engine에서 시작된 것입니다. localhost에서의 연결은 일부 내부 Cloud SQL 프로세스가 사용할 수 있습니다.

연결 한도 이해

Cloud SQL 인스턴스에 대한 QPS 한도는 없습니다. 그러나 연결, 크기, App Engine별 한도가 설정되어 있습니다. 할당량 및 한도를 참조하세요.

데이터베이스 연결은 서버 및 연결 애플리케이션의 리소스를 사용합니다. 항상 연결 관리 권장사항을 참고하여 애플리케이션의 사용 공간을 최소화하고 Cloud SQL 연결 한도를 초과할 가능성을 줄이세요. 자세한 내용은 데이터베이스 연결 관리를 참조하세요.

연결 및 스레드 표시

'too many connections' 오류 메시지가 표시되거나 인스턴스에서 발생하는 상황을 확인하려면 SHOW PROCESSLIST를 사용하여 연결 수와 스레드 수를 표시하면 됩니다.

MySQL 클라이언트에서 다음을 실행합니다.

mysql> SHOW PROCESSLIST;

다음과 비슷한 출력이 표시됩니다.

+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| Id | User      | Host         | db        | Command | Time | State | Info                 |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
|  3 | user-name | client-IP    | NULL      | Query   |    0 | NULL  | SHOW processlist     |
|  5 | user-name | client-IP    | guestbook | Sleep   |    1 |       | SELECT * from titles |
| 17 | user-name | client-IP    | employees | Query   |    0 | NULL  | SHOW processlist     |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
3 rows in set (0.09 sec)

PROCESSLIST에서 반환된 열을 해석하는 방법에 대한 자세한 내용은 MySQL 참조를 확인하세요.

스레드 수를 가져오려면 다음을 사용하면 됩니다.

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';

다음과 비슷한 출력이 표시됩니다.

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Compute Engine에서 연결

Compute Engine 인스턴스와의 연결은 10분 동안 비활성 상태이면 시간 초과되어 Compute Engine 인스턴스와 Cloud SQL 인스턴스 간의 오랫동안 사용되지 않은 연결에 영향을 줄 수 있습니다. 자세한 내용은 Compute Engine 문서의 네트워킹 및 방화벽을 참조하세요.

오랫동안 사용되지 않은 연결을 유지하려면 TCP 연결 유지를 설정하면 됩니다. 다음 명령어는 TCP 연결 유지 값을 1분으로 설정하고 인스턴스 재부팅 시 구성을 영구 유지합니다.

현재 tcp_keepalive_time 값을 표시합니다.

cat /proc/sys/net/ipv4/tcp_keepalive_time

tcp_keepalive_time을 60초로 설정하고 재부팅할 때도 영구적이게 설정합니다.

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

변경사항을 적용합니다.

sudo /sbin/sysctl --load=/etc/sysctl.conf

tcp_keepalive_time 값을 표시하여 변경사항이 적용되었는지 확인합니다.

cat /proc/sys/net/ipv4/tcp_keepalive_time

IPv6로 연결

연결 시 다음 오류 메시지 중 하나가 표시되는 경우

Can't connect to MySQL server on '2001:1234::4321' (10051)
Can't connect to MySQL server on '2001:1234::4321' (101)

인스턴스의 IPv6 주소로 연결을 시도하고 있지만 워크스테이션에서 IPv6를 사용하지 못할 가능성이 높습니다. ipv6.google.com으로 이동하여 워크스테이션에서 IPv6가 작동하는지 확인할 수 있습니다. 이 페이지가 로드되지 않으면 IPv6를 사용할 수 없는 것입니다. IPv4 주소 또는 Cloud SQL 인스턴스에 대신 연결합니다. 먼저 IPv4 주소를 인스턴스에 추가해야 할 수도 있습니다.

연결 타임아웃

클라이언트가 비공개 IP를 사용하여 Cloud SQL 인스턴스에 연결할 수 없는 경우에는 클라이언트가 172.17.0.0/16 범위 내 IP를 사용하고 있는지 확인합니다. 172.17.0.0/16 범위 내 IP에서 비공개 IP를 사용하여 Cloud SQL 인스턴스로 연결할 수 없습니다. 마찬가지로 이 범위 내 IP로 생성된 Cloud SQL 인스턴스에 연결할 수 없습니다. 이 범위는 Docker 브리지 네트워크에 예약되어 있습니다.

비정기적인 연결 오류

유지보수 이벤트로 인해 Cloud SQL이 인스턴스를 다시 시작하면 연결이 장애 조치 복제본으로 라우팅될 수 있습니다. 장애 조치 복제본에 연결되면 다음과 같은 상황이 발생합니다.

  • 암호화되지 않은 연결을 사용하는 클라이언트의 읽기 요청은 정상적으로 처리됩니다. 하지만 쓰기 요청이 실패하고 'Error 1290: The MySQL server is running with the --read-only option so it cannot execute this statement'와 같은 오류 메시지가 반환됩니다.

  • 암호화된 연결을 사용하는 클라이언트의 읽기 및 쓰기 요청이 실패하고 'x509: certificate is valid for master-instance, not failover-instance'와 같은 오류 메시지가 반환됩니다.

이벤트가 끝나면 Cloud SQL에서 연결을 재설정합니다. 연결을 다시 시도합니다. 지수 백오프와 같은 오류 처리 전략을 수립하여 비정기적인 연결 오류가 해결되도록 애플리케이션을 설계하는 것이 좋습니다. 자세한 내용은 애플리케이션 구현을 참조하세요.

인스턴스 문제

백업

백업의 성능을 최적화하려면 테이블 수를 적정 수로 유지합니다.

가져오기 및 내보내기

Cloud SQL의 가져오기 및 내보내기mysqldump 유틸리티를 사용할 때와 동일합니다. 하지만 Cloud SQL 가져오기/내보내기 기능의 경우 Cloud Storage 버킷을 사용하여 데이터를 전송한다는 점이 다릅니다.

Cloud Storage 버킷을 통해 가져오기 기능을 사용하여 Cloud SQL로 가져오기 및 내보내기 작업은 데이터베이스 크기에 따라 완료하는 데 오랜 시간이 걸릴 수 있습니다. 이에 따른 영향은 다음과 같습니다.

  • 장기 실행 작업을 중지할 수 없습니다.
  • 인스턴스당 한 번에 하나의 가져오기 또는 내보내기 작업만 수행할 수 있습니다.

더 작은 데이터 배치로 Cloud SQL 가져오기 또는 내보내기 기능을 사용하여 각 작업을 완료하는 데 걸리는 시간을 단축시킬 수 있습니다.

내보내기의 경우 서버리스 내보내기를 사용하여 데이터베이스 성능에 미치는 영향을 최소화하고 내보내기를 실행하는 동안 인스턴스에서 다른 작업을 실행할 수 있습니다.

그 밖에 가져오기를 수행할 때 주의해야 할 점은 다음과 같습니다.

  • 가져오기 중에 충돌이 발생하면 메모리 부족(OOM) 오류가 원인일 수 있습니다. 이 경우 MySQL 명령어를 직접 사용하여 --extended-insert=FALSE --complete-insert 매개변수를 추가할 수 있습니다. 이러한 매개변수를 사용하면 가져오기 속도가 낮아지지만 가져오기에 필요한 메모리 양도 감소합니다.

디스크 공간

인스턴스가 최대 허용 저장용량에 도달하면 데이터베이스 쓰기가 실패합니다. 예를 들어 테이블을 삭제하여 데이터를 삭제할 경우 확보된 공간이 인스턴스의 사용한 저장용량 보고에 반영되지 않습니다. 이 동작에 대한 설명은 FAQ의 삭제된 테이블의 공간을 확보하려면 어떻게 해야 하나요?를 참조하세요.

최대 저장용량 한도에 도달해도 인스턴스가 계속 다시 시작될 수 있습니다.

데이터 손상 방지

생성된 열 사용 방지

MySQL의 문제로 인해 생성된 열을 사용하면 데이터가 손상될 수 있습니다. 자세한 내용은 MySQL 버그 #82736을 참조하세요.

정상적인 종료

Cloud SQL에서 인스턴스를 종료하면(예: 유지보수 목적) 새 연결이 인스턴스로 전송되지 않고 기존 연결이 종료됩니다. mysqld가 종료되는 데 소요되는 시간은 최대 1분으로 제한되어 있습니다. 이 시간 내에 종료가 완료되지 않으면 mysqld 프로세스가 강제 중지됩니다. 이 경우 디스크 쓰기가 도중에 취소될 수 있습니다.

데이터베이스 엔진

InnoDB는 유일하게 MySQL 인스턴스에 지원되는 스토리지 엔진이며, 이는 MyISAM과 같은 MySQL 스토리지 엔진보다 테이블 손상에 더 강하기 때문입니다.

기본적으로 Cloud SQL 데이터베이스 테이블은 InnoDB 스토리지 엔진을 통해 생성됩니다. CREATE TABLE 구문에 InnoDB 이외의 다른 스토리지 엔진을 지정하는 ENGINE 옵션이 포함되어 있으면(예: ENGINE = MyISAM), 테이블이 생성되지 않고 다음 예시와 같은 오류 메시지가 표시됩니다.

ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).

CREATE TABLE 명령어에서 ENGINE = MyISAM 옵션을 삭제하면 이 오류를 방지할 수 있습니다. 이렇게 하면 InnoDB 스토리지 엔진으로 테이블이 생성됩니다.

InnoDB에서는 더욱 강력한 데이터 일관성이 보장되므로 1세대 인스턴스에 권장됩니다.

시스템 테이블 변경

mysql.usermysql.db와 같은 mysql 데이터베이스의 모든 테이블이 포함된 MySQL 시스템 테이블은 MyISAM 스토리지 엔진을 사용합니다. 이러한 테이블은 비정상적인 종료에 취약하므로 이러한 테이블을 변경한 후 FLUSH CHANGES 명령어를 실행합니다. MyISAM 손상이 발생하면 CHECK TABLEREPAIR TABLE을 통해 정상 상태로 돌아갈 수 있습니다(데이터는 저장되지 않음).

글로벌 트랜잭션 식별자(GTID)

모든 MySQL 인스턴스에는 GTID가 자동으로 사용 설정됩니다. GTID를 사용 설정하면 복제본 생성과 장애 조치 시 데이터가 손실되지 않고 복제본이 더 견고해집니다. 그러나 GTID에는 MySQL로 인한 몇 가지 제한 사항이 있으며, 이는 MySQL 매뉴얼에 설명되어 있습니다. GTID가 사용 설정된 MySQL 서버에서는 다음과 같이 안전하지 않은 작업을 트랜잭션 방식으로 사용할 수 없습니다.

  • CREATE TABLE ... SELECT
  • 트랜잭션 내 CREATE TEMPORARY TABLE
  • 트랜잭션 테이블과 트랜잭션이 아닌 테이블 모두에 영향을 미치는 트랜잭션 또는 문

안전하지 않은 트랜잭션을 트랜잭션 방식으로 사용하면 다음 예시와 같은 오류 메시지가 표시됩니다.

 Exception: SQLSTATE[HY000]: General error: 1786
 CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.

트리거와 저장 함수 사용

인스턴스에 바이너리 로깅이 사용 설정되어 있고 트리거나 저장 함수로 작업해야 하는 경우 인스턴스에서 log_bin_trust_function_creators 플래그가 on으로 설정되어 있는지 확인합니다.

정지 상태

Cloud SQL에서 인스턴스를 정지할 수 있는 이유는 다음을 포함하여 다양합니다.

  • 결제 문제

    예를 들어 프로젝트 결제 계정의 신용카드가 만료되면 인스턴스가 정지될 수 있습니다. Google Cloud Console의 결제 페이지에서 프로젝트를 선택하고 프로젝트에 사용된 결제 계정 정보를 조회하여 프로젝트 결제 정보를 확인할 수 있습니다. 결제 문제를 해결하면 인스턴스가 몇 시간 내에 실행 가능한 상태로 돌아갑니다.

  • KMS 주요 문제

    예를 들어 Cloud SQL 인스턴스에서 사용자 데이터를 암호화하는 데 사용된 KMS 키 버전이 없거나 중지 또는 삭제된 경우입니다. 고객 관리 암호화 키(CMEK) 사용을 참조하세요.

  • 법적 문제

    예를 들어 Google Cloud 서비스이용 정책을 위반하면 인스턴스가 정지될 수 있습니다. 자세한 내용은 Google Cloud 서비스 약관의 '정지 및 삭제'를 참조하세요.

  • 운영 문제

    예를 들어 인스턴스가 장애 루프에서 중단된 경우(시작 중 또는 시작 직후에 인스턴스가 비정상 종료된 경우) Cloud SQL에서 인스턴스를 정지할 수 있습니다.

결제 문제가 정지를 트리거한 경우 인스턴스가 정지된 상태에서 인스턴스 관련 정보를 확인하거나 인스턴스를 삭제할 수 있습니다.

플래티넘, 골드, 실버 서포트 패키지가 있는 Cloud SQL 사용자는 정지된 인스턴스에 대해 지원팀에 직접 문의할 수 있습니다. 모든 사용자는 google-cloud-sql 포럼과 함께 이전 안내를 사용할 수 있습니다.

성능

쿼리 로그 사용 설정

쿼리 성능을 미세 조정하려면 인스턴스에 --log_output='FILE'--slow_query_log=on 데이터베이스 플래그를 추가하여 Cloud SQL이 느린 쿼리를 로깅하도록 구성하면 됩니다. 이렇게 하면 Google Cloud Console의 로그 뷰어를 사용하여 로그를 출력할 수 있습니다. Google Cloud의 작업 제품군 로깅 요금이 적용됩니다.

log_output을 TABLE로 설정하지 마세요. 플래그 사용 팁에서 설명한 연결 문제가 발생할 수 있습니다.

잠금 모니터링 사용 설정

InnoDB 모니터는 InnoDB 저장소 엔진의 내부 상태에 관한 정보를 제공하는데, 성능 조절 시 이 정보를 사용할 수 있습니다.

MySQL 클라이언트를 사용하여 인스턴스에 액세스하고 주문형 모니터 출력을 확인합니다.

SHOW ENGINE INNODB STATUS\G

모니터 출력 섹션에 대한 자세한 내용은 InnoDB 표준 모니터 및 잠금 모니터 출력을 참조하세요.

출력이 정기적으로 파일이나 테이블로 생성되도록 InnoDB 모니터를 사용 설정할 수 있습니다. 이렇게 하면 성능이 저하됩니다. 자세한 내용은 InnoDB 모니터 사용 설정을 참조하세요.

성능 스키마 사용

MySQL 성능 스키마는 하위 수준에서 MySQL 서버 실행을 모니터링하는 기능입니다. performance_schema에서 생성된 통계를 사용하는 가장 간단한 방법은 MySQL Workbench 성능 보고서 기능을 사용하는 것입니다.

적절한 데이터베이스 테이블 수 유지

데이터베이스 테이블은 시스템 리소스를 사용합니다. 테이블 수가 많으면 인스턴스 성능과 가용성이 영향을 받을 수 있으며 인스턴스에 SLA가 적용되지 않을 수 있습니다. 자세히 알아보기

일반 성능 팁

  • 머신 유형이 워크로드에 충분한지 확인합니다.

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

  • 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.

속도가 느린 데이터베이스 선택에는 다음을 고려하세요.

  • 캐싱은 읽기 성능에 중요합니다. 데이터 세트 크기를 인스턴스의 RAM 크기와 비교합니다. 전체 데이터 세트가 인스턴스 RAM의 70% 이내인 것이 가장 좋으며, 이렇게 하면 쿼리가 IO 성능으로 제한되지 않습니다. 그렇지 않으면 인스턴스 등급 크기를 늘리는 것이 좋습니다.
  • 워크로드가 CPU 집약적인 쿼리(정렬, 정규 표현식, 기타 복잡한 함수)로 구성된 경우 인스턴스가 제한될 수 있습니다. 이런 경우에는 등급을 올립니다.
  • 리더와 데이터베이스의 위치를 확인합니다. 지연 시간은 쓰기 성능보다 읽기 성능에 더 많은 영향을 미칩니다.
  • 적절한 색인 생성, 검색 데이터 축소, 추가 왕복 방지와 같이 Cloud SQL과 관련 없는 성능 개선 사항을 조사합니다.

쿼리 실행 성능이 저하되면 EXPLAIN을 사용합니다. EXPLAIN은 SELECT와 같이 다른 문에 추가하는 문으로 MySQL이 문을 실행하는 방법에 대한 정보를 반환합니다. SELECT, DELETE, INSERT, REPLACE, UPDATE와 연동됩니다. 예를 들면 EXPLAIN SELECT * FROM myTable;입니다.

EXPLAIN을 사용하여 다음 작업을 수행할 수 있는 위치를 식별합니다.

  • 표에 색인을 추가하여 쿼리 성능을 개선합니다. 예를 들어 JOIN 키로 사용하는 모든 필드에 두 테이블의 색인이 있는지 확인합니다.

  • ORDER BY 작업을 개선합니다. EXPLAIN 출력의 Extra 열에 'Using temporary; Using filesort'가 표시되면 중간 결과가 파일에 저장된 후에 분류됩니다. 이러면 일반적으로 성능이 저하됩니다. 이 경우에는 다음 조치 중 하나를 실행합니다.

    • 가능하다면 정렬 대신 색인을 사용합니다. 자세한 내용은 ORDER BY 최적화를 참조하세요.

    • 쿼리 세션에서 sort_buffer_size 변수 크기를 늘립니다.

    • 열을 필요한 만큼만 선언하여 행별로 사용되는 RAM 크기를 줄입니다.

고객 관리 암호화 키(CMEK)

Cloud KMS 오류, 역할 또는 권한 누락으로 인해 생성, 클론, 업데이트와 같은 Cloud SQL 관리자 작업이 실패할 수 있습니다. Cloud KMS 키 버전이 누락되거나, Cloud KMS 키 버전이 중지 또는 삭제되거나, Cloud KMS 키 버전에 액세스할 수 있는 IAM 권한이 없거나, Cloud KMS 키 버전이 Cloud SQL 인스턴스와 다른 리전에 있는 경우 등에는 일반적으로 작업이 실패하게 됩니다. 일반적인 문제를 진단하고 해결하려면 다음 문제해결 표를 사용하세요.

고객 관리 암호화 키 문제해결 표

발생 오류 문제 원인 해결 방법
제품별, 프로젝트별 서비스 계정을 찾을 수 없음 서비스 계정 이름이 잘못되었습니다. 올바른 사용자 프로젝트의 서비스 계정을 만들었는지 확인합니다.

서비스 계정 페이지로 이동

서비스 계정에 액세스 권한을 부여할 수 없음 사용자 계정에 이 키 버전에 대한 액세스 권한을 부여할 수 있는 권한이 없습니다. 사용자 계정 또는 서비스 계정에 조직 관리자 역할을 추가합니다.

IAM 계정 페이지로 이동

Cloud KMS 키 버전이 삭제됨 키 버전이 삭제되었습니다. 키 버전이 삭제되면 데이터를 암호화하거나 복호화하는 데 사용할 수 없습니다.
Cloud KMS 키 버전이 사용 중지됨 키 버전이 사용 중지되었습니다. Cloud KMS 키 버전을 다시 사용 설정합니다.

암호화 키 페이지로 이동

Cloud KMS 키를 사용할 수 있는 권한이 없음 Cloud SQL 인스턴스에서 작업을 실행하는 데 사용하는 사용자 또는 서비스 계정에 cloudkms.cryptoKeyEncrypterDecrypter 역할이 없거나 Cloud KMS 키 버전이 없습니다. 사용자 또는 서비스 계정에 cloudkms.cryptoKeyEncrypterDecrypter 역할을 추가합니다.

IAM 계정 페이지로 이동


이 역할이 계정에 이미 있으면 키 만들기를 참조하여 새 키 버전을 만드는 방법을 알아보세요. 참고를 참조하세요.
Cloud KMS 키를 찾을 수 없음 키 버전이 존재하지 않습니다. 새 키 버전을 만듭니다. 키 만들기를 참조하세요. 참고를 참조하세요.
Cloud SQL 인스턴스와 Cloud KMS 키 버전이 서로 다른 리전에 있음 Cloud KMS 키 버전과 Cloud SQL 인스턴스는 같은 리전에 있어야 합니다. Cloud KMS 키 버전이 전역 리전 또는 멀티 리전에 있는 경우에는 작동하지 않습니다. 인스턴스를 만들려는 리전에 키 버전을 만듭니다. 키 만들기를 참조하세요. 참고를 참조하세요.

Cloud SQL 인스턴스 문제 해결

자세한 내용을 보려면 표의 링크를 클릭하세요.

문제 설명 문제 원인 해결 방법
다시 시작 후 성능이 저하됩니다. 다시 시작되면 InnoDB 캐시가 비어 있으므로 모든 읽기에서 데이터를 가져오려면 백엔드를 왕복해야 합니다.. 모든 데이터가 채워질 때까지 기다리세요.
비정상 종료 복구가 느립니다. 대량의 general_log가 누적되었을 수 있습니다. 일반 로깅을 관리합니다. 자세히 알아보기
스토리지를 사용하는 항목을 확인하려 합니다. 데이터베이스 테이블, 바이너리 로그 또는 임시 파일이 대부분의 용량을 사용합니다. 이 팁에서 확인 방법을 참조하세요.
쿼리가 차단됩니다. 한 프로세스가 다른 모든 프로세스를 차단하고 있습니다. 차단하는 프로세스를 찾아 중지합니다. 자세히 알아보기
바이너리 로그를 수동으로 삭제할 수 없습니다. 바이너리 로그를 수동으로 삭제할 수 없습니다. 바이너리 로그는 일반적으로 약 7일 후에 관련된 자동 백업과 함께 자동으로 삭제됩니다.
임시 파일에 대한 정보를 찾으려고 합니다. 임시 파일 이름은 ibtmp1입니다. 자세히 알아보려면 이 데이터베이스 쿼리를 사용해 보세요.
테이블 크기를 알아보려고 합니다. 데이터베이스에서 이 정보를 확인할 수 있습니다. 자세히 알아보려면 이 데이터베이스 쿼리를 사용해 보세요.
mysqld에서 신호 11을 받았습니다. 쿼리가 너무 많은 연결을 만들고 있으므로 인스턴스가 비정상 종료되었습니다. 이를 방지하려면 쿼리를 리팩터링하세요.
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. 페이지 클리너가 인스턴스의 변화 속도를 따라잡지 못합니다. 인스턴스 샤딩이 도움이 될 수 있습니다.
임시 스토리지가 자동 스토리지를 늘림 자동 스토리지가 사용 설정되었습니다. 다시 시작하면 임시 파일은 삭제되지만 저장용량은 줄어들지 않습니다. 인스턴스 크기는 고객지원에서만 재설정할 수 있습니다. 자세히 알아보기
데이터가 자동으로 삭제됨 이 작업을 수행하는 스크립트가 어디선가 실행 중입니다. 스크립트를 찾습니다.
인스턴스를 삭제할 수 없음 둘 이상의 근본 원인이 있을 수 있습니다. 둘 이상의 솔루션이 있을 수 있습니다.
큰 임시 데이터 크기로 인해 인스턴스가 중단됨 한 번에 너무 많은 임시 테이블이 생성되었습니다. 인스턴스를 다시 시작하고 이 완화 옵션을 시도합니다.
업그레이드 중 치명적인 오류 발생 여러 가지 원인이 있을 수 있습니다. 로그에 더 많은 정보가 표시될 수 있습니다. 강제로 다시 시작하려면 고객지원에 문의해야 합니다.
디스크 공간 부족 후 다시 시작할 때 인스턴스가 중단됨 저장용량 자동 증가 기능이 사용 설정되지 않았습니다. 스토리지 자동 증가를 사용 설정합니다.
온프레미스 기본 인스턴스가 멈춤 해당 사항 없음 Cloud SQL 고객 지원팀에서는 Cloud SQL에 없는 인스턴스를 지원할 수 없습니다.
다시 시작 시 종료가 느림 60초 후에도 종료되지 않는 연결은 비정상적 종료를 초래할 수 있습니다. 지속 시간이 60초 미만인 연결만 유지합니다.
Access denied for user 사용자 인증 또는 만료된 SSL/TLS 인증서 문제입니다. 사용자 및 인증서 상태를 확인합니다.
사용자를 삭제할 수 없음 사용자가 데이터베이스의 객체를 소유하고 있을 수 있습니다. 객체를 삭제하거나 다시 할당해야 할 수 있습니다.
공유 VPC의 기존 인스턴스에 비공개 IP 주소를 할당할 수 없음 인스턴스 주소는 생성 시 프로젝트에 연결됩니다. 기존 인스턴스를 대체할 새 Cloud SQL 인스턴스를 만듭니다.
특정 쿼리가 느리게 실행됨 데이터베이스 관련 문제 또는 네트워크 지연 시간 문제입니다. 이 제안 사항을 확인하세요.
메모리 부족이라고 표시되지만 모니터링 차트에는 표시되지 않음 내부 오버헤드 프로세스에서 일부 RAM을 사용 중일 수 있습니다. 인스턴스에 워크로드의 충분한 오버헤드가 있는지 확인합니다.

다시 시작 후 성능 저하

다시 시작 후 성능이 저하됩니다.

문제 원인

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; 명령어를 사용하여 이 로크 크기를 확인할 수 있습니다.

쿼리가 차단됨

쿼리가 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을 받음

다음 오류가 발생합니다.

mysqld got signal 11

문제 원인

쿼리가 너무 많은 연결을 만들고 있으므로 인스턴스가 비정상 종료되었을 수 있습니다.

해결 방법

연결이 너무 많이 생성되지 않도록 쿼리를 리팩터링합니다.


InnoDB: page_cleaner

서버가 계속 중단되고 다음과 같은 오류가 발생합니다. InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal

문제 원인

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

해결 방법

가능한 경우 인스턴스를 샤딩합니다. 여러 개의 작은 Cloud SQL 인스턴스를 사용하는 것이 하나의 큰 인스턴스를 사용하는 것보다 더 효과적입니다.


임시 스토리지가 자동 스토리지를 늘림

임시 테이블이 스토리지 사용량을 늘리고 자동 스토리지가 늘어났습니다.

문제 원인

자동 스토리지가 사용 설정되었습니다.

해결 방법

임시 테이블을 삭제하기 위해 다시 시작해도 자동으로 증가한 스토리지 크기는 줄어들지 않습니다.


데이터가 자동으로 삭제됨

정기적으로 데이터가 자동으로 삭제됩니다.

문제 원인

환경에서 스크립트가 실행되고 있을 가능성이 높습니다.

해결 방법

삭제 시점의 로그를 살펴보고 대시보드 또는 다른 자동화된 프로세스에서 실행 중인 악성 스크립트가 있는지 확인합니다.


인스턴스를 삭제할 수 없음

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일 수 있습니다.

문제 원인

  1. 다른 작업이 진행 중입니다.
  2. INSTANCE_RISKY_FLAG_CONFIG 경고는 하나 이상의 beta 플래그가 사용될 때마다 트리거됩니다.

해결 방법

  1. Cloud SQL 작업은 동시에 실행되지 않습니다. 다른 작업이 완료될 때까지 기다립니다.
  2. 위험한 플래그 설정을 삭제하고 인스턴스를 다시 시작합니다.

큰 임시 데이터 크기로 인해 시스템이 중단됨

큰 임시 데이터 크기로 인해 시스템이 중단되었습니다.

문제 원인

시스템은 쿼리와 부하에 따라 한 번에 여러 개의 임시 테이블을 만들 수 있습니다.

해결 방법

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

한 가지 완화 옵션은 ROW_FORMAT=COMPRESSED로 임시 테이블을 만들어 임시 파일 디렉터리의 file-per-table 테이블스페이스에 저장하는 것입니다. 하지만 단점은 각 임시 테이블의 file-per-table 테이블스페이스를 만들고 삭제하는 것과 관련된 성능 비용입니다.


업그레이드 중 치명적인 오류 발생

인스턴스에서 리소스를 업그레이드할 때 ERROR_INTERNAL_FATAL 오류 메시지가 표시됩니다.

문제 원인

여러 가지 원인이 있을 수 있습니다.

해결 방법

로그에 더 많은 정보가 표시될 수 있지만 어떤 경우에도 인스턴스를 강제로 다시 만들려면 고객지원이 필요할 수 있습니다.


디스크 공간 부족 후 다시 시작할 때 인스턴스가 중단됨

디스크 공간 부족 후 다시 시작할 때 인스턴스가 멈춥니다.

문제 원인

저장용량 자동 증가 기능이 사용 설정되지 않았습니다.

해결 방법

인스턴스의 저장용량이 부족하고 저장용량 자동 증가 기능이 사용 설정되지 않은 경우 인스턴스가 오프라인 상태가 됩니다. 이 문제를 방지하려면 인스턴스를 수정하여 스토리지 자동 증가를 사용 설정하면 됩니다.


온프레미스 기본 인스턴스가 멈춤

온프레미스 기본 인스턴스가 멈췄을 때 Cloud SQL 고객 지원팀의 지원을 받을 수 있는지 알고 싶습니다.

문제 원인

인스턴스가 Cloud SQL에 없습니다.

해결 방법

Cloud SQL 고객 지원팀에서는 Cloud SQL에 없는 인스턴스를 지원할 수 없습니다.


다시 시작 시 종료가 느림

다시 시작 시 종료가 느립니다.

문제 원인

인스턴스가 종료될 때 60초 이내에 종료되지 않는 연결로 인해 비정상 종료가 발생합니다.

해결 방법

60초 미만 지속되는 연결만 유지하면 데이터베이스 명령 프롬프트의 연결을 포함한 대부분의 비정상 종료를 방지할 수 있습니다. 이러한 연결을 몇 시간 또는 며칠 동안 열어두면 종료가 비정상적으로 될 수 있습니다.


사용자 액세스가 거부됨

Access denied for user 'XXX'@'XXX' (using password: XXX) 오류 메시지가 표시됩니다.

문제 원인

다음과 같은 몇 가지 근본 원인이 있을 수 있습니다.

  • 사용자 이름(또는 비밀번호)이 잘못되었습니다.
  • 사용자가 @XXX가 아닌 곳에서 연결 중입니다.
  • 연결하려는 데이터베이스에 대한 올바른 권한이 사용자에게 없습니다.

해결 방법

  • 사용자 이름과 해당 비밀번호를 확인합니다.
  • 연결의 출처를 확인하여 사용자에게 액세스 권한이 부여된 위치와 일치하는지 확인합니다.
  • 데이터베이스에서 사용자의 권한 부여를 확인합니다.

사용자를 삭제할 수 없음

데이터베이스 사용자를 삭제할 수 없습니다.

문제 원인

사용자에게 종속된 객체가 데이터베이스에 있습니다. 먼저 해당 객체를 삭제하거나 다른 사용자에게 다시 할당해야 합니다.

해결 방법

사용자에게 종속된 객체를 찾은 후 이 객체를 삭제하거나 다른 사용자에게 다시 할당합니다. 이 문서에서는 사용자가 소유한 객체를 찾는 방법을 설명합니다.


공유 VPC의 기존 인스턴스에 비공개 IP 주소를 할당할 수 없음

공유 VPC의 기존 인스턴스에 비공개 IP 주소를 할당할 수 없습니다.

문제 원인

그 이유는 Cloud SQL 인스턴스가 생성되면 테넌트 프로젝트에 자동으로 연결되므로 동일한 해당 프로젝트의 Cloud SQL 인스턴스도 모두 자동으로 테넌트 프로젝트에 연결되기 때문입니다. 하지만 생성된 인스턴스가 공유 VPC에서 비공개 IP를 사용하는 경우 공유 VPC 호스트 프로젝트와 연결된 테넌트 프로젝트에 연결됩니다.

해결 방법

새 Cloud SQL 인스턴스를 만들어 기존 인스턴스를 바꿀 수 있습니다.


특정 쿼리가 느리게 실행됨

CPU 사용량이 지속적으로 높습니다.

문제 원인

쿼리는 여러 가지 이유로 느려질 수 있지만 주로 데이터베이스의 특정 부분이 원인입니다. Cloud SQL과 관련될 수 있는 한 가지 이유는 소스(작성자 또는 리더) 리소스와 대상(Cloud SQL) 리소스가 서로 다른 리전에 있는 경우의 네트워크 지연 시간입니다.

해결 방법

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

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

  • 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.
  • 리더 및 데이터베이스의 위치를 확인합니다. 지연 시간은 쓰기 성능보다 읽기 성능에 더 많은 영향을 미칩니다.
지연 시간을 줄이려면 소스 리소스와 대상 리소스를 동일한 리전에 두는 것이 좋습니다.


메모리 부족이라고 표시되지만 모니터링 차트에는 표시되지 않음

인스턴스가 실패하고 Out of memory를 보고하지만 Console이나 Cloud Monitoring 차트에는 여전히 메모리가 남아 있는 것으로 표시됩니다.

문제 원인

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

해결 방법

인스턴스에 워크로드와 일부 추가 오버헤드를 처리할 수 있는 오버헤드가 충분한지 확인합니다.