Cloud SQL 인스턴스 문제 진단

이 페이지에서는 Cloud SQL 인스턴스로 작업할 때 가장 자주 발생하는 문제의 목록과 해결 방법을 설명합니다. 알려진 문제 페이지도 검토하는 것이 좋습니다. 여기에 나온 정보로도 문제가 해결되지 않는 경우 지원 개요를 참조하여 추가 도움을 받으세요.

로그 보기

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

인스턴스가 응답하지 않음

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

연결 문제

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

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

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

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

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

1세대 인스턴스의 경우 연결 페이지에 표시된 클라이언트 인증서의 만료일도 확인해야 합니다. 해당 인증서가 만료된 경우 SSL을 사용하여 인스턴스에 연결하기 전에 새로운 클라이언트 인증서를 생성해야 합니다.

연결 권한이 있는지 확인

연결에 실패하면 연결 권한이 있는지 확인해야 합니다.

  • App Engine 표준 환경에서 1세대 인스턴스에 연결하는 경우 App Engine 애플리케이션에 Cloud SQL 인스턴스 연결 권한이 있는지 확인해야 합니다.
  • 예를 들어 온프레미스 환경에서 mysql 클라이언트를 사용해 연결하는 등 IP 주소를 사용하여 연결하는 데 문제가 있는 경우 연결 시 사용하는 IP 주소에 Cloud SQL 인스턴스 연결 권한이 있는지 확인합니다. 현재 IP 주소를 확인하세요.
  • gcloud sql connect를 사용하여 인스턴스에 연결합니다. 이 명령어는 짧은 기간 동안 IP 주소를 인증합니다. Cloud SDK 및 mysql 클라이언트가 설치된 환경에서 이 작업을 실행할 수 있습니다. Cloud Shell에서도 이 명령어를 실행할 수 있습니다. Cloud Shell은 Google Cloud Platform 콘솔에서 사용할 수 있으며 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는 App Engine의 1세대 인스턴스에 연결되지만 일부 내부 Cloud SQL 프로세스에서도 이 경로를 사용합니다.

연결 한도 이해

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

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

연결 및 스레드 표시

'너무 많은 연결' 오류 메시지가 표시되거나 인스턴스의 상황을 파악하려는 경우 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 인스턴스와 Cloud SQL 인스턴스 간의 연결에 오랫동안 사용되지 않은 연결이 있다고 예상되는 경우 Compute Engine 인스턴스와의 연결이 10분 동안 비활성 상태로 지속되면 제한 시간이 초과된다는 점에 유의해야 합니다. 자세한 내용은 Compute Engine 문서의 네트워킹 및 방화벽을 참조하세요.

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

# Display the current tcp_keepalive_time value.
cat /proc/sys/net/ipv4/tcp_keepalive_time

# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

# Apply the change.
sudo /sbin/sysctl --load=/etc/sysctl.conf

# Display the tcp_keepalive_time value to verify the change was applied.
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 브리지 네트워크용으로 예약되어 있습니다.

인스턴스 문제

백업

데이터베이스 표가 10,000개 이상인 경우 1세대 인스턴스의 백업이 실패할 수 있습니다. 최상의 성능을 위해 표의 개수를 적정하게 유지하세요.

가져오기 및 내보내기

Cloud SQL의 가져오기 및 내보내기는 mysqldump 유틸리티를 사용할 때와 동일합니다. 단, Cloud SQL 가져오기/내보내기 기능의 경우 Cloud Storage 버킷을 사용하여 데이터를 전송한다는 점이 다릅니다. 데이터베이스 하나, 모든 인스턴스 데이터베이스, 선택한 데이터를 CSV 형식으로 가져오고 내보낼 수 있습니다.

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

  • 1세대 인스턴스에 대한 작업은 24시간으로 제한됩니다.
  • 장기 실행 작업은 중지할 수 없습니다.

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

