MySQL용 Cloud SQL 문제 해결

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

백업 및 복구

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

문제 설명 문제 원인 해결 방법
현재 작업 상태를 볼 수 없음 사용자 인터페이스에 성공 또는 실패만 표시됩니다. 이 데이터베이스 명령어를 사용하여 자세히 알아보세요.
작업 생성자를 찾을 수 없음 사용자 인터페이스에 작업을 시작한 사용자가 표시되지 않습니다. 감사 로깅을 사용하여 확인하세요.
자동 백업 중 디스크 공간 부족 인스턴스가 하드 디스크 공간 한도에 도달했습니다. 파일 시스템 크기와 할당량을 확인하세요.
인스턴스 삭제 후 백업할 수 없음 인스턴스가 삭제되었습니다. 내보내기에서 다시 만들거나 유예 기간 내인 경우 고객지원에 문의하세요.
자동 백업이 중단된 것으로 보임 백업 시간은 데이터베이스 크기와 관련이 있습니다. 작업을 취소해야 하는 경우 고객지원문의하세요.
복원 실패 덤프 파일에 아직 존재하지 않는 데이터베이스 사용자가 포함되어 있을 수 있습니다. 복원하기 전에 데이터베이스 사용자를 만듭니다.
이 인스턴스에 유효한 작업이 아님 대상 인스턴스 크기가 소스보다 작습니다. 대상 인스턴스 크기를 늘립니다.
자동 백업 보관일 수를 늘리려는 경우 자동 백업은 7개만 보존됩니다. 자체 수동 백업을 관리합니다.
백업 실패 시 알 수 없는 오류 발생 백업이 타임아웃되었을 수 있습니다. 이 플래그를 확인하세요.
백업 실패에 대한 알림 없음 기본 알림이 없습니다. 커스텀 알림을 설정하세요.

현재 작업 상태를 볼 수 없음

Google Cloud Console에서 작업 상태를 확인할 수 없습니다.

문제 원인

Google Cloud Console은 완료 시에만 성공 또는 실패를 보고하며, 경고를 반환하도록 설계되지 않았습니다.

해결 방법

데이터베이스에 연결하고 SHOW WARNINGS를 실행합니다.


작업 생성자를 찾을 수 없음

주문형 백업 작업을 실행한 사용자를 확인하려고 합니다.

문제 원인

Google Cloud Console의 인스턴스 작업 페이지에 작업을 시작한 사용자가 표시되지 않습니다.

해결 방법

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

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • Cloud 감사 로그가 사용 설정된 경우 cloudaudit.googleapis.com/activity도 사용할 수 있습니다.


자동 백업 중 디스크 공간 부족

[ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written. 오류 메시지가 표시됩니다.

문제 원인

자동 백업 중에 인스턴스가 엄격한 한도에 도달했습니다. 백업 중에 사용 가능한 디스크 공간 이상으로 임시 파일이 확장될 수 있습니다.

해결 방법

디스크가 꽉 찼거나 디스크 할당량이 초과됐는지 확인합니다. 수동으로 디스크 크기를 늘리거나 스토리지 자동 증가를 사용 설정할 수 있습니다.


인스턴스 삭제 후 백업할 수 없음

인스턴스를 삭제한 후 백업을 수행할 수 없습니다.

문제 원인

인스턴스가 삭제되었습니다.

해결 방법

  • Cloud SQL 인스턴스 삭제 유예 기간은 4일입니다. 이 시간 동안 고객지원에서 인스턴스를 다시 만들 수 있습니다. 인스턴스가 삭제된 후에는 데이터를 복구할 수 없습니다.
  • 내보내기를 완료한 경우 새 인스턴스를 만든 다음 가져오기를 수행하여 데이터베이스를 다시 만들 수 있습니다. 내보내기는 Cloud Storage에 쓰이고 여기에서 가져오기를 읽습니다.

자동 백업이 중단됨

자동 백업이 장시간 중단되고 취소할 수 없습니다.

문제 원인

데이터베이스 크기에 따라 백업에 오랜 시간이 걸릴 수 있습니다.

해결 방법

작업을 취소해야 하는 경우 고객지원에 인스턴스 force restart를 요청할 수 있습니다.


백업에서 복원 실패

SQL 덤프 파일에 참조된 하나 이상의 사용자가 없으면 복원 작업이 실패할 수 있습니다.

문제 원인

SQL 덤프를 복원하기 전에 객체를 소유하거나 덤프된 데이터베이스의 객체에 대한 권한이 부여된 모든 데이터베이스 사용자가 있어야 합니다. 그렇지 않으면 복원에서 원래 소유권이나 권한으로 객체를 다시 만들지 못합니다.

해결 방법

SQL 덤프에서 복원하기 전에 데이터베이스 사용자를 만듭니다.


이 인스턴스에 유효한 작업이 아님

instances.restoreBackup에 대한 API 호출에서 HTTP Error 400: This operation isn't valid for this instance 오류 메시지가 표시됩니다.

문제 원인

백업 크기(YYGB)보다 스토리지 크기(XXGB)가 작은 인스턴스의 백업에서는 복원할 수 없습니다.

해결 방법

대상 인스턴스를 수정하여 스토리지 크기를 늘립니다.


자동 백업 보관일 수를 늘리려는 경우

자동 백업 보관일 수를 7일에서 30일 이상으로 늘릴 수 있습니다.

문제 원인

백업은 7개만 보관됩니다. 백업은 백업 보관 비용과 크기 때문에 정기적으로 삭제됩니다. 따라서 복원할 수 있는 자동 백업은 현재 표시되는 백업뿐입니다.

해결 방법

백업을 무기한 보관하려면 자동 백업의 경우처럼 삭제되지 않는 주문형 백업을 직접 생성할 수 있습니다. 주문형 백업은 무기한 유지됩니다. 즉, 백업이나 백업이 속한 인스턴스가 삭제될 때까지 유지됩니다. 이러한 유형의 백업은 자동으로 삭제되지 않으므로 결제에 영향을 미칠 수 있습니다.


백업 실패 시 알 수 없는 오류 발생

백업이 실패했으며 Unknown error가 표시됩니다.

문제 원인

백업 생성 시간이 제한 시간인 10분에 도달했습니다. 자동 백업에는 제한 시간이 10분으로 설정되어 있으며 이 시간 안에 백업이 완료되어야 합니다.

해결 방법

백업 생성에 영향을 미치는 플래그는 checkpoint_timeout 플래그와 checkpoint_completion_target 플래그입니다. 백업이 시작되면 slow 체크포인트가 실행되고 checkpoint_completion_targetcheckpoint_timeout을 곱한 값만큼 시간이 소요됩니다.

예를 들면 900 sec * 0.9 sec = 810 sec = 13.5 min입니다. 따라서 제한 시간을 초과합니다. 이 경우 checkpoint_completion_target 값을 낮추면 문제가 해결됩니다.

백업 실패에 대한 알림 없음

자동 백업이 실패했으며 알림을 받지 못했습니다.

문제 원인

자동 백업이 실패하면 Cloud SQL 인스턴스의 Details 페이지에 Operation error 메시지가 표시됩니다. 백업이 실패하면 이메일 알림이 전송되지 않습니다.

해결 방법

Monitoring 알림을 만들거나 Error Reporting 알림을 사용하여 자체 커스텀 알림을 설정하면 됩니다.

클론

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

문제 설명 문제 원인 해결 방법
constraints/sql.restrictAuthorizedNetworks 오류와 함께 클론이 실패합니다. 승인된 네트워크 구성에 의해 차단되었습니다. 다음 옵션 중 하나를 시도합니다.

constraints/sql.restrictAuthorizedNetworks 오류와 함께 클론 실패

constraints/sql.restrictAuthorizedNetworks 오류와 함께 클론이 실패합니다.

문제 원인

클론 작업이 Authorized Networks 구성에 의해 차단되었습니다. Google Cloud Console의 연결 섹션에서 공개 IP 주소에 Authorized Networks가 구성되어 있으며 보안 고려사항으로 인해 클론이 허용되지 않습니다.

해결 방법

가능한 경우 Cloud SQL 인스턴스에서 모든 Authorized Networks 항목을 삭제합니다. 그렇지 않으면 Authorized Networks 항목 없이 복제본을 만듭니다.

연결

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

문제 설명 문제 원인 해결 방법
Aborted connection 패킷을 읽는 중에 오류가 발생하거나 연결이 취소되었습니다. 해결 방법을 참조하세요.
Unauthorized to connect 오류 여러 근본 원인이 있을 수 있습니다. 해결 방법을 참조하세요.
네트워크 연결 실패 프로젝트에서 Service Networking API가 사용 설정되지 않았습니다. 프로젝트에서 Service Networking API를 사용 설정합니다.
Remaining connection slots are reserved 최대 연결 수에 도달했습니다. max_connections 플래그를 늘립니다.
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project 서비스 계정의 네트워킹 권한이 없거나 잘못되었습니다. Service Networking API를 중지했다가 다시 사용 설정합니다.
error x509: certificate is not valid for any names, but wanted to match project-name:db-name. 알려진 문제: 현재 Cloud SQL 프록시 다이얼러는 Go 1.15와 호환되지 않습니다. 해결될 때까지 해결 방법이 나와 있는 GitHub의 토론을 참조하세요.

연결 취소됨

Got an error reading communication packets 또는 Aborted connection xxx to db: DB_NAME 오류 메시지가 표시됩니다.

문제 원인

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

해결 방법

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

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

  1. 지수 백오프. 재시도 간격을 기하급수적으로 늘립니다.
  2. 무작위 백오프도 추가합니다.
이러한 방법을 조합하면 제한을 줄일 수 있습니다.


연결 권한 없음

Unauthorized to connect 오류 메시지가 표시됩니다.

문제 원인

승인은 여러 수준에서 발생하므로 여러 가지 원인이 있을 수 있습니다.

  • 데이터베이스 수준에서 데이터베이스 사용자가 있어야 하며 비밀번호가 일치해야 합니다.
  • 프로젝트 수준에서 사용자에게 올바른 IAM 권한이 없을 수 있습니다.
  • Cloud SQL 수준에서 인스턴스 연결 방법에 따라 근본 원인이 달라질 수 있습니다. 공개 IP를 통해 인스턴스에 직접 연결하는 경우 연결의 소스 IP가 인스턴스의 승인된 네트워크에 있어야 합니다.

    비공개 IP 연결은 기본적으로 허용되지만 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
    

    Cloud SQL 프록시를 통해 연결하는 경우 IAM 권한이 올바르게 설정되었는지 확인합니다.

  • 네트워크 수준에서 Cloud SQL 인스턴스가 공개 IP를 사용하는 경우 연결의 소스 IP가 승인된 네트워크에 있어야 합니다.

해결 방법

  • 사용자 이름과 비밀번호를 확인합니다.
  • 사용자의 IAM 역할과 권한을 확인합니다.
  • 공개 IP를 사용하는 경우 소스가 승인된 네트워크에 있는지 확인합니다.

네트워크 연결 실패

Error: Network association failed due to the following error 오류 메시지가 표시됩니다. 서비스 네트워킹 서비스 계정을 소비자 프로젝트에서 servicenetworking.serviceAgent 역할로 설정합니다.

문제 원인

프로젝트에서 Service Networking API가 사용 설정되지 않았습니다.

해결 방법

프로젝트에서 Service Networking API를 사용 설정합니다. Cloud SQL 인스턴스에 비공개 IP 주소를 할당하려고 하고 공유 VPC를 사용할 때 이 오류가 표시되면 호스트 프로젝트에도 Service Networking API를 사용 설정해야 합니다.


나머지 연결 슬롯이 예약됨

FATAL: remaining connection slots are reserved for non-replication superuser connections 오류 메시지가 표시됩니다.

문제 원인

최대 연결 수에 도달했습니다.

해결 방법

max_connections 플래그 값을 수정합니다.


서비스 네트워킹 서비스 계정을 소비자 프로젝트에서 servicenetworking.serviceAgent 역할로 설정

set Service Networking service account as servicenetworking.serviceAgent role on consumer project. 오류 메시지가 표시됩니다.

문제 원인

사용자 또는 서비스 계정 권한이 올바르지 않습니다. 이 문제는 Terraform 구성 스크립트와 같은 자동 설정 스크립트 중에 발생할 수 있습니다.

해결 방법

서비스 권한을 복구하려면 Service Networking API를 중지하고 5분 정도 기다린 후 다시 사용 설정합니다.

다음 gcloud 명령어를 사용하여 프로젝트에 역할을 할당할 수도 있습니다.

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=project-id
gcloud projects add-iam-policy-binding project-id --member="service-account-prefix@service-networking.iam.gserviceaccount.com" --role="roles/servicenetworking.serviceAgent"

오류 x509: 인증서가 유효한 이름이 없음

error x509: certificate is not valid for any names, but wanted to match project-name:db-name 오류 메시지가 표시됩니다.

문제 원인

알려진 문제: 현재 Cloud SQL 프록시 다이얼러는 Go 1.15와 호환되지 않습니다.

해결 방법

버그가 수정될 때까지 해결 방법이 포함된 GitHub의 토론을 참조하세요.


인스턴스 만들기

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

문제 설명 문제 원인 해결 방법
Internal error 서비스 네트워킹 서비스 계정이 없습니다. Service Networking API를 사용 중지했다가 다시 사용 설정합니다.
Terraform 인스턴스를 만들지 못했습니다. Terraform 구성 오류입니다. Terraform 구성 파일을 검사하고 복구합니다.
Terraform 스크립트에서 HTTP Error 409 발생 다른 작업이 이미 진행 중입니다. Terraform 스크립트를 수정하여 각 작업이 완료될 때까지 기다립니다.
Unknown error 최근 삭제된 인스턴스와 이름이 같은 인스턴스를 만들려고 합니다. 또는 사용 중인 새 비공개 IP 범위로 인스턴스 여러 개를 동시에 만들려고 합니다. 인스턴스에 다른 이름을 사용하거나 인스턴스가 삭제된 후 일주일이 될 때까지 기다립니다. 다른 이름을 사용하여 연속으로 실패한 인스턴스를 다시 만듭니다.

내부 오류

{"ResourceType":"sqladmin.v1beta4.instance", "ResourceErrorCode":"INTERNAL_ERROR","ResourceErrorMessage":null} 오류 메시지가 표시됩니다.

문제 원인

서비스 프로젝트에 이 기능에 필요한 서비스 네트워킹 서비스 계정이 없을 수 있습니다.

해결 방법

서비스 권한을 복구하려면 Service Networking API를 중지하고 5분 정도 기다린 후 다시 사용 설정합니다.


Terraform 인스턴스 만들기 실패

Terraform 인스턴스를 만들지 못했습니다.

문제 원인

일반적으로 Terraform 스크립트 자체 내의 문제입니다.

해결 방법

Terraform 구성 파일을 검사하고 복구합니다.


Terraform 스크립트에서 409 오류 발생

Terraform 스크립트에 HTTP Error 409 오류 메시지가 표시됩니다.

문제 원인

Operation failed because another operation was already in progress

해결 방법

스크립트를 수정하여 각 인스턴스 작업이 완료될 때까지 실행을 중지합니다. 스크립트를 폴링하고 이전 작업 ID로 200이 반환될 때까지 기다린 후에 다음 단계로 진행합니다.


알 수 없는 오류

인스턴스를 만들려고 할 때 Cloud SQL creation failed, error UNKNOWN과 같은 오류 메시지가 표시됩니다.

문제 원인

최근에 삭제한 인스턴스의 이름을 다시 사용하려는 경우일 수 있습니다. 삭제한 인스턴스 이름은 일주일 동안 다시 사용할 수 없습니다. 또는 첫 번째 인스턴스만 생성되고 다른 인스턴스는 Unknown error와 함께 실패한 경우 새 비공개 IP 범위를 사용하여 인스턴스 여러 개를 동시에 만들려고 합니다.

해결 방법

인스턴스에 다른 이름을 사용하거나 일주일 후에 원래 이름을 사용하여 새 인스턴스를 만듭니다. 동시에 여러 인스턴스를 연속으로 만듭니다.

외부 기본

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

,
문제 설명 문제 원인 해결 방법
Specified key was too long; max key length is 767 bytes. 외부 기본 인스턴스에는 innodb_large_prefix 변수가 설정되어 있을 수 있습니다. 복제본을 만들 때 ON으로 innodb_large_prefix 플래그를 설정하거나 기존 복제본을 플래그로 업데이트합니다.
Table definition has changed. 덤프 프로세스 중에 데이터 정의 언어(DDL)가 변경되었습니다. 덤프 프로세스 중에 DDL 변경을 방지합니다.
Access denied; you need (at least one of) the SUPER privilege(s) for this operation. 데이터베이스에 Cloud SQL에서 지원하지 않는 방식으로 DEFINER를 참조하는 뷰, 함수 또는 프로시져가 있을 수 있습니다. Cloud SQL의 DEFINER 사용에 대한 자세한 정보를 참조하세요.
Lost connection to MySQL server during query when dumping table. 소스를 사용할 수 없거나 덤프가 너무 큰 패킷을 포함하고 있을 수 있습니다. 외부 기본 프로젝트를 연결할 수 있는지 확인하거나 max_allowed_packet 옵션으로 mysqldump를 사용합니다.
Got packet bigger than 'max_allowed_packet' bytes when dumping table. 패킷이 설정에서 허용하는 것보다 큽니다. max_allowed_packet 옵션으로 mysqldump를 사용합니다.
초기 데이터 마이그레이션이 성공했지만 복제 중인 데이터가 없습니다. 충돌하는 복제 플래그가 있을 수 있습니다. 이러한 플래그 설정을 확인하세요.
초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다. 여러 가지 원인이 있을 수 있습니다. 이러한 방법을 시도해 보세요.
mysqld check failed: data disk is full. 복제본 인스턴스의 데이터 디스크가 가득 찼습니다. 복제본 인스턴스의 디스크 크기를 늘립니다. 수동으로 디스크 크기를 늘리거나 스토리지 자동 증가를 사용 설정할 수 있습니다.

지정된 키가 너무 깁니다. 최대 키 길이는 767바이트입니다.

Specified key was too long; max key length is 767 bytes. 오류가 표시됩니다.

문제 원인

외부 기본 인스턴스에는 innodb_large_prefix 변수가 설정되어 있을 수 있습니다. 이렇게 하면 767바이트보다 긴 색인 키 프리픽스가 허용됩니다. MySQL 5.6의 기본값은 OFF입니다.

해결 방법

복제본을 만들 때 innodb_large_prefix 플래그를 ON으로 설정하거나 기존 복제본을 플래그로 업데이트합니다.


테이블 정의가 변경됨

Table definition has changed 오류가 표시됩니다.

문제 원인

덤프 프로세스 중에 DDL이 변경되었습니다.

해결 방법

덤프 프로세스 중에 테이블을 수정하거나 다른 DDL 변경을 수행하지 마세요.


액세스 거부됨. 이 작업에 대한 SUPER 권한(하나 이상)이 필요합니다.

Access denied; you need (at least one of) the SUPER privilege(s) for this operation 오류가 표시됩니다.

문제 원인

근본 원인은 고객이 super user@localhost(예: root@localhost)를 사용하는 DEFINER와 함께 VIEW/FUNCTION/PROCEDURE를 가지고 있기 때문일 수 있습니다. 이는 Cloud SQL에서는 지원되지 않습니다.

해결 방법

해결 방법은 외부 데이터베이스에서 Definer를 업데이트하는 것입니다. 예를 들어 root@localhost에서 root@% 또는 비 수퍼유저가 있습니다. 자세한 내용은 저장된 객체 액세스 제어를 참조하세요.


테이블을 덤프할 때 쿼리 중에 MySQL 서버와의 연결이 끊어졌습니다.

Lost connection to MySQL server during query when dumping table 오류가 표시됩니다.

문제 원인

  • 소스가 복제본에서 연결할 수 없게 되었을 수 있습니다.

  • 소스 데이터베이스에는 소스 데이터베이스에서 max_allowed_packet을 더 큰 수로 설정해야 하는 큰 blob 또는 긴 문자열이 있는 테이블이 있을 수 있습니다.

해결 방법

  • 다시 시작하고 외부 기본을 연결할 수 있는지 확인합니다.

  • mysqldump를 max_allowed_packet 옵션과 함께 사용하여 데이터를 덤프하고 덤프 파일로 마이그레이션합니다.


테이블을 덤프할 때 'max_allowed_packets' 바이트보다 큰 패킷이 있습니다.

Got packet bigger than 'max_allowed_packet' bytes when dumping table 오류가 표시됩니다.

문제 원인

패킷이 설정에서 허용하는 것보다 큽니다.

해결 방법

mysqldump를 max_allowed_packet 옵션과 함께 사용하여 데이터를 덤프하고 덤프 파일로 마이그레이션합니다.


복제되는 데이터가 없습니다.

초기 데이터 마이그레이션이 성공했지만 복제 중인 데이터가 없습니다.

문제 원인

한 가지 가능한 근본 원인은 소스 데이터베이스에서 복제 플래그를 정의하여 일부 또는 전체 데이터베이스 변경사항이 복제되지 않기 때문일 수 있습니다.

해결 방법

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

기본 인스턴스에서 show master status 명령어를 실행하여 현재 설정을 확인합니다.


초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다.

초기 데이터 마이그레이션에 성공했지만 얼마 후 데이터 복제가 더 이상 작동하지 않습니다.

문제 원인

이 문제의 근본 원인은 여러 가지가 있을 수 있습니다.

해결 방법

  • Cloud Monitoring UI에서 복제본 인스턴스의 복제 측정항목을 확인합니다.

  • MySQL IO 스레드 또는 SQL 스레드의 오류는 mysql.err 로그 파일의 Cloud Logging에서 확인할 수 있습니다.

  • 이 오류는 복제본 인스턴스에 연결할 때도 찾을 수 있습니다. SHOW SLAVE STATUS 명령어를 실행하고 출력에서 다음 필드를 확인합니다.

    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

mysqld 확인 실패: 데이터 디스크가 가득 찼습니다.

mysqld check failed: data disk is full 오류가 표시됩니다.

문제 원인

DRAIN 작업 중에 이 오류가 발생하면 복제본 인스턴스의 데이터 디스크가 가득 찬 것입니다.

해결 방법

복제본 인스턴스의 디스크 크기를 늘립니다.

플래그

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

문제 설명 문제 원인 해결 방법
문자 집합 utf8mb4가 있는 데이터 이 문자 집합은 지원되지 않습니다. 데이터에서 utf8mb4 문자열을 필터링하세요.
플래그를 사용 설정하면 인스턴스가 비정상 종료됩니다. max_connections 플래그 값이 너무 높게 설정되었을 수 있습니다. 고객 지원팀에 문의하여 플래그 삭제를 요청하세요.
performance_schema 플래그를 추가할 수 없음 인스턴스 크기가 너무 작음 더 큰 인스턴스로 업데이트하세요.
시간대가 자동으로 변경되지 않습니다. 자동 시간대 변경은 지원되지 않습니다. 시간은 수동으로 변경해야 합니다. 자세히 알아보기
Bad syntax for dict arg. 복잡한 매개변수 값을 특수 처리해야 합니다. 자세히 알아보기

문자 집합 utf8mb4가 있는 데이터

문자 집합 utf8mb4가 있는 데이터를 가져올 수 없습니다.

문제 원인

문자 집합 utf8mb4는 이전 매뉴얼에 지원된다고 나와 있었지만 지금은 지원되지 않습니다.

해결 방법

데이터에서 utf8mb4 문자열을 필터링합니다.


플래그를 사용 설정하면 인스턴스가 비정상 종료됨

플래그를 사용 설정한 후 인스턴스가 공황과 비정상 종료 간에 순환됩니다.

문제 원인

max_connections 플래그 값을 너무 높게 설정하면 이 오류가 발생합니다.

해결 방법

고객지원에 연락하여 플래그 삭제 후 hard drain을 요청합니다. 이렇게 하면 원하지 않는 플래그 또는 설정 없이 새 구성으로 인스턴스가 다른 호스트에서 강제로 다시 시작됩니다.


performance_schema 플래그를 추가할 수 없음

지원되는 플래그의 드롭다운 메뉴에 없어서 performance_schema 플래그를 추가할 수 없습니다.

문제 원인

performance_schema 및 그 변형(performance_schema_accounts_size, performance_schema_accounts_size 등)은 db-n1-standard-8 또는 db-n1-highmem-4보다 작은 인스턴스에서는 사용 설정할 수 없습니다.

해결 방법

이 플래그를 사용해야 하는 경우 인스턴스를 수정하여 더 큰 크기로 업그레이드하세요.


시간대가 자동으로 변경되지 않음

시간대가 일광 절약 시간에 맞추어 자동으로 변경되지 않았습니다.

문제 원인

Cloud SQL에서는 자동 시간대 변경이 지원되지 않으며 문자열이 아니라 시간대 오프셋 값을 이용해 수동으로 변경해야 합니다.

해결 방법

인스턴스를 수정하여 default_time_zone 플래그를 변경합니다. 이름이 지정된 영역은 지원되지 않습니다. 예를 들어 Europe/London런던은 UTC 시간대이며 default_time_zone 플래그에 지원되는 +00:00 값입니다.


dict argument의 잘못된 구문

플래그를 설정하려고 하면 오류 메시지 Bad syntax for dict arg가 표시됩니다.

문제 원인

쉼표로 구분된 목록과 같은 복잡한 매개변수 값은 gcloud 명령어에 사용할 때 특수 처리되어야 합니다.

해결 방법

복잡한 플래그 값에 유용한 --flag:value 사전이 포함된 YAML 또는 JSON 파일을 지정하는 gcloud --flags-file 매개변수를 사용합니다.

고가용성

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

문제 설명 문제 원인 해결 방법
수동 장애 조치에 대한 측정항목을 찾을 수 없음 자동 장애 조치만 측정항목에 포함됩니다. 해당 사항 없음
CPU 및 RAM 사용량이 거의 100%임 인스턴스 머신 크기가 부하에 비해 너무 작습니다. 인스턴스 머신 크기를 업그레이드합니다.

수동 장애 조치에 대한 측정항목을 찾을 수 없음

수동 장애 조치를 수행했지만 자동 장애 조치 측정항목의 측정 항목 탐색기에서 해당 항목을 찾을 수 없습니다.

문제 원인

자동 장애 조치만 측정항목에 포함됩니다. 수동으로 시작된 장애 조치는 포함되지 않습니다.

해결 방법

해당 사항 없음


CPU 및 RAM 사용량이 거의 100%임

Cloud SQL 인스턴스 리소스(CPU 및 RAM) 사용량이 거의 100%여서 고가용성 인스턴스가 다운됩니다.

문제 원인

인스턴스 머신 크기가 부하에 비해 너무 작습니다.

해결 방법

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

가져오기 및 내보내기

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

문제 설명 문제 원인 해결 방법
작업 상태를 볼 수 없음 사용자 인터페이스에 성공 또는 실패만 표시됩니다. 이 데이터베이스 명령어를 사용하여 자세히 알아보세요.
내보내기 도중 408 Error (Timeout) 발생 데이터베이스 크기와 내보내기 콘텐츠에 따라 SQL 내보내기가 오래 걸릴 수 있습니다. 여러 CSV 내보내기를 사용하여 각 작업의 크기를 줄입니다.
CSV 내보내기에 성공했지만 SQL 내보내기에 실패했습니다. SQL 내보내기는 Cloud SQL과의 호환성 문제가 발생할 가능성이 높습니다. CSV 내보내기를 사용하여 필요한 항목만 내보냅니다.
내보내기가 너무 오래 걸림 Cloud SQL은 동시 동기 작업을 지원하지 않습니다. 내보내기 오프로딩을 사용합니다. 자세히 알아보기
가져오는 데 시간이 너무 오래 걸림 활성 연결이 너무 많으면 가져오기 작업을 방해할 수 있습니다. 사용하지 않는 연결을 끊거나 Cloud SQL 인스턴스를 다시 시작한 후 가져오기 작업을 시작합니다.
Error 1412: Table definition has changed. 내보내기 중에 테이블이 변경되었습니다. 덤프 작업에서 테이블 변경 문을 삭제합니다.
가져오기 실패 내보낸 파일에 아직 존재하지 않는 데이터베이스 사용자가 포함되어 있을 수 있습니다. 가져오기 전에 데이터베이스 사용자를 만듭니다.
내보내기 작업 중에 연결이 종료되었습니다. 쿼리는 처음 7분 이내에 데이터를 생성해야 합니다. 쿼리를 수동으로 테스트합니다. 자세히 알아보기
내보내는 중에 알 수 없는 오류 발생 대역폭 문제일 수 있습니다. 인스턴스와 Cloud Storage 버킷이 동일한 리전에 있는지 확인합니다.
내보내기를 자동화하려고 합니다. Cloud SQL은 내보내기를 자동화하는 방법을 제공하지 않습니다. 이 기능을 수행하려면 자체 파이프라인을 빌드하세요. 자세히 알아보기
ERROR_RDBMS: system error occurred Cloud Storage 권한 또는 존재하지 않는 테이블 문제입니다. 권한을 확인하거나 테이블이 존재하는지 확인합니다.
가져오기 중 오류 발생: 테이블이 존재하지 않음 현재 필수 테이블이 존재하지 않습니다. 가져오기 시작 시 FOREIGN_KEY_CHECKS를 사용 중지합니다.

작업 상태를 볼 수 없음

진행 중인 작업의 상태를 볼 수 없습니다.

문제 원인

Google Cloud Console은 완료 시에만 성공 또는 실패를 보고하며, 경고를 반환하도록 설계되지 않았습니다.

해결 방법

데이터베이스에 연결하고 SHOW WARNINGS를 실행합니다.


내보내기 중 408 오류(시간 초과) 발생

Cloud SQL에서 내보내기 작업을 수행하는 동안 408 Error (Timeout) 오류 메시지가 표시됩니다.

문제 원인

CSV 형식과 SQL 형식은 내보내기 방식이 서로 다릅니다. SQL 형식은 전체 데이터베이스를 내보내며 완료하는 데 더 오래 걸릴 수 있습니다. CSV 형식은 내보내기에 포함할 데이터베이스 요소를 정의할 수 있습니다.

해결 방법

CSV 형식을 사용하고 여러 개의 작은 내보내기 작업을 실행하여 각 작업의 크기와 길이를 줄입니다.


CSV 내보내기에 성공했지만 SQL 내보내기에 실패

CSV 내보내기에 성공했지만 SQL 내보내기에 실패했습니다.

문제 원인

CSV 형식과 SQL 형식은 내보내기 방식이 서로 다릅니다. SQL 형식은 전체 데이터베이스를 내보내며 완료하는 데 더 오래 걸릴 수 있습니다. CSV 형식은 내보내기에 포함할 데이터베이스 요소를 정의할 수 있습니다.

해결 방법

CSV 내보내기를 사용하여 필요한 항목만 내보냅니다.


내보내기가 너무 오래 걸림

내보내기 시간이 너무 오래 걸려 다른 작업이 차단됩니다.

문제 원인

Cloud SQL은 동시 동기 작업을 지원하지 않습니다.

해결 방법

한 번에 내보내는 데이터 세트 크기를 줄여보세요.


가져오는 데 시간이 너무 오래 걸림

가져오는 데 시간이 너무 오래 걸려 다른 작업이 차단됩니다.

문제 원인

활성 연결이 너무 많으면 가져오기 작업을 방해할 수 있습니다. 연결은 CPU와 메모리를 소비하므로 사용 가능한 리소스가 제한됩니다.

해결 방법

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

  • 모든 연결이 끊깁니다.
  • 리소스를 소비할 수 있는 모든 태스크가 종료됩니다.


mysqldump: 오류 1412: 테이블 정의가 변경됨

mysqldump: Error 1412: Table definition has changed, retry transaction when dumping the table 오류 메시지가 표시됩니다.

문제 원인

내보내기 프로세스 중에 테이블이 변경되었습니다.

해결 방법

내보내기 작업 중에 다음 문을 사용하면 덤프 트랜잭션이 실패할 수 있습니다.

  • ALTER TABLE
  • CREATE TABLE
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
덤프 작업에서 이러한 문을 삭제합니다.


가져오기 실패

내보낸 SQL 덤프 파일에 참조된 하나 이상의 사용자가 없으면 가져오기가 실패합니다.

문제 원인

SQL 덤프를 가져오기 전에 객체를 소유하거나 덤프된 데이터베이스의 객체에 대한 권한이 부여된 모든 데이터베이스 사용자가 있어야 합니다. 그렇지 않으면 복원에서 원래 소유권이나 권한으로 객체를 다시 만들지 못합니다.

해결 방법

SQL 덤프를 가져오기 전에 데이터베이스 사용자를 만듭니다.


내보내기 작업 중에 연결이 종료됨

내보내기 작업 중에 연결이 종료되었습니다.

문제 원인

내보내기에서 실행되는 쿼리가 내보내기 시작 후 처음 7분 이내에 데이터를 생성하지 않아서 Cloud Storage 연결이 시간 초과될 수 있습니다.

해결 방법

클라이언트에서 연결하고 아래 명령어로 쿼리 출력을 STDOUT에 전송하여 쿼리를 수동으로 테스트합니다.

COPY (INSERT_YOUR_QUERY_HERE) TO STDOUT WITH ( FORMAT csv, DELIMITER ',', ENCODING 'UTF8', QUOTE '"', ESCAPE '"' )

내보내기가 시작되면 클라이언트가 즉시 데이터 전송을 시작할 것으로 예상되므로 이는 예상된 문제입니다. 전송 데이터가 없는 연결을 유지하면 연결이 끊기고 결국 내보내기에 실패하여 작업이 불확실한 상태가 됩니다. gcloud의 오류 메시지 또한 다음 메시지를 통해 이런 내용을 전달하고자 합니다.

operation is taking longer than expected


내보내는 중에 알 수 없는 오류 발생

데이터베이스를 Cloud Storage 버킷으로 내보내려고 할 때 Unknown error 오류 메시지가 표시됩니다.

문제 원인

대역폭 문제로 인해 전송이 실패할 수 있습니다.

해결 방법

Cloud SQL 인스턴스가 Cloud Storage 버킷과 다른 리전에 있을 수 있습니다. 한 대륙에서 데이터를 읽어 다른 대륙에 쓰려면 많은 네트워크 사용량이 필요하며, 이러한 간헐적인 문제를 일으킬 수 있습니다. 인스턴스와 버킷의 리전을 확인합니다.


내보내기를 자동화하려는 경우

내보내기를 자동화하려고 합니다.

문제 원인

Cloud SQL은 내보내기를 자동화하는 방법을 제공하지 않습니다.

해결 방법

Google Cloud 제품(Cloud Scheduler, Pub/Sub, Cloud Functions)을 사용하여 자체 자동 내보내기 시스템을 빌드할 수 있습니다.


ERROR_RDBMS 시스템 오류 발생

[ERROR_RDBMS] system error occurred 오류 메시지가 표시됩니다.

문제 원인

  • 사용자에게 필요한 일부 Cloud Storage 권한이 없을 수 있습니다.
  • 데이터베이스 테이블이 없을 수 있습니다.

해결 방법

  1. 최소한 버킷에 대한 WRITER 권한과 내보내기 파일에 대한 READER 권한이 있는지 확인합니다. Cloud Storage에서 액세스 제어를 구성하는 방법에 대한 자세한 내용은 액세스제어 목록 만들기 및 관리를 참조하세요.
  2. 테이블이 있는지 확인합니다. 테이블이 있다면 버킷에 대한 올바른 권한이 있는지 확인합니다.

가져오기 중 오류 발생: 테이블이 존재하지 않음

테이블이 존재하지 않는다는 오류와 함께 가져오기 작업이 실패합니다.

문제 원인

테이블은 다른 테이블의 외래 키 종속 항목을 가질 수 있으며, 작업 순서에 따라 이러한 테이블 중 하나 이상이 가져오기 작업 도중에는 아직 존재하지 않을 수 있습니다.

해결 방법

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

  SET FOREIGN_KEY_CHECKS=0;

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

  SET FOREIGN_KEY_CHECKS=1;

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

로깅

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

문제 설명 문제 원인 해결 방법
로깅이 CPU와 메모리를 많이 사용합니다. 로깅을 조정해야 합니다. 로깅 리소스 사용량을 조정해 보세요.
감사 로그를 찾을 수 없음 사용자 인증 문제입니다. 사용자 역할 및 권한을 확인합니다.
로그에 작업 정보가 없음 감사 로그가 사용 설정되지 않았습니다. 감사 로깅을 사용 설정합니다.
Logging이 디스크 공간을 많이 사용함 재실행 로그, 바이너리 로그, 일반 로그가 디스크 공간을 사용합니다. 이 명령어를 실행하여 디스크 사용량 세부정보를 가져오세요.

Logging이 CPU와 메모리를 많이 사용함

로깅이 CPU와 메모리를 많이 사용합니다.

문제 원인

로깅 사용량을 조정해야 합니다.

해결 방법

log_statement 플래그를 '없음'으로 설정하고 logging_collector 플래그를 '꺼짐'으로 설정할 수 있습니다. 로깅이 계속 발생하는 경우 조정할 수 있는 다른 로그 관련 플래그가 있을 수 있습니다. 인스턴스를 수정하여 이러한 플래그를 수정할 수 있습니다.


감사 로깅

Cloud SQL의 감사 로깅을 사용 설정했지만 Cloud Logging에서 감사 로그를 찾을 수 없습니다.

문제 원인

데이터 액세스 로그는 작업이 사용자가 만든 데이터를 생성 또는 수정하거나 읽는 인증된 사용자 주도 API 호출인 경우 또는 작업이 리소스의 구성 파일 또는 메타데이터에 액세스하는 경우에만 작성됩니다.

해결 방법

작업을 수행하는 사용자의 역할과 권한을 확인합니다.


로그에서 작업 정보를 찾을 수 없음

작업에 대한 자세한 정보를 찾으려 합니다. 예를 들어 사용자가 삭제되었는데 누가 삭제했는지 알 수 없습니다. 로그는 작업이 시작되었음을 표시하지만 그 이상의 정보를 제공하지 않습니다.

문제 원인

이와 같은 자세한 개인 식별 정보(PII)를 로깅하려면 감사 로깅을 사용 설정해야 합니다.

해결 방법

프로젝트에서 감사 로깅을 사용 설정합니다.


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;

인스턴스 관리

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

문제 설명 문제 원인 해결 방법
다시 시작 후 성능이 저하됩니다. 다시 시작되면 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 Storage로 내보내기를 수행하여 데이터 손실을 방지합니다.

재시작 후 성능 저하

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

문제 원인

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) 리소스가 서로 다른 리전에 있는 경우의 네트워크 지연 시간입니다.

