읽기 복제본 색인 개요

이 문서에서는 Cloud SQL Enterprise 버전 및 Cloud SQL Enterprise Plus 버전 모두에서 Cloud SQL 읽기 복제본의 보조 색인을 관리하는 개념과 메커니즘을 설명합니다. MySQL에서는 테이블에 두 가지 주요 유형의 색인을 만들 수 있습니다.

  • 클러스터형 색인: 디스크의 행을 물리적으로 정렬하는 MySQL 테이블의 기본 색인입니다. 테이블에 기본 키를 정의하면 MySQL은 이를 클러스터링된 색인으로 사용합니다. 테이블에는 클러스터형 색인이 하나만 있을 수 있습니다.

  • 보조 색인: 쿼리 성능을 최적화하는 MySQL 테이블의 추가 색인입니다.

    복제본은 일반적으로 읽기 전용이지만 보고 목적으로 테이블에 보조 색인을 만들 수 있습니다. Cloud SQL은 복제본 보조 색인을 만드는 두 가지 방법을 지원합니다.

    • 관리형 복제본 색인 (권장): Cloud SQL은 기본 인스턴스에 색인 정의를 저장하고 복제본 비정상 종료 또는 다시 생성 후 보조 색인을 자동으로 다시 빌드합니다. Google은 색인 손실을 방지하고 수동 색인 복원을 방지하기 위해 자체 관리형 색인보다 관리형 색인을 사용하는 것이 좋습니다.
    • 자체 관리형 복제본 색인: 복제본에서 직접 보조 색인을 추가하고 삭제할 수 있지만 이러한 색인은 복제본이 비정상 종료되거나 복제본이 다시 생성된 후에는 유지되지 않습니다. 자체 관리형 색인을 사용하는 경우 관리형 복제본 색인을 사용하도록 마이그레이션할 수 있습니다.

복제본 색인 메서드 비교

다음 표에서는 Cloud SQL의 관리형 복제본 색인과 자체 관리형 복제본 색인을 비교합니다.

기능 관리형 복제본 색인 자체 관리형 복제본 색인
복제본 재생성 간 지속성 자동으로 다시 빌드됨 삭제됨 (수동 재빌드 필요)
구성 모델 기본 인스턴스의 중앙 집중식 메타데이터 대상 읽기 복제본의 직접 DDL
실행 메커니즘 주기적인 백그라운드 프로세스
(약 5분마다)		 즉시 실행
복제 지연 가드레일 복제 지연이 20분을 초과하면 색인 생성을 자동으로 일시중지합니다. 없음 (사용자 관리)
지원되는 버전 Cloud SQL Enterprise 버전 및 Cloud SQL Enterprise Plus 버전 Cloud SQL Enterprise 버전 및 Cloud SQL Enterprise Plus 버전
지원되는 데이터베이스 버전 MySQL용 Cloud SQL
(유지보수 버전 R20260726.00_05 이상)		 MySQL용 Cloud SQL
(지원되는 모든 버전)
외부 서버 복제본 지원 지원되지 않음 지원됨

관리형 복제본 색인

복제본을 다시 만든 후 색인 손실을 방지하기 위해 Cloud SQL은 관리형 복제본 색인을 지원합니다. Google에서는 이 색인 생성 및 보관 방법을 권장합니다. Cloud SQL은 기본적으로 이 메서드를 사용 설정합니다.

관리형 복제본 색인에는 Cloud SQL 유지보수 버전 R20260726.00_05 이상이 필요합니다.

다음 섹션에서는 Cloud SQL이 복제본 색인을 유지하는 방법, 이점, 수명 주기 이벤트 중 동작 방식을 설명합니다.

Cloud SQL에서 관리형 복제본 색인을 유지하는 방법