다음 방법 중 하나를 사용하여 단일 작업에 소요되는 시간을 줄일 수 있습니다.

  • Cloud SQL의 가져오기 및 내보내기 기능을 사용하여 24시간 이내에 완료할 수 있는 소량의 데이터만 처리합니다.

  • Cloud SQL 가져오기 또는 내보내기 기능을 사용하지 않고 덤프 파일을 Cloud SQL로 직접 재생합니다. 예를 들어 cloudsql-import를 사용하면 MySQL 연결을 통해 mysqldump 파일을 재생하여 가져오기 작업을 수행할 수 있습니다. cloudsql-import는 연결 실패 및 인스턴스 다시 시작을 복원할 수 있습니다.

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

  • 가져오기 시 충돌이 일어난다면 메모리 부족(OOM) 오류가 원인일 수 있습니다. 이러한 경우 --extended-insert=FALSE --complete- insert 매개변수를 추가해볼 수 있습니다. 이렇게 하면 가져오기 속도가 감소하지만 필요한 메모리의 양도 감소합니다.

디스크 공간

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

데이터 손상 방지

생성된 열 사용 방지

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

정상적인 종료

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

데이터베이스 엔진

InnoDB는 MyISAM 같은 MySQL 저장소 엔진보다 테이블 손상에 더 강하기 때문에 2세대 인스턴스에 유일하게 지원되는 저장소 엔진입니다.

기본적으로 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)

모든 2세대 인스턴스는 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 Platform Console의 결제 페이지에서 프로젝트를 선택하고 프로젝트에 사용된 결제 계정 정보를 조회하여 프로젝트 결제 정보를 확인할 수 있습니다. 결제 문제를 해결하면 인스턴스가 몇 시간 내에 실행 가능 상태로 돌아갑니다.

  • 법적 문제

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

  • 운영 문제

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

결제 문제로 인해 정지가 트리거된 경우 인스턴스가 정지되어 있는 동안에도 인스턴스 관련 정보를 확인하거나 인스턴스를 삭제할 수 있습니다.

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

성능

쿼리 로그 사용 설정

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

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

잠금 모니터링 사용 설정

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

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

SHOW ENGINE INNODB STATUS\G

모니터 출력의 각 섹션에 대한 설명은 InnoDB 표준 모니터 및 잠금 모니터 출력을 참조하세요.

출력이 정기적으로 파일이나 표로 생성되도록 InnoDB 모니터를 사용 설정할 수 있으며, 이 경우 성능이 저하됩니다. 자세한 내용은 InnoDB 모니터 사용 설정을 참조하세요.

적절한 수의 데이터베이스 표 유지

데이터베이스 표는 시스템 리소스를 사용합니다. 그 수가 매우 많을 경우 인스턴스 성능과 가용성에 영향을 미칠 수 있으며 인스턴스에 SLA가 적용되지 않을 수 있습니다. 자세히 알아보기

일반적인 성능 도움말

  • 1세대 인스턴스는 SQL 작업에 사용되는 임시 공간이 10GB로 제한됩니다. 일부 작업(예: GROUP BY를 사용한 다량의 집계)은 이 한도에 영향을 받을 수 있습니다. 어떤 경우에는 쿼리를 다르게 작성하거나 다른 SQL 구문을 사용하여 임시 공간 한도에 도달하지 않도록 할 수 있습니다. 2세대 인스턴스에는 이러한 한도가 적용되지 않습니다.
  • 머신 유형이 작업 부하에 맞게 충분히 큰지 확인하세요.

데이터베이스 삽입, 업데이트, 삭제 속도가 느리다면 다음과 같은 조치를 고려하세요.

  • 1세대 인스턴스의 경우 파일 시스템 복제 비동기 모드(인스턴스 구성 절정)가 동기 모드보다 훨씬 더 빠릅니다. 현재 동기 모드를 사용하고 있고 애플리케이션이 어느 정도의 데이터 위험을 견딜 수 있다면 비동기 모드로 전환하는 것이 좋습니다.
  • 작성자와 데이터베이스의 위치를 확인합니다. 장거리로 데이터를 보내면 지연 시간이 발생합니다.

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

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

쿼리 실행 성능이 저하되면 EXPLAIN을 사용하여 다음과 같은 조치를 취할 위치를 식별합니다.

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

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

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

    • 쿼리 세션에서 sort_buffer_size 변수 크기를 늘리세요.

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

MySQL용 Cloud SQL