해결 방법

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

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

  • long_query_time 플래그를 사용 설정하면 로그에서 속도가 느린 쿼리를 확인할 수 있습니다. 프로젝트의 로그 탐색기 페이지로 이동하여 다음과 같이 쿼리를 실행합니다.
    resource.type="cloudsql_database"
    resource.labels.database_id="INSTANCE-ID"
    log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        
  • 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.
  • 리더 및 데이터베이스의 위치를 확인합니다. 지연 시간은 쓰기 성능보다 읽기 성능에 더 많은 영향을 미칩니다.
지연 시간을 줄이려면 소스 리소스와 대상 리소스를 동일한 리전에 두는 것이 좋습니다.


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

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

문제 원인

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

해결 방법

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


삭제된 인스턴스 복구

인스턴스가 의도적으로 또는 실수로 삭제된 경우 삭제를 취소할 수 없습니다.

문제 원인

인스턴스를 삭제하면 백업을 포함한 인스턴스의 모든 데이터가 영구 삭제됩니다.

해결 방법

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

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

복제

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

문제 설명 문제 원인 해결 방법
생성 시 읽기 복제본이 복제를 시작하지 않았습니다. 바이너리 로깅이 사용 설정된 후에 백업이 최소 한 개 이상 생성되어 있어야 합니다. 바이너리 로그를 사용 설정한 후 백업이 하나 이상 생성될 때까지 기다립니다.
읽기 복제본을 만들 수 없음 - 알 수 없는 오류 여러 근본 원인이 있을 수 있습니다. 로그에서 자세한 내용을 확인하세요.
디스크가 가득 참 복제본을 만드는 동안 기본 인스턴스 디스크 크기가 가득 찰 수 있습니다. 기본 인스턴스를 더 큰 디스크 크기로 업그레이드합니다.
복제본 인스턴스가 너무 많은 메모리를 사용 복제본은 자주 요청되는 읽기 작업을 캐시할 수 있습니다. 임시 메모리 공간을 회수하려면 복제본 인스턴스를 다시 시작합니다.
복제가 중지되었습니다. 최대 저장공간에 도달했고 저장용량 자동 증가가 사용 설정되지 않았습니다. 스토리지 자동 증가를 사용 설정합니다.
긴 복제 지연 시간이 지속적으로 발생합니다. 다양한 근본 원인이 있을 수 있습니다. 여기에서 몇 가지 해결 방법을 확인하세요.

