Cloud SQL FAQ

정보

Cloud SQL이란 무엇인가요?
Cloud SQL은 클라우드에서 완전 관리형 SQL 데이터베이스를 제공하는 편리한 서비스입니다. Cloud SQL은 MySQL 또는 PostgreSQL 데이터베이스를 제공합니다.
Cloud SQL을 사용하면 어떤 이점이 있나요?
Cloud SQL을 사용하면 패치 및 업데이트 적용, 백업 관리, 복제 구성과 같이 일상적이지만 시간이 많이 소요되는 필수 작업을 Google에서 맡으므로 사용자는 우수한 애플리케이션 구현에만 집중할 수 있습니다. 또한 표준 유선 프로토콜을 사용하기 때문에 어디에서나 거의 모든 애플리케이션에서 쉽게 연결할 수 있습니다.
Cloud SQL에서 사용할 수 있는 데이터베이스 버전은 무엇인가요? 업데이트는 어떻게 관리되나요?

MySQL용 Cloud SQL의 경우, 2세대 인스턴스는 MySQL 5.6 및 5.7을 지원합니다. 1세대 인스턴스는 MySQL 5.5 및 MySQL 5.6을 지원합니다.

PostgreSQL용 Cloud SQL은 PostgreSQL 9.6 및 11.1 베타를 지원합니다. 부 버전 업데이트는 릴리스 시 바로 적용되며, 사용자가 해야 하는 추가 작업은 없습니다. 업데이트에 대한 자세한 내용은 유지관리 때문에 인스턴스가 종료되는 경우는 어떤 경우인가요?를 참조하세요.

인스턴스의 현재 버전을 확인하려면 Google Cloud Platform Console에서 인스턴스 이름을 클릭하여 인스턴스 세부정보 페이지를 엽니다. 또는 gcloud sql instances describe 명령어를 사용할 수 있습니다.

Cloud SQL에서 모든 데이터베이스 기능을 지원하나요?
Cloud SQL은 MySQL 또는 PostgreSQL의 가장 일반적인 기능을 지원합니다. 표준 데이터베이스 기능과 Cloud SQL이 제공하는 기능 간의 모든 차이점은 Cloud SQL과 표준 MySQL 기능의 차이점 또는 Cloud SQL와 표준 PostgreSQL 기능의 차이점을 참조하세요.
크기 또는 QPS 제한이 있나요?
Cloud SQL 인스턴스에는 초당 쿼리 수(QPS) 제한이 없습니다. 연결, 크기, App Engine 관련 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
Cloud SQL이 변경됐을 때 알림을 받으려면 어떻게 해야 하나요?
Cloud SQL에 대한 공지와 소식을 게시하는 google-cloud-sql-announce 포럼에 가입할 수 있습니다.
버그를 신고하거나 기능을 요청하거나 질문을 하려면 어떻게 해야 하나요?
google-cloud-sql-discuss 그룹에서 버그를 신고하고 기능을 요청할 수 있으며 Stack Overflow에서 질문할 수 있습니다. 기타 다른 지원이 필요한 경우는 Cloud SQL 지원 페이지를 참조하세요.
맨 위로

시작하기

인스턴트 관리에 가장 적합한 MySQL 도구는 무엇인가요?
Cloud SQL에 사용할 수 있는 다양한 MySQL 도구가 있습니다. 간단한 문을 실행하는 경우에는 MySQL 명령줄 도구를 사용할 수 있습니다. 보다 복잡한 작업을 실행하거나 다양한 데이터베이스 개발 환경을 사용하려면 Toad for MySQL 또는 MySQL Workbench를 사용하면 됩니다. 자세한 내용은 관리 및 보고 도구를 참조하세요.
어떤 저장소 엔진을 사용해야 하나요?
MySQL 2세대 인스턴스의 경우 저장소 엔진으로 InnoDB만 지원합니다. MySQL 1세대 인스턴스의 경우에는 보다 강력한 데이터 일관성을 보장하는 InnoDB 스토리지 엔진을 권장합니다.

모든 테이블 형식이 MyISAM인 mysqldump 파일은 sed 스크립트를 통해 파일을 파이핑하면 InnoDB 형식으로 변환할 수 있습니다.

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

경고: mysqldump 파일에 mysql 스키마가 포함되어 있으면 이 작업을 수행해서는 안 됩니다. 이런 파일은 반드시 MyISAM 형식을 유지해야 합니다.

