이 페이지에서는 Cloud SQL 인스턴스로 작업할 때 가장 자주 발생하는 문제의 목록과 해결 방법을 설명합니다. 알려진 문제, 문제 해결, 지원 페이지도 검토하세요.
로그 보기
최근 작업 정보를 확인하려면 Cloud SQL 인스턴스 작업 로그 또는 MySQL 오류 로그를 확인하면 됩니다.
인스턴스가 응답하지 않음
인스턴스가 연결에 더 이상 응답하지 않거나 성능이 저하된 경우 인스턴스가 작업 가이드라인에 부합하는지 확인합니다. 이 가이드라인에 부합하지 않으면 Cloud SQL SLA가 적용되지 않습니다.
연결 문제
연결 문제에 대한 도움말은 연결 문제 디버깅 페이지 또는 문제 해결 페이지의 연결 섹션을 참조하세요.
인스턴스 문제
백업
백업의 성능을 최적화하려면 테이블 수를 적정 수로 유지합니다.
다른 백업 문제는 문제 해결 페이지의 백업 섹션을 참조하세요.
가져오기 및 내보내기
Cloud SQL의 가져오기 및 내보내기는 mysqldump 유틸리티를 사용할 때와 동일합니다. 하지만 Cloud SQL 가져오기/내보내기 기능의 경우 Cloud Storage 버킷을 사용하여 데이터를 전송한다는 점이 다릅니다.
Cloud SQL로 가져오고 Cloud SQL에서 내보내는 작업은 처리 중인 데이터의 크기에 따라 완료하는 데 많은 시간이 걸릴 수 있습니다. 이에 따른 영향은 다음과 같습니다.
- 장기 실행 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 스토리지 엔진으로 테이블이 생성됩니다.
시스템 표의 변경
mysql.user 및 mysql.db와 같은 mysql 데이터베이스의 모든 테이블이 포함된 MySQL 시스템 테이블은 MyISAM 스토리지 엔진을 사용합니다. 이러한 테이블은 비정상적인 종료에 취약하므로 이러한 테이블을 변경한 후 FLUSH CHANGES 명령어를 실행합니다. MyISAM 손상이 발생하면 CHECK TABLE과 REPAIR 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의 결제 페이지에서 프로젝트를 선택하고 프로젝트에 사용된 결제 계정 정보를 조회하여 프로젝트 결제 정보를 확인할 수 있습니다. 결제 문제를 해결하면 인스턴스가 몇 시간 내에 실행 가능한 상태로 돌아갑니다.
Cloud Key Management Service의 주요 문제
예를 들어, Cloud SQL 인스턴스에서 사용자 데이터를 암호화하는 데 사용되는 Cloud KMS의 키 버전이 없으면 키에 대한 액세스 권한이 취소되는 경우 또는 키가 비활성화되거나 삭제된 것입니다. 자세한 내용은 고객 관리 암호화 키(CMEK) 사용을 참조하세요.
법적 문제
예를 들어 Google Cloud 서비스이용 정책을 위반하면 인스턴스가 정지될 수 있습니다. 자세한 내용은 Google Cloud 서비스 약관의 '정지 및 삭제'를 참조하세요.
운영 문제
예를 들어 인스턴스가 장애 루프에서 중단된 경우(시작 중 또는 시작 직후에 인스턴스가 비정상 종료된 경우) Cloud SQL에서 인스턴스를 정지할 수 있습니다.
결제 문제가 정지를 트리거한 경우 인스턴스가 정지된 상태에서 인스턴스 관련 정보를 확인하거나 인스턴스를 삭제할 수 있습니다.
플래티넘, 골드, 실버 지원 패키지가 있는 Cloud SQL 사용자는 정지된 인스턴스에 대해 지원팀에 직접 문의할 수 있습니다. 모든 사용자는 google-cloud-sql 포럼과 함께 이전 안내를 이용할 수 있습니다.
성능
개요
Cloud SQL은 I/O 추가 비용 없이 최대 60,000 IOPS의 성능 집약적인 워크로드를 지원합니다. 영구 디스크의 IOPS 및 처리량 성능은 여러 요인 중에서도 디스크 크기, 인스턴스 vCPU 수, I/O 블록 크기에 따라 달라집니다.
인스턴스의 성능도 스토리지 유형 선택과 워크로드에 따라 달라집니다.
다음에 대해 자세히 알아보기
쿼리 로그 사용 설정
쿼리 성능을 미세 조정하려면 인스턴스에 --log_output='FILE' 및 --slow_query_log=on 데이터베이스 플래그를 추가하여 Cloud SQL이 느린 쿼리를 로깅하도록 구성하면 됩니다.
이렇게 하면 Google Cloud Console의 로그 뷰어를 사용하여 로그를 출력할 수 있습니다.
Google Cloud Observability 로깅 요금이 적용됩니다.
log_output을 TABLE로 설정하지 마세요. 플래그 사용 팁에서 설명한 연결 문제가 발생할 수 있습니다.
Cloud Logging 및 Monitoring을 사용하여 MySQL용 Cloud SQL 느린 쿼리를 로깅하고 모니터링하는 방법에 대한 안내는 이 가이드를 참조하세요.
잠금 모니터링 사용 설정
InnoDB 모니터는 InnoDB 저장소 엔진의 내부 상태에 관한 정보를 제공하는데, 성능 조절 시 이 정보를 사용할 수 있습니다.
MySQL 클라이언트를 사용하여 인스턴스에 액세스하고 주문형 모니터 출력을 확인합니다.
SHOW ENGINE INNODB STATUS\G
모니터 출력의 각 섹션에 대한 설명은 InnoDB 표준 모니터 및 잠금 모니터 출력을 참조하세요.
출력이 정기적으로 파일이나 표로 생성되도록 InnoDB 모니터를 사용 설정할 수 있으며, 이 경우 성능이 저하됩니다. 자세한 내용은 InnoDB 모니터 사용 설정을 참조하세요.
성능 스키마 사용
MySQL 성능 스키마는 하위 수준에서 MySQL 서버 실행을 모니터링하는 기능입니다. performance_schema에서 생성된 통계를 사용하는 가장 간단한 방법은 MySQL Workbench 실적 보고서 기능을 사용하는 것입니다.
적절한 수의 데이터베이스 표 유지
데이터베이스 표는 시스템 리소스를 사용합니다. 테이블 수가 많으면 인스턴스 성능과 가용성이 영향을 받을 수 있으며 인스턴스에 SLA가 적용되지 않을 수 있습니다. 자세히 알아보기
일반 성능 팁
. 데이터베이스 삽입, 업데이트, 삭제 속도가 느리면 다음과 같이 조치하는 것이 좋습니다.- 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.
속도가 느린 데이터베이스 선택에는 다음을 고려하세요.
- 캐싱은 읽기 성능에 중요합니다. 데이터 세트 크기를 인스턴스의 RAM 크기와 비교합니다. 전체 데이터 세트가 인스턴스 RAM의 70% 이내인 것이 가장 좋으며, 이렇게 하면 쿼리가 IO 성능으로 제한되지 않습니다. 그렇지 않으면 인스턴스의 RAM 크기를 늘리는 것이 좋습니다.
- 워크로드가 CPU 집약적인 쿼리(정렬, 정규 표현식, 기타 복잡한 함수)로 구성된 경우 인스턴스가 제한될 수 있습니다. 이런 경우에는 vCPU를 늘립니다.
쿼리 실행 성능이 저하되면 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 크기를 줄입니다.
문제 해결
다른 Cloud SQL 문제에 대해서는 문제 해결 페이지를 참조하세요.
오류 메시지
특정 API 오류 메시지는 오류 메시지 참조 페이지를 참조하세요.
고객 관리 암호화 키(CMEK) 문제 해결
Cloud KMS 오류, 역할 또는 권한 누락으로 인해 생성, 클론, 업데이트와 같은 Cloud SQL 관리자 작업이 실패할 수 있습니다. Cloud KMS 키 버전이 누락되거나, Cloud KMS 키 버전이 중지 또는 삭제되거나, Cloud KMS 키 버전에 액세스할 수 있는 IAM 권한이 없거나, Cloud KMS 키 버전이 Cloud SQL 인스턴스와 다른 리전에 있는 경우 등에는 일반적으로 작업이 실패하게 됩니다. 일반적인 문제를 진단하고 해결하려면 다음 문제 해결 표를 사용하세요.
고객 관리 암호화 키 문제 해결 표
| 발생 오류 | 문제 원인 | 해결 방법 |
|---|---|---|
| 제품별, 프로젝트별 서비스 계정을 찾을 수 없음 | 서비스 계정 이름이 잘못되었습니다. | 올바른 사용자 프로젝트의 서비스 계정을 만들었는지 확인합니다.
|
| 서비스 계정에 액세스 권한을 부여할 수 없음 | 사용자 계정에 이 키 버전에 대한 액세스 권한을 부여할 수 있는 권한이 없습니다. | 사용자나 서비스 계정에 조직 관리자 역할을 추가합니다.
|
| Cloud KMS 키 버전이 삭제됨 | 키 버전이 삭제되었습니다. | 키 버전이 삭제되면 데이터를 암호화하거나 복호화하는 데 사용할 수 없습니다. |
| Cloud KMS 키 버전이 사용 중지됨 | 키 버전이 사용 중지되었습니다. | Cloud KMS 키 버전을 다시 사용 설정합니다.
|
| Cloud KMS 키를 사용할 수 있는 권한이 없음 | Cloud SQL 인스턴스에서 작업을 실행하는 데 사용하는 사용자 또는 서비스 계정에 cloudkms.cryptoKeyEncrypterDecrypter 역할이 없거나 Cloud KMS 키 버전이 없습니다. |
키를 호스팅하는 Google Cloud 프로젝트에서 사용자나 서비스 계정에 cloudkms.cryptoKeyEncrypterDecrypter 역할을 추가합니다.
이 역할이 사용자 계정에 이미 부여되었으면 키 만들기를 참조하여 새 키 버전을 만드는 방법을 알아보세요. 참고를 참조하세요. |
| Cloud KMS 키를 찾을 수 없음 | 키 버전이 존재하지 않습니다. | 새 키 버전을 만듭니다. 키 만들기를 참조하세요. 참고를 참조하세요. |
| Cloud SQL 인스턴스와 Cloud KMS 키 버전이 서로 다른 리전에 있음 | Cloud KMS 키 버전과 Cloud SQL 인스턴스는 같은 리전에 있어야 합니다. Cloud KMS 키 버전이 전역 리전 또는 멀티 리전에 있는 경우에는 작동하지 않습니다. | 인스턴스를 만들려는 리전에 키 버전을 만듭니다. 키 만들기를 참조하세요. 참고를 참조하세요. |
| Cloud KMS 키 버전이 복원되었지만 인스턴스가 계속 정지됨 | 키 버전이 중지되었거나 적절한 권한을 부여하지 않습니다. | 키 버전을 다시 사용 설정하고 키를 호스팅하는 Google Cloud 프로젝트의 사용자나 서비스 계정에 cloudkms.cryptoKeyEncrypterDecrypter 역할을 부여합니다. |
다시 암호화 문제 해결 표
| 발생 오류 | 문제 원인 | 해결 방법 |
|---|---|---|
| Cloud KMS 키에 액세스할 수 없으므로 CMEK 리소스 다시 암호화가 실패했습니다. 기본 키 버전이 사용 설정되어 있고 권한이 올바르게 부여되었는지 확인하세요. | 키 버전이 중지되었거나 적절한 권한을 부여하지 않습니다. | Cloud KMS 키 버전을 다시 사용 설정합니다. 키를 호스팅하는 Google Cloud 프로젝트에서 |
| 서버 내부 오류로 인해 CMEK 리소스 다시 암호화가 실패했습니다. 나중에 다시 시도해 주세요. | 서버 내부 오류가 발생했습니다. | 다시 암호화를 재시도합니다. 자세한 내용은 기존 CMEK가 사용 설정된 인스턴스 또는 복제본 다시 암호화를 참조하세요. |