생성 시 읽기 복제본이 복제를 시작하지 않음

생성 시 읽기 복제본이 복제를 시작하지 않았습니다.

문제 원인

기본 인스턴스에는 적어도 일주일 동안의 binlog가 있어야 합니다. 그렇지 않으면 복제본이 복제를 시작할 수 없습니다.

해결 방법

충분한 binlog가 생성될 때까지 기다립니다.


읽기 복제본을 만들 수 없음 - 알 수 없는 오류

읽기 복제본을 만들 수 없음 - unknown error.

문제 원인

로그 파일에 더 구체적인 오류가 있을 수 있습니다.

해결 방법

Cloud Logging의 로그를 검사하여 실제 오류를 찾습니다. 오류가 set Service Networking service account as servicenetworking.serviceAgent role on consumer project이면 Service Networking API를 사용 중지했다가 다시 사용 설정합니다. 이렇게 하면 프로세스를 계속 진행하는 데 필요한 서비스 계정이 생성됩니다.


디스크가 가득 참

UPDATE_DISK_SIZE 또는 mysqld: disk is full 오류

문제 원인

복제본을 만드는 동안 기본 인스턴스 디스크 크기가 가득 찰 수 있습니다.

해결 방법

기본 인스턴스를 수정하여 더 큰 디스크 크기로 업그레이드합니다.