데이터가 없는 새 인스턴스에서 사용된 디스크 공간이 표시되는 이유는 무엇인가요?
Cloud SQL 및 데이터베이스는 인스턴스가 생성될 때 시스템 파일과 메타데이터를 위해 공간을 사용합니다.
MySQL 1세대 인스턴스가 간혹 응답이 느려지는 이유는 무엇인가요?
사용량 요금제에서 인스턴스에 청구되는 금액을 최소화하기 위해 인스턴스는 기본적으로 15분 동안 액세스하지 않는 경우 비활성화 상태가 됩니다. 다음에 액세스하면 인스턴스를 활성화하는 동안 짧은 지연 시간이 발생합니다. 인스턴스의 활성화 정책을 구성해 이 방식을 변경할 수도 있습니다. 자세히 알아보기
어떤 활성화 정책을 사용해야 하나요?

MySQL 2세대 인스턴스 또는 PostgreSQL 인스턴스: 일반적으로 활성화 정책을 ALWAYS로 설정합니다. 인스턴스를 사용하지 않으면 인스턴스 요금이 청구되지 않도록 활성화 정책을 NEVER로 설정합니다.

MySQL 1세대 인스턴스: 1세대 인스턴스를 패키지 요금제로 사용하는 경우에는 인스턴스를 사용하지 않을 때 정지하더라도 비용상의 이점이 없으므로 활성화 정책을 ALWAYS로 설정해야 합니다. 1세대 인스턴스를 사용량 요금제로 사용하는 경우에는 활성화 정책을 ON DEMAND로 설정하면 비용을 줄일 수 있습니다. 이 설정에서는 인스턴스가 15분 동안 비활성화 상태를 유지하면 자동으로 종료되므로 인스턴스를 사용하지 않을 때 비용이 발생하지 않습니다. 인스턴스의 활성화 정책이 ON DEMAND인 경우에는 인스턴스가 종료된 상태일 때 액세스 요청이 수신되면 짧은 지연 시간이 발생합니다. 요청을 처리하기 전에 인스턴스를 시작해야 하기 때문입니다.

맨 위로

데이터 저장 및 복제

데이터는 어디에 저장되나요?

MySQL 2세대 인스턴스: 인스턴스 데이터는 인스턴스가 존재하는 지역에 저장됩니다. 백업 데이터는 중복화를 위해 두 지역에 저장됩니다. 한 대륙에 두 개의 지역이 있는 경우 백업 데이터는 같은 대륙에 유지됩니다. 오스트레일리아는 지역이 한 개이므로 시드니 지역의 백업 데이터는 아시아에도 저장됩니다. 상파울루 지역의 백업 데이터는 미국 지역에도 저장됩니다.

MySQL 1세대 인스턴스: 인스턴스가 존재하는 대륙에 인스턴스 데이터 및 백업 데이터가 저장됩니다.

PostgreSQL 인스턴스: 인스턴스 데이터는 인스턴스가 있는 리전에 저장됩니다. 백업 데이터는 중복화를 위해 두 지역에 저장됩니다. 한 대륙에 두 개의 지역이 있는 경우 백업 데이터는 같은 대륙에 유지됩니다. 오스트레일리아는 지역이 한 개이므로 시드니 지역의 백업 데이터는 아시아에도 저장됩니다. 상파울루 지역의 백업 데이터는 미국 지역에도 저장됩니다.

영역이란 무엇인가요?

영역은 리소스를 실행할 수 있는 특정 지리적 위치의 독립적인 항목입니다. 예를 들어 이름이 us-central1-a인 영역은 미국 중부의 한 위치를 나타냅니다.

영역에 장애가 발생할 때 내결함성을 제공하기 위해 기본적으로 MySQL 1세대 인스턴스의 데이터는 복제되며, 서비스는 여러 영역에 분산됩니다. MySQL 2세대 인스턴스의 경우, 고가용성으로 인스턴스를 구성해(장애 조치 복제본 추가) 영역 간 내결함성을 구현할 수 있습니다. 모든 프로덕션 인스턴스에 고가용성 구성을 사용하는 것을 적극 권장합니다.

영역(zone)에 대한 자세한 내용은 Compute Engine 문서의 영역 리소스를 참조하세요.

저장용량 한도는 얼마나 되나요?
저장용량 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
데이터는 어떻게 복제되나요?

MySQL 2세대 인스턴스: 2세대 장애 조치 복제본일부 동기 복제를 사용합니다. 2세대 읽기 복제본은 비동기 복제를 사용합니다.