이 방법을 사용하면 복제본 보조 색인을 정의하고 그룹화하며 이러한 색인 그룹을 유지할 수 있는 복제본을 지정합니다. Cloud SQL은 복제본에서 백그라운드 프로세스를 실행하여 필요한 색인을 자동으로 만들고 삭제하며 시간이 지남에 따라 색인을 유지보수합니다. Cloud SQL은 관리형 복제본 색인을 만들 때 색인 주석에 [SIC_X_Y] 태그를 추가합니다. 여기서 X 및 Y는 정수입니다. 이 태그는 내부 관리용으로만 사용되며 기능은 없습니다.

Cloud SQL은 색인 생성 및 삭제와 같은 관리형 복제본 색인 유지보수를 일괄적으로 수행합니다. Cloud SQL 색인 유지보수 프로세스에서 CREATE 또는 DROP 작업 그룹을 선택하면 각 보조 색인에 대해 PENDING 상태 항목을 만듭니다. 그런 다음 각 데이터 정의 언어(DDL) 문을 순차적으로 실행합니다. 한 색인에서 실패해도 큐에 있는 후속 색인의 실행이 차단되지 않습니다. 그러면 Cloud SQL은 약 5분 후에 다음 배치를 선택합니다.

장점 및 사용 사례

관리형 복제본 색인은 다음과 같은 이점을 제공합니다.

  • 자동 색인 보관: Cloud SQL이 읽기 복제본을 다시 만들면 (예: 인스턴스 비정상 종료 후) Cloud SQL은 해당 복제본에 매핑된 보조 색인을 자동으로 다시 빌드합니다. 누락된 색인을 복원하기 위해 수동 저장 프로시져를 실행하거나 외부 스키마 추적 스크립트를 유지할 필요가 없습니다.
  • 일관된 쿼리 성능: 복제본 복구 후 보조 색인을 자동으로 다시 빌드하여 Cloud SQL은 쿼리 처리량을 유지하고 색인이 생성되지 않은 쿼리로 인한 쿼리 지연 시간 급증 및 높은 CPU 사용률을 방지합니다.
  • 그룹 기반 구성: 기본 인스턴스에서 보조 색인을 한 번 정의하고 이름이 지정된 복제본 그룹으로 구성합니다. 그런 다음 단일 데이터베이스 플래그 (cloudsql_index_recreate_replica_group)를 설정하여 수백 개의 색인이 포함된 색인 그룹을 읽기 복제본에 할당할 수 있습니다. 이렇게 하면 여러 복제본에서 개별 저장 프로시져를 실행할 필요가 없습니다.
  • 복제본 역할별 선택적 색인 할당: 색인 그룹을 보고 및 분석 읽기 복제본에 구체적으로 할당하여 읽기 쿼리를 가속화하는 동시에 재해 복구 (DR) 읽기 복제본의 색인을 생성하지 않고 기본 인스턴스 스키마와 동일하게 유지할 수 있습니다. 이렇게 하면 DR 인스턴스에서 쓰기 트랜잭션 오버헤드와 복제 지연이 방지됩니다.
  • 기본 인스턴스 성능 격리: 읽기 복제본의 보조 색인은 스토리지를 사용하거나 기본 인스턴스에 쓰기 트랜잭션 지연 시간을 추가하지 않고 읽기 및 보고 쿼리를 최적화합니다.
  • 기본 제공 모니터링 가능성: 전용 저장 프로시저를 사용하면 읽기 복제본에서 색인 생성 진행 상황, 실행 시간, 오류 로그를 모니터링할 수 있습니다.
  • 중단 없는 마이그레이션 및 공존: 관리형 복제본 색인은 동일한 인스턴스 및 테이블에서 기존 자체 관리형 복제본 색인과 안전하게 공존합니다. 다운타임이나 활성 읽기 쿼리 워크로드 중단 없이 관리형 복제본 색인을 점진적으로 채택할 수 있습니다.

복제본 승격

