권장사항

이 페이지에서는 Cloud SQL의 성능, 내구성, 가용성을 최적화하기 위한 권장사항을 제공합니다.

Cloud SQL 인스턴스에 문제가 발생하면 문제 해결 중에 다음을 검토합니다.

인스턴스 구성 및 관리

권장사항 추가 정보
운영 가이드라인을 읽고 수행하여 인스턴스에 Cloud SQL SLA가 적용되는지 확인합니다.
기본 인스턴스의 유지관리 기간을 구성하여 방해가 되는 업데이트가 발생할 수 있는 시간을 제어하세요. 유지관리 기간을 참조하세요.
읽기가 많이 발생하는 작업 부하의 경우 읽기 복제본을 추가하여 기본 인스턴스에서 트래픽을 오프로드하세요. 원하는 경우 HAProxy와 같은 부하 분산기를 사용하여 복제본에 대한 트래픽을 관리할 수 있습니다.
인스턴스를 정기적으로 삭제하고 다시 만드는 경우 인스턴스 ID의 타임스탬프를 사용하여 새로운 인스턴스 ID의 사용 가능성을 높이세요. 인스턴스가 삭제된 후 며칠 동안은 삭제된 인스턴스의 ID를 다시 사용할 수 없습니다.
이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.

Cloud SQL 인스턴스는 이전 작업을 완료할 때까지 새로운 작업 요청을 수락하지 않습니다. 조기에 새로운 작업을 시작하려고 시도하면 작업 요청에 실패합니다. 인스턴스 다시 시작도 여기에 포함됩니다.

Cloud Console의 인스턴스 상태에는 작업 실행 여부가 반영되지 않습니다. 녹색 체크표시는 인스턴스가 RUNNABLE 상태인 것만 나타냅니다. 작업 실행 여부를 확인하려면 작업 탭으로 이동하여 최근 작업 상태를 확인합니다.

업데이트 후 시스템 테이블을 삭제하세요. MySQL 시스템 테이블(예: mysql.user 또는 mysql.db)은 MyISAM 스토리지 엔진을 사용합니다. 이러한 테이블은 비정상적인 종료에 취약하므로 mysql 클라이언트를 사용하여 사용자 추가 또는 업데이트와 같이 테이블을 변경한 후에 FLUSH CHANGES 명령어를 실행합니다. MyISAM 손상이 발생하고 인스턴스를 다시 시작할 수 있는 경우 CHECK TABLEREPAIR TABLE 명령어를 사용하여 손상을 해결할 수 있지만 테이블의 콘텐츠가 올바르지 않을 수 있습니다.

데이터 아키텍처

권장사항 추가 정보
가능한 경우 인스턴스를 공유하세요. 가능한 경우 여러 개의 작은 Cloud SQL 인스턴스를 사용하는 것이 하나의 큰 인스턴스를 사용하는 것보다 더 효과적입니다. 큰 모놀리식 인스턴스를 관리하면 여러 개의 작은 인스턴스를 관리할 때 발생하지 않는 문제가 발생합니다.
너무 많은 데이터베이스 테이블을 사용하지 마세요.

데이터베이스 테이블이 너무 많으면 인스턴스 응답 시간에 영향을 줄 수 있습니다. 테이블이 10,000개를 넘으면 SLA 적용 범위에 영향을 줍니다. 자세한 내용은 운영 가이드라인을 참조하세요.

테이블에 기본 키 또는 고유한 키가 있는지 확인하세요. Cloud SQL은 기본 키 또는 고유 키가 있는 테이블에서 가장 효과적인 행 기반 복제를 사용합니다.

애플리케이션 구현

권장사항 추가 정보
연결 풀링 및 지수 백오프와 같은 연결 관리 권장사항을 사용하세요. 이러한 방법을 사용하면 애플리케이션의 리소스 사용이 향상되고 Cloud SQL 연결 한도를 유지할 수 있습니다. 자세한 내용과 코드 샘플은 데이터베이스 연결 관리를 참조하세요.
유지관리 기간 중 언제든지 발생할 수 있는 유지관리 업데이트에 대한 애플리케이션의 응답을 테스트하세요. 인스턴스의 머신 유형 변경이 유지관리 업데이트에 가장 근접합니다. 단, 유지관리 업데이트 동안에는 장애 조치용 복제본이 먼저 업데이트(오프라인으로 전환)되고, 그런 다음 복제본의 업데이트가 완료되면 기본 인스턴스가 업데이트(오프라인으로 전환)됩니다. 머신 유형 변경의 경우 기본 인스턴스가 복제본보다 먼저 오프라인으로 전환됩니다. 애플리케이션이 유지보수 이벤트 후에 작업을 재개하도록 가급적 지수 백오프를 사용하여 최소 10분 동안 데이터베이스에 다시 연결을 시도해야 합니다. 자세한 내용은 데이터베이스 연결 관리를 참조하세요.
언제든지 발생할 수 있는 장애 조치에 대한 애플리케이션의 응답을 테스트하세요. Cloud Console, gcloud 명령줄 도구 또는 API를 사용하여 장애 조치를 수동으로 시작할 수 있습니다. 장애 조치 시작을 참조하세요.
대규모 트랜잭션은 피하세요. 트랜잭션을 작고 짧게 유지하세요. 대규모 데이터베이스 업데이트가 필요한 경우 하나의 큰 트랜잭션이 아니라 여러 건의 작은 트랜잭션으로 수행하세요.
Cloud SQL 프록시를 사용하는 경우 최신 버전을 사용하세요. Cloud SQL 프록시를 최신 상태로 유지하기를 참조하세요.

데이터 가져오기 및 내보내기

권장사항 추가 정보
작은 인스턴스 크기의 가져오기 속도를 높이세요. 작은 인스턴스의 경우 큰 데이터 세트를 가져올 때 성능을 개선하기 위해 일시적으로 인스턴스의 등급을 높일 수 있습니다.
Cloud SQL로 가져올 데이터를 내보내는 경우 적절한 절차를 사용하세요. 외부 관리 데이터베이스 서버에서 데이터 내보내기를 참조하세요.
내보낼 때 적절한 mysqldump 명령어를 사용하여 가져오기 속도를 높이세요. mysqldump 유틸리티를 사용하여 Cloud SQL로 가져올 데이터를 내보내는 경우 다음 옵션을 고려하세요.
  • --single-transaction 옵션을 사용하여 autocommit을 비활성화하고 단일 트랜잭션에서 파일 또는 테이블을 래핑합니다.
  • --extended-insert 옵션을 사용하여 각 INSERT 문에 많은 행을 포함시킵니다(기본적으로 사용 설정됨).
가져오기 및 내보내기를 사용하여 데이터를 마이그레이션하는 경우 가져오기에 내보내기와 정확하게 동일한 SQL 모드를 사용합니다. 가져오기와 내보내기에 동일한 SQL 모드 사용를 참조하세요.

백업 및 복구

권장사항 추가 정보
적절한 Cloud SQL 기능을 사용하여 데이터를 보호하세요.

데이터 중복 및 보호 기능을 제공하는 방법은 백업, point-in-time recovery, 내보내기입니다. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다.

백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 백업에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다.

point-in-time recovery는 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다. point-in-time recovery는 항상 새로운 인스턴스를 만듭니다. 즉, 기존 인스턴스에는 point-in-time recovery를 수행할 수 없습니다.

Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 선택한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다.