MySQL 1세대 인스턴스: 1세대 인스턴스를 만들 때 데이터가 리전 내 모든 영역에 자동으로 복제됩니다.

PostgreSQL 인스턴스는 고가용성 구성읽기 복제본을 제공합니다.

Cloud SQL 장애 조치는 어떤 방식으로 작동하나요?

장애 조치에 대한 자세한 내용은 고가용성 구성 개요를 참조하세요.

데이터가 암호화되나요?
Cloud SQL 고객 데이터는 데이터베이스 테이블, 임시 파일, 백업에 저장될 때 암호화됩니다. 외부 연결은 SSL을 사용하거나 Cloud SQL 프록시를 사용하여 암호화될 수 있습니다.
미사용 데이터의 암호화는 어떻게 관리하나요?

데이터는 256비트 고급 암호화 표준(AES-256) 이상과 대칭 키를 사용하여 암호화됩니다. 즉, 데이터가 저장될 때 데이터를 암호화하고 데이터가 사용될 때 데이터를 복호화하는 데 같은 키가 사용됩니다. 이러한 데이터 키는 보안 키 저장소에 저장된 마스터키를 사용하여 자체적으로 암호화되고 정기적으로 변경됩니다.

자세한 내용은 Google Cloud의 미사용 데이터 암호화를 참조하세요.

전송 중인 데이터의 암호화는 어떻게 관리하나요?

데이터가 Google이나 Google의 대리인이 통제하지 않는 물리적 경계 외부로 이동할 때 Google은 하나 이상의 네트워크 계층에서 전송 중인 모든 데이터를 암호화하고 인증합니다. Google이나 Google 대리인이 통제하는 물리적 경계 내에서 전송 중인 데이터는 일반적으로 인증되지만 기본적으로 암호화되지 않을 수 있습니다. 위협 모델에 따라 적용할 추가 보안 조치를 선택할 수 있습니다. 예를 들어 Cloud SQL로의 영역 내 연결을 위해 SSL을 구성할 수 있습니다.

자세한 내용은 Google Cloud의 전송 중 암호화를 참조하세요.

만들 수 있는 읽기 복제본의 종류에는 어떤 것이 있나요?

각 유형의 사용 사례를 비롯하여 읽기 복제본에 대한 자세한 내용은 복제 옵션을 참조하세요.

인스턴스가 읽기 복제본인지 어떻게 알 수 있나요?
Google Cloud Platform 콘솔을 사용하면 모든 Cloud SQL 인스턴스를 확인할 수 있고, 마스터 인스턴스인지 읽기 복제본 인스턴스인지도 확인할 수 있습니다. 또는 Cloud SDK를 사용하여 마스터 인스턴스인지 읽기 복제본 인스턴스인지 확인할 수도 있습니다.
맨 위로

백업 및 복구

인스턴스를 복구하려면 어떻게 해야 하나요?

백업으로 복원하려면 Google Cloud Platform Console 또는 gcloud 명령줄 도구를 사용하면 됩니다. 자세한 내용은 인스턴스 복원을 참조하세요.

MySQL 인스턴스를 특정 시점으로 복원하려면 특정 시점 복구를 사용합니다. 자세한 내용은 특정 시점 복구 수행을 참조하세요.

백업 비용은 얼마나 드나요?

MySQL 2세대 인스턴스: 최근의 자동 백업 7개 및 모든 주문형 백업이 유지됩니다. 비용은 백업 저장 가격에 따라 부과됩니다. 바이너리 로그는 백업 공간이 아닌 저장 공간을 사용하며 저장 용량에 따라 비용이 청구됩니다.

MySQL 1세대 인스턴스: 최근 백업 7개의 저장소 요금이 인스턴스 비용에 포함됩니다. 바이너리 로그 공간은 인스턴스에서 사용된 스토리지에 포함됩니다.

PostgreSQL 인스턴스: 최근 자동 백업 7개 및 모든 주문형 백업이 유지됩니다. 이러한 백업 비용은 백업 저장률에 따라 부과됩니다.

인스턴스 저장소 가격 및 인스턴스 요율에 대한 자세한 내용은 가격을 참조하세요.

특정 시점 복구가 성능에 어떤 영향을 미치나요?
특정 시점 복구를 위해서는 바이너리 로깅을 사용 설정해야 합니다. 즉, 데이터베이스에 대한 모든 업데이트가 독립 로그에 작성되므로 쓰기 성능이 약간 저하됩니다. 읽기 작업 성능은 바이너리 로그 파일 크기에 관계없이 바이너리 로깅에 영향을 받지 않습니다.
맨 위로