Cloud SQL은 읽기 복제본 인스턴스에서만 관리형 복제본 색인을 유지합니다. 읽기 복제본을 기본 인스턴스로 승격하면 Cloud SQL은 관리형 복제본 색인으로 생성된 보조 색인을 자동으로 삭제합니다. Cloud SQL에서 삭제를 실행하기 전에 약 5분 정도 지연될 수 있습니다.

Cloud SQL은 승격된 인스턴스에서 보조 색인을 삭제하고 데이터베이스 플래그를 삭제하지만 기본 인스턴스는 보조 색인 정의와 그룹 매핑을 유지합니다.

재해 복구 (DR) 전환

DR 전환 중에 DR 복제본을 새 기본 인스턴스로 승격하면 Cloud SQL은 DR 복제본에 생성된 모든 보조 색인을 자동으로 삭제합니다. Cloud SQL은 이전 기본 인스턴스가 복제본이 될 때 이러한 보조 색인을 자동으로 만들지 않습니다.

전환 후 이전 기본 인스턴스에 보조 색인을 만들려면 해당 인스턴스에서 cloudsql_index_recreate_replica_group 데이터베이스 플래그를 설정합니다.

복제 지연

복제 지연이 20분을 초과하면 Cloud SQL은 보조 색인 생성 작업을 일시중지합니다. 지연이 20분을 초과할 때 관리형 복제본 색인 생성이 이미 진행 중인 경우 Cloud SQL은 작업을 완료합니다. 복제 지연은 관리형 복제본 색인 삭제 작업을 일시중지하지 않습니다.

제한사항

관리형 복제본 색인을 사용할 때는 다음 제한사항이 적용됩니다.

  • 외부 서버 복제본에서 관리형 복제본 색인을 만들 수 없음: Cloud SQL은 외부 서버 복제본의 관리형 복제본 색인 생성을 지원하지 않습니다.
  • 복제본 그룹당 최대 1,000개의 색인: 복제본 그룹에 최대 1,000개의 보조 색인을 할당할 수 있습니다.
  • 색인 메타데이터 업데이트 또는 변경은 지원되지 않음: 기존 색인 메타데이터를 업데이트하거나 변경할 수 없습니다. 색인을 수정하려면 기존 색인 정의를 삭제하고 새 색인 정의를 만들어야 합니다.

자체 관리형 복제본 색인

자체 관리형 복제본 색인은 개별 Cloud SQL 읽기 복제본에서 직접 만들고 삭제하는 보조 색인입니다. 관리형 복제본 색인과 마찬가지로 기본 인스턴스에서 스토리지를 사용하거나 쓰기 지연 시간에 영향을 주지 않고 보고 및 분석 워크로드와 같은 읽기 쿼리 성능을 최적화합니다.

자체 관리형 색인 관리

mysql 스키마에서 다음 저장 프로시져를 사용하여 읽기 복제본에서 직접 자체 관리형 복제본 색인을 관리합니다.

  • mysql.addSecondaryIdxOnReplica: 읽기 복제본의 지정된 테이블에 보조 색인을 추가합니다. 이 저장 프로시저는 CREATE INDEX DDL 문의 래퍼입니다.
  • mysql.dropSecondaryIdxOnReplica: 읽기 복제본에서 이전에 만든 보조 색인을 삭제합니다. 이 저장 프로시저는 DROP INDEX DDL 문의 래퍼입니다.

이러한 저장 프로시저를 실행하려면 cloudsqlsuperuser 역할이 필요합니다.

자체 관리형 색인을 만들면 Cloud SQL은 데이터베이스 이름, 테이블 이름, 색인 이름을 포함한 기본 메타데이터를 복제본의 mysql.cloudsql_replica_index 테이블에 기록합니다. 관리형 복제본 색인과 달리 자체 관리형 색인은 기본 인스턴스에 등록되지 않으며 Cloud SQL 백그라운드 복제 프로세스에서 유지보수되지 않습니다.

문법 세부정보 및 사용 예시는 자체 관리형 복제본 색인을 참조하세요.