복제본 인스턴스가 너무 많은 메모리를 사용

복제본 인스턴스가 너무 많은 메모리를 사용하고 있습니다.

문제 원인

복제본은 임시 메모리를 사용하여 자주 요청되는 읽기 작업을 캐시하므로 기본 인스턴스보다 더 많은 메모리를 사용할 수 있습니다.

해결 방법

복제본 인스턴스를 다시 시작하여 임시 메모리 공간을 회수합니다.


복제 중지됨

복제가 중지되었습니다.

문제 원인

최대 저장용량 한도에 도달했고 >automatic storage increase is disabled.

해결 방법

인스턴스를 수정하여 automatic storage increase를 사용 설정합니다.


긴 복제 지연 시간이 지속적으로 발생함

긴 복제 지연 시간이 지속적으로 발생합니다.

문제 원인

쓰기 부하가 너무 높아 복제본이 처리할 수 없습니다. 복제본의 SQL 스레드가 IO 스레드를 따라잡을 수 없는 경우 복제 지연이 발생합니다. 일부 쿼리 또는 워크로드로 인해 특정 스키마에서 일시적이거나 영구적인 복제 지연이 발생할 수 있습니다. 복제 지연이 발생하는 일반적인 원인은 다음과 같습니다.

  • 복제본에 대한 쿼리의 속도가 느립니다. log_slow_slave_statements를 사용 설정하여 이러한 쿼리를 검색한 후 수정하면 됩니다.
  • 모든 테이블에 고유/기본 키가 있어야 합니다. 테이블에 고유/기본 키가 없으면 업데이트할 때마다 복제본에서 전체 테이블 검사를 수행해야 합니다.
  • DELETE ... WHERE field < 50000000과 같은 쿼리의 경우 복제본에 다수의 업데이트가 쌓이게 되므로 행 기준 복제에서 복제 지연이 발생합니다.

해결 방법

가능한 해결책은 다음과 같습니다.

  • 인스턴스를 수정하여 복제본 크기를 늘립니다.
  • 데이터베이스의 부하를 줄입니다.
  • 테이블 색인을 생성합니다.
  • 느린 쿼리를 찾아 수정합니다.
  • 복제본을 다시 만듭니다.