인스턴스 관리

데이터베이스를 확장하거나 축소할 수 있나요?

MySQL 2세대 및 PostgreSQL 인스턴스: 언제든지 다운타임 없이 인스턴스에서 사용할 수 있는 저장용량을 늘릴 수 있습니다. 인스턴스 저장소의 크기를 줄일 수는 없습니다. 또한 공간이 부족할 때 저장용량을 자동으로 늘리도록 인스턴스를 구성할 수도 있습니다. 자세히 알아보기

MySQL 1세대 인스턴스: 언제든지 데이터베이스의 등급을 변경할 수 있습니다. 이렇게 하면 인스턴스가 강제로 다시 시작되어 약간의 다운타임이 발생합니다.

Google Cloud Platform Console을 사용하여 Cloud SQL을 관리해야 하나요?
아니요. 콘솔을 통해 수행할 수 있는 모든 관리 작업은 Cloud SQL API를 통해 프로그래매틱 방식으로 수행하거나 gcloud 명령줄 도구를 사용하여 스크립팅할 수도 있습니다.
삭제된 테이블의 공간을 재확보하려면 어떻게 해야 하나요?
데이터베이스에서 테이블을 삭제하고 Google Cloud Platform Console을 확인했을 때 테이블 삭제로 확보한 공간이 인스턴스의 사용된 스토리지에 반영되지 않을 수 있습니다. MySQL 5.5를 실행하는 인스턴스에서는 기본적으로 innodb_file_per_table 플래그가 OFF로 설정되어 있습니다. InnoDB는 기본 테이블스페이스를 절대 축소시키지 않습니다. 이 구성에서 공간을 재확보하려면 작은 데이터베이스에서 새 인스턴스를 만들거나 innodb_file_per_table 플래그 값을 ON으로 변경합니다. 데이터베이스 플래그를 변경하는 방법에 대한 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.
데이터 변경사항을 어떻게 추적할 수 있나요?
인스턴스의 바이너리 로깅을 사용 설정하면 데이터 변경사항을 추적할 수 있습니다. 데이터 변경사항을 추적하면 실수로 인한 데이터 손실을 복구하는 데 도움이 됩니다. 예를 들어 DROP DATABASE 명령어를 사용하여 실수로 데이터가 손실된 경우 데이터 손실 이벤트 직전의 바이너리 로그 좌표로 복원할 수 있습니다. 자세한 내용은 특정 시점 복구를 참조하세요. 특정 시점 복구 및 바이너리 로깅은 PostgreSQL 인스턴스에서 아직 사용할 수 없습니다.
유지관리 때문에 인스턴스가 종료되는 경우는 어떤 경우인가요?

MySQL 2세대 및 PostgreSQL 인스턴스: 인스턴스의 유지관리 기간을 선택할 수 있으므로 유지관리가 다시 시작되는 시간을 제어할 수 있습니다. 인스턴스가 프로젝트의 다른 인스턴스보다 이르거나 늦게 업데이트를 받도록 지정할 수도 있습니다. 자세히 알아보기

MySQL 1세대 인스턴스: Cloud SQL 업그레이드를 수행하고, 영역 간에 이전하고, 기타 인프라 작업을 수행하기 위해 Cloud SQL 인스턴스를 주기적으로 다시 시작합니다. 데이터가 여러 위치에 복제되기 때문에 인스턴스 중단은 일반적으로 몇 초에서 몇 분 사이입니다. App Engine 애플리케이션을 따르도록 구성된 1세대 인스턴스를 새 위치에서 다시 시작할 수도 있습니다. 그러면 App Engine 애플리케이션이 다른 곳으로 이동한 경우에도 지연 시간이 최소화됩니다. 이렇게 할 경우 지연 시간이 약간 증가하며 일반적으로 몇 초 정도 사용할 수 없게 됩니다.

애플리케이션이 유지보수 종료와 같이 단기간 동안 인스턴스에 액세스할 수 없는 상황을 처리하도록 설계하는 것이 좋습니다. 같은 효과가 있는 인스턴스를 다시 시작하여 유지관리 종료에 대한 애플리케이션의 동작을 테스트할 수 있습니다. 일반적으로 거부된 연결을 다시 시도하기 위해서는 지수 백오프를 사용할 뿐만 아니라 짧게 지속되는 연결만 사용하는 것이 좋습니다. 자세한 내용은 연결을 어떻게 관리해야 하나요?를 참조하세요.