장점 및 사용 사례

자체 관리형 복제본 색인은 특정 워크플로에 다음과 같은 이점을 제공합니다.

  • 기본 인스턴스 성능 격리: 읽기 복제본의 보조 색인은 스토리지를 사용하거나 기본 인스턴스에 쓰기 트랜잭션 지연 시간을 추가하지 않고 읽기 및 보고 쿼리를 최적화합니다.
  • 즉시 실행: 저장 프로시져 호출은 관리형 복제본 색인에 필요한 주기적인 백그라운드 유지보수 주기 (약 5분마다)를 기다리지 않고 복제본에서 DDL 문으로 즉시 실행됩니다.
  • 격리된 테스트 및 실험: 복제본 그룹 전체에서 관리형 복제본 색인을 만들기 전에 개별 읽기 복제본에서 쿼리 성능을 테스트하고 색인 최적화를 검증할 수 있습니다.

제한사항

자체 관리형 복제본 색인에는 다음과 같은 중요한 운영 제한사항이 있습니다.

  • 복제본 재생성 시 지속성 부족: Cloud SQL이 읽기 복제본을 재생성하는 경우 (예: 인스턴스 복구, 유지보수, 하드웨어 장애 중) 해당 복제본의 모든 자체 관리형 보조 색인이 삭제되고 자동으로 복원되지 않습니다.
  • 수동 복원 오버헤드: Cloud SQL은 색인을 재구성하고 다시 빌드할 수 없습니다. mysql.addSecondaryIdxOnReplica를 다시 실행하여 색인을 수동으로 다시 만들어야 합니다.
  • 쿼리 성능 저하: 누락된 색인을 수동으로 다시 빌드할 때까지 복제본을 다시 만든 후 읽기 쿼리의 성능이 저하될 수 있습니다.

관리형 복제본 색인은 복제본 재생성 이벤트 전반에서 자동으로 유지되고 다시 빌드되므로 프로덕션 워크로드에 관리형 복제본 색인을 사용하는 것이 좋습니다. 기존 자체 관리형 색인이 있는 경우 관리형 복제본 색인으로 마이그레이션합니다.

복제본 색인 유형의 공존

자체 관리형 복제본 색인(mysql.addSecondaryIdxOnReplica를 사용하여 생성됨)과 관리형 복제본 색인은 동일한 Cloud SQL 읽기 복제본 인스턴스와 동일한 테이블에 공존할 수 있습니다. 이를 통해 기존 데이터베이스 워크로드를 중단하지 않고 관리형 복제본 색인을 점진적으로 채택할 수 있습니다.

두 색인 관리 방법을 모두 사용할 때는 다음 동작을 고려하세요.

  • 독립적인 작업: 읽기 복제본에서 직접 만드는 자체 관리형 색인은 관리형 복제본 색인과 함께 계속 작동합니다.
  • 정기 평가: Cloud SQL 백그라운드 유지보수 프로세스는 복제본에 할당하는 복제본 그룹에 매핑된 색인 정의를 정기적으로 (약 5분마다) 평가합니다.
  • 이름 충돌 처리: 읽기 복제본에 기존 자체 관리형 색인과 동일한 이름으로 관리형 복제본 색인 정의를 등록하면 백그라운드 프로세스에서 해당 이름의 색인이 이미 있음을 감지합니다. 이 프로세스는 mysql.cloudsql_replica_idx_status 테이블에 FAILED 상태를 기록합니다. 이 오류는 데이터베이스 트래픽에 영향을 주지 않으며, 테이블 잠금을 만들거나 기존 자체 관리형 색인에 영향을 주지 않습니다.
  • 다시 만들 때 자동 해결: 읽기 복제본을 다시 만들면 Cloud SQL은 인스턴스 다시 만들기의 일환으로 기존 자체 관리형 색인을 삭제하고 등록된 정의에서 관리형 복제본 색인을 자동으로 만듭니다.

다음 단계