MySQL 인스턴스의 경우, mysqld를 종료하는 데 소요되는 시간은 1분으로 제한됩니다. 이 시간 안에 종료가 완료되지 않으면 mysqld 프로세스가 강제 종료됩니다. 이 경우에는 서버가 쿼리 처리를 시작할 준비를 마치기 전에 InnoDB 저장소 엔진이 충돌 복구를 수행하기 때문에 시작 시간이 길어집니다. 충돌 복구를 완료하는 데 걸리는 시간은 데이터베이스 크기에 따라 다릅니다. 데이터베이스가 클수록 복구에 더 많은 시간이 걸립니다.

새 버전이 적용되면 노트가 출시 노트에 추가됩니다. 하지만 모든 인스턴스가 동시에 새로 출시되는 버전으로 업그레이드되는 것은 아닙니다.

특정 데이터베이스를 가져오거나 내보낼 수 있나요?
예. MySQL 인스턴스의 경우 단일 데이터베이스 또는 여러 데이터베이스를 가져오거나 내보낼 수 있습니다. PostgreSQL 인스턴스의 경우에는 특정 데이터베이스만 가져오거나 내보낼 수 있습니다.
CSV 파일을 가져오거나 내보낼 수 있나요?
MySQL 인스턴스용 CSV를 가져오거나 내보낼 수 있습니다. PostgreSQL 인스턴스는 CSV 파일 가져오기나 내보내기를 아직 지원하지 않습니다. 자세한 내용은 CSV 파일 만들기를 참조하세요.
인스턴스로 데이터를 가져오거나 내보내려면 Cloud Storage 계정이 필요한가요?
Cloud SQL은 Cloud Storage 버킷을 사용하여 데이터베이스(압축 또는 비압축 SQL 덤프 파일)와 CSV 파일을 가져오거나 내보내는 방식을 지원합니다. Cloud Storage 버킷을 사용하여 가져오거나 내보내려면 GCP 계정에 가입하고 버킷을 만들거나 다른 계정에서 Cloud Storage 버킷에 대한 액세스 권한이 있어야 합니다. 자세한 내용은 데이터 가져오기 또는 데이터 내보내기를 참조하세요.
가져오기 작업에서 ERROR_RDBMS는 무엇을 의미하나요?
이 오류는 데이터 가져오기 작업 중에 MySQL이 오류를 반환할 경우 발생합니다. 일반적인 원인은 구문이 잘못되었거나 정의되지 않은 데이터베이스 또는 테이블을 사용했거나 SUPER 권한이 필요한 MySQL 문 실행을 시도했기 때문입니다.
인스턴스를 삭제하면 해당 인스턴스 이름을 다시 사용할 수 있나요?
예. 하지만 곧바로 다시 사용할 수는 없습니다. 최대 1주일이 지나야 인스턴스 이름을 다시 사용할 수 있습니다.
cloudsqladmin 데이터베이스 사용자란 무엇인가요?
모든 Cloud SQL 인스턴스에는 cloudsqladmin이라는 데이터베이스 사용자가 있습니다. SHOW GRANTS FOR cloudsqladmin@localhost를 수행하면 이 사용자를 확인할 수 있습니다. 일부 인스턴스에서는 이 이름이 시스템 사용자 테이블에도 표시됩니다. 이 사용자 계정은 인스턴스의 데이터에 액세스해야 하는 자동 프로세스(예: 인스턴스 백업 또는 가져오기/내보내기 수행)에서 사용됩니다.
GRANT ALL을 사용하려면 어떻게 해야 하나요?
Cloud SQL은 SUPER 권한을 지원하지 않기 때문에 GRANT ALL PRIVILEGES 문이 작동하지 않습니다. 대신 GRANT ALL ON `%`.*을 사용할 수 있습니다.
인스턴스의 트랜잭션 로그에 어떻게 액세스하나요?
MySQL 인스턴스의 경우 인스턴스의 바이너리 로깅을 사용 설정하고(바이너리 로깅 사용 설정 참조) 인스턴스의 IP 주소를 구성하면(IP 연결 액세스 구성 참조) 표준 MySQL mysqlbinlog 유틸리티를 사용하여 인스턴스의 트랜잭션 로그를 검사할 수 있습니다.
Cloud SQL에서 제공되는 트랜잭션 격리 수준은 무엇인가요?

MySQL 인스턴스: Cloud SQL에서는 REPEATABLE READ 트랜잭션 격리가 제공됩니다. 현재 세션의 트랜잭션 격리 수준을 변경할 수 있지만 일반적으로는 기본값을 사용하는 것이 좋습니다. 자세한 내용은 MySQL 문서의 Transaction Isolation Levels를 참조하세요.

PostgreSQL 인스턴스: Cloud SQL에서는 Read committed 트랜잭션 격리가 제공됩니다. 특정 트랜잭션의 트랜잭션 격리 수준을 변경할 수 있지만 일반적으로는 기본값을 사용하는 것이 좋습니다. 자세한 내용은 PostgreSQL 문서의 Transaction Isolation을 참조하세요.

맨 위로

가격 및 결제

Cloud SQL을 사용해보려면 어떻게 해야 하나요?
가장 작은 인스턴스는 db-f1-micro입니다. 이 인스턴스로 서비스를 사용해볼 수 있습니다. 공유 코어 인스턴스에는 SLA가 적용되지 않습니다.
사용량 요금제와 패키지 요금제 중 어떤 요금제를 사용해야 하나요?
사용량 요금제 및 패키지 요금제 옵션은 1세대 인스턴스에만 적용됩니다. 일반적으로 인스턴스를 매월 450시간 이상 사용하는 경우 패키지 요금제를 선택하는 것이 더 경제적입니다. 요금제에 대한 자세한 내용은 가격 책정을 참조하세요.
요금제를 변경할 수 있나요?
사용량 요금제 및 패키지 요금제 옵션은 1세대 인스턴스에만 적용됩니다. 한 달에 3회까지 인스턴스 요금제를 변경할 수 있습니다. 하루가 끝나는 시점(미국 태평양 표준시 기준)에 적용되어 있는 요금제로 인스턴스 비용을 계산합니다. 같은 날에는 요금제를 원하는 만큼 변경할 수 있습니다. 몇 번을 변경해도 매월 3회의 변경 기회 중 1회만 사용한 것으로 계산됩니다.

설정을 수정하면 1세대 인스턴스 요금제를 변경할 수 있습니다. Google Cloud Platform 콘솔로 이동하여 인스턴스가 포함된 프로젝트를 선택한 후 Cloud SQL을 선택하면 됩니다. 인스턴스 목록에서 인스턴스를 선택하고 결제 설정이 포함된 인스턴스 설정을 수정하세요.

한 프로젝트에서 만들 수 있는 인스턴스 수는 몇 개인가요?
인스턴스 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.
필요한 데이터베이스 인스턴스의 크기는 어느 정도인가요? RAM은 어느 정도가 필요한가요?
일반적으로 RAM과 CPU를 추가한 대용량 인스턴스를 선택하면 데이터베이스 성능이 향상될 수 있습니다. 이렇게 하면 단일 행에 영향을 미치는 업데이트의 성능은 크게 영향을 받지 않지만, 조인, ORDER BY, GROUPing을 포함하는 쿼리 등과 같이 쿼리 수가 많아 대량의 계산이 수반되는 경우에는 성능이 향상됩니다. 인스턴스 크기 및 가격에 대한 자세한 내용은 가격 페이지를 참조하세요.
인스턴스 사용량은 어떻게 계산하나요?

MySQL 2세대 및 PostgreSQL 인스턴스: 인스턴스 실행 시간의 분당 요금이 청구됩니다.

MySQL 1세대 인스턴스: 인스턴스에서 종량제 결제 요금제를 사용하는 경우, 인스턴스 실행 시간의 분당 요금이 부과됩니다.

ON_DEMAND(기본값) 활성화 정책을 사용하는 인스턴스는 액세스할 때마다(SQL 프롬프트, 외부 애플리케이션, App Engine 애플리케이션 등을 통해) 시작되며, 마지막 액세스가 완료된 후 15분 동안 유지됩니다. 그 후에는 인스턴스가 종료됩니다. 인스턴스가 꺼져 있는 동안에는 요금이 청구되지 않습니다.

인스턴스는 클라이언트가 연결되어 있으면 계속 켜져 있습니다. 여기에는 유휴 연결도 포함됩니다. MySQL 클라이언트를 사용하고 SHOW PROCESSLIST 명령어를 실행하여 인스턴스 연결을 나열할 수 있습니다. 그런 다음 KILL 명령어를 사용하여 연결을 끊을 수 있습니다. 인스턴스를 다시 시작하여 모든 연결을 끊을 수도 있습니다.

패키지 요금제를 사용하고 ON_DEMAND 활성화 정책이 적용되는 인스턴스는 마지막 액세스 이후 12시간 동안 켜져 있습니다.

활성화 정책을 수정하여 인스턴스의 활성화 동작을 변경할 수 있습니다. 자세히 알아보기

저장 용량은 어떻게 계산하나요?

MySQL 2세대 및 PostgreSQL 인스턴스: 인스턴스에 대해 프로비저닝된 저장용량을 기준으로 저장소 요금을 계산합니다. 백업용 저장소는 백업이 사용하는 공간 크기에 따라 요금이 부과됩니다. 저장소는 인스턴스가 켜져 있는지와 관계없이 요금이 부과됩니다.

MySQL 1세대 인스턴스: 인스턴스가 사용하는 파일 공간을 기준으로 저장소 요금을 계산합니다. 저장소 요금은 GB 단위로 분당 부과되므로 사용량과 거의 동일한 요금이 부과됩니다. 저장소 요금은 인스턴스 사용 여부와 관계없이 발생합니다. 예약된 백업 서비스를 사용하여 생성한 백업용 저장소에는 요금이 부과되지 않습니다.

청구될 요금을 어떻게 확인할 수 있나요?
Google Cloud Platform Console결제 탭에는 청구서가 마지막으로 발행된 후 인스턴스에 부과된 요금이 표시됩니다.
'사용량' 요금제를 사용하고 있는데 유휴 상태인 1세대 인스턴스에서 비용이 발생하는 이유는 무엇인가요?

인스턴스에 예약된 백업을 사용 설정했는지 확인하세요. Cloud SQL은 마지막 예약된 백업 이후에 인스턴스의 데이터가 변경된 경우에만 인스턴스를 백업합니다. 예약된 백업이 수행될 때마다 인스턴스가 백업 시간 동안 활성화되므로 '사용량' 요금이 부과됩니다.

인스턴스가 최대 허용 크기에 도달하면 어떻게 되나요?

MySQL 2세대 및 PostgreSQL 인스턴스: 인스턴스가 프로비저닝된 저장소 크기에 도달하고 저장용량 자동 증가가 사용 설정되지 않았거나 구성된 제한에 도달한 경우, 저장소 크기를 늘릴 때까지 데이터베이스에 대한 추가 쓰기가 허용되지 않습니다. 스토리지 크기를 늘리는 데 인스턴스 재시작 또는 다운타임이 필요하지 않습니다.

MySQL 1세대 인스턴스:

인스턴스가 선택한 요금제에서 허용되는 최대 저장용량에 도달하면 데이터 삭제를 통해 크기가 줄어들 때까지 데이터베이스에 추가로 쓸 수 없습니다.

인스턴스가 일시 중지되는 이유는 무엇인가요?
GCP 계정에 문제가 있을 수 있습니다. 결제 지원 요청을 제출하여 결제 상태를 확인할 수 있습니다. 결제 문제가 해결되면 인스턴스가 몇 시간 내에 실행 가능한 상태로 돌아갑니다. 일시정지된 2세대 인스턴스는 90일이 지나면 삭제됩니다.
인스턴스가 삭제된 이유는 무엇인가요?
90일 동안 일시 중지된 PostgreSQL 및 MySQL 2세대 인스턴스는 삭제됩니다. 상태가 SUSPENDED인 인스턴스도 해당합니다. 상태가 RUNNABLE인 중지된 인스턴스는 삭제되지 않습니다.
Cloud SQL 계정을 취소하려면 어떻게 해야 하나요?
Google Cloud Platform Console에서 프로젝트를 선택한 후 API 서비스를 선택하여 API 대시보드를 열어서 프로젝트의 Cloud SQL을 비활성화할 수 있습니다. Cloud SQL API를 찾고 해당 API에 사용 중지를 클릭합니다.
결제를 중지하려면 어떻게 해야 하나요?
프로젝트에 대한 Google Cloud Platform 콘솔 결제 및 설정 창에서 결제 사용 중지를 클릭하여 결제를 중지하도록 설정할 수 있습니다. 결제를 중지하도록 설정하는 경우 Cloud SQL 서비스도 중지하도록 설정됩니다. 결제를 중지하기 전에 Cloud SQL 서비스를 중지해도 좋을지 먼저 확인하세요.

결제를 중지하도록 설정하면 결제 주기 시작 시점과 취소 시점 사이에 발생한 요금에 대해 최종 청구서를 받게 됩니다.

맨 위로

App Engine과 함께 Cloud SQL 사용

App Engine에서 MySQL 2세대 인스턴스로 연결할 수 있나요?
애플리케이션이 실행되는 환경(표준 환경 또는 가변형 환경)에 상관없이 App Engine 애플리케이션에서 2세대 인스턴스로 연결할 수 있습니다. 자세한 내용은 App Engine에서 연결을 참조하세요.
App Engine에서 PostgreSQL 인스턴스로 연결할 수 있나요?
사용 중인 환경 및 언어에 따라 App Engine 애플리케이션에서 PostgreSQL 인스턴스로 연결할 수 있습니다. 자세한 내용은 App Engine에서 연결을 참조하세요.
미국의 App Engine에서 EU의 Cloud SQL 인스턴스에 액세스할 수 있나요? 반대의 경우도 가능한가요?

MySQL 1세대 인스턴스에 연결하는 경우 App Engine 애플리케이션이 Cloud SQL 인스턴스와 동일한 지역에 위치하며 표준 환경에서 실행되어야 합니다.

MySQL 2세대 인스턴스에 연결하는 경우 App Engine 애플리케이션이 동일한 지역에 있을 필요가 없으며 표준 환경이나 가변형 환경에서 실행될 수 있습니다. 그러나 Cloud SQL 인스턴스와 App Engine 애플리케이션 간의 거리가 멀어지면 데이터베이스 연결 지연 시간이 길어집니다.

PostgreSQL 인스턴스에 연결하는 경우 App Engine 애플리케이션이 동일한 지역에 있을 필요는 없습니다. 그러나 Cloud SQL 인스턴스와 App Engine 애플리케이션 간의 거리가 멀어지면 데이터베이스 연결 지연 시간이 길어집니다.

어떤 GCP 데이터베이스 서비스가 적합할까요?
애플리케이션의 요구사항에 따라 다릅니다. Google Cloud Platform은 데이터 저장 및 검색을 위한 다양한 서비스를 제공합니다. 자세한 내용은 저장소 옵션을 참조하세요.
App Engine 개발 서버를 사용하려면 로컬 데이터베이스 서버를 설치해야 하나요?
아니요. 개발 서버에서 실행할 때 Cloud SQL 또는 로컬에 설치된 데이터베이스 서버를 사용하도록 App Engine을 구성할 수 있습니다.
인스턴스에 액세스하는 데 사용할 수 있는 언어는 무엇인가요?
App Engine은 인스턴스에 연결하는 데 사용할 수 있는 여러 언어를 지원합니다. 자세한 내용은 App Engine에서 연결을 참조하세요.

App Engine을 사용하지 않는 경우 연결된 커넥터 또는 API가 있는 언어를 사용할 수 있습니다. 지원되는 언어 목록은 MySQL 참조 설명서의 커넥터 및 API 장을 참조하세요.

Django를 Cloud SQL과 함께 사용할 수 있나요?
예. Cloud SQL은 Django와 호환됩니다. Django 시작하기를 참조하세요.
Python 쿼리 문자열에서 사용할 수 있는 자리표시자는 무엇인가요?
Python 사용자는 매개변수 치환 시 %s 형식 코드만 사용할 수 있습니다. 따라서 cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age)) 문은 유효하지 않습니다.
연결을 어떻게 관리해야 하나요?

연결 풀링 및 지수 백오프 사용을 포함한 효율적인 데이터베이스 연결 관리는 데이터베이스 애플리케이션 개발에 있어 중요한 부분입니다. 이러한 기술을 다양한 언어와 프레임워크에서 활용하는 방법의 예는 데이터베이스 연결 관리를 참조하세요.

인스턴스 연결 제한에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

'잘못된 연결 ID'라는 메시지를 표시하는 SQLException은 무엇을 의미하나요?
서버에서 더 이상 연결이 열려 있지 않으므로 클라이언트에서 연결을 삭제해야 한다는 의미입니다.  이 경우 이미 종료되었기 때문에 '종료'를 호출할 필요는 없습니다.
App Engine 외부에서 프로그래매틱 방식으로 Cloud SQL 인스턴스에 액세스할 수 있나요?
예. 지원되는 언어를 사용하는 외부 애플리케이션에서 프로그래매틱 방식으로 Cloud SQL 인스턴스에 액세스할 수 있습니다. Cloud SQL 데이터베이스에 액세스하기 위한 Apps Script 스크립트 쓰기 등 JDBC를 사용하여 연결할 수도 있습니다. 외부 애플리케이션에서 연결을 참조하세요.
맨 위로
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

Cloud SQL 문서