읽기 복제본의 인덱스는 왜 사라졌나
Cloud SQL MySQL 읽기 복제본 인덱스는 보고서나 분석 쿼리의 성능을 높이기 위해 복제본에만 추가하는 보조 인덱스다. 기존 자체 관리형 방식에서는 복제본에 직접 인덱스를 만들었다. 그러나 복제본 장애나 재생성 이후 이 인덱스가 유지되지 않아 관리자가 다시 만들어야 했다.
2026년 10월 28일 정식 출시된 managed replica indexes(관리형 복제본 인덱스)는 주 인스턴스(primary)에 인덱스 정의를 저장하고 복제본 그룹에 연결한다. 복제본을 다시 만들 때 백그라운드 작업이 정의를 읽어 보조 인덱스를 재구축한다. 주 인스턴스의 모든 인덱스를 자동 복제하는 기능과는 다르다.
지원 환경과 자동 관리의 조건
공식 발표 기준 Cloud SQL Enterprise 및 Enterprise Plus의 MySQL 8.0 이상이 대상이며, 최소 유지보수 버전 R20260726.00_05 이상이 요구된다. 운영 인스턴스의 유지보수 버전부터 확인해야 한다. 외부 서버 복제본에는 관리형 인덱스를 지원하지 않는다.
복제본 그룹 하나당 인덱스 정의 최대 1,000개를 관리하고, 한 복제본에는 동시에 하나의 인덱스 그룹만 지정할 수 있다. 자동 재생성에 관한 기본 플래그가 활성 상태여도 그룹 지정 플래그가 비어 있다면 임의의 인덱스가 관리 대상이 되지는 않는다. Cloud SQL 인덱스 자동 복원을 사용하려면 정의 등록과 그룹 매핑이 선행돼야 한다.
설정 순서: 주 인스턴스에 정의를 만들고 복제본에 그룹 연결
먼저 주 인스턴스에서 제공 저장 프로시저로 CREATE INDEX 문을 등록한다. 다음으로 반환된 정의 ID를 원하는 그룹에 추가하고, 읽기 복제본 인스턴스의 데이터베이스 플래그 cloudsql_index_recreate_replica_group을 그 그룹 이름으로 지정한다. 아래 SQL은 공식 호출 형식을 설명하는 예시이며 실제 테이블·열 이름과 DDL 검증 후 사용해야 한다.
예시 ① CALL mysql.cloudsql_replica_idx_defn_create('report_idx','CREATE INDEX idx_created_at ON app.orders (created_at)');
예시 ② CALL mysql.cloudsql_replica_idx_group_add(반환된_정수_ID,'reporting_group');
예시 ③ 읽기 복제본 플래그 cloudsql_index_recreate_replica_group=reporting_group
이 저장 프로시저에는 cloudsqlsuperuser 권한이 필요하며 호출 시 COMMIT이 수행된다. 사용자 애플리케이션에서 별도 트리거나 사용자 정의 저장 프로시저를 설치하는 방식이 아니라 Cloud SQL이 제공하는 관리 인터페이스다.
5분 배치·FAILED·복제 지연, 무엇을 확인해야 하나
인덱스 재생성은 즉각 처리되는 것이 아니라 약 5분 간격의 비동기 유지보수 작업으로 진행된다. 인덱스 상태는 PENDING, RUNNING, DONE 등으로 변하며 실패 시 FAILED와 오류 기록을 확인할 수 있다. 실패한 인덱스 생성은 약 1시간 후 재시도된다. 따라서 새 정의를 등록했다고 곧바로 사용 가능한 것은 아니다.
MySQL 복제본 인덱스 상태 확인에는 복제본에서 CALL mysql.cloudsql_replica_idx_show_status(); 또는 CALL mysql.cloudsql_replica_idx_show_errors(); 등을 사용한다. Cloud SQL replica index FAILED 상태라면 오류와 기존 동일 이름의 인덱스 존재 여부를 먼저 점검해야 한다.
복제 지연이 20분을 넘으면 새 인덱스 생성이 일시 중단된다. 이미 시작된 생성이 완료될 수 있으며 삭제 작업까지 모두 멈추는 것은 아니다. 이는 복제 지연을 해소하면 무조건 즉시 복구된다는 보증이 아니라 작업 상태를 따로 모니터링해야 한다는 뜻이다.
복제본 승격·DR·기존 인덱스 전환에서 놓치기 쉬운 점
읽기 복제본을 주 인스턴스로 승격하면 관리형 복제본 인덱스가 자동 제거되며, 제거 작업에도 시간이 걸릴 수 있다. 재해복구(DR) 전환 후 이전 primary가 replica로 바뀌더라도 관리형 인덱스가 자동 생성된다고 가정하면 안 된다. 새 역할에 맞춰 그룹 플래그를 검토해야 한다.
Cloud SQL 복제본 인덱스 전환 시 기존 자체 관리 인덱스와 같은 이름으로 관리형 정의를 등록하면 충돌로 FAILED가 발생할 수 있다. 재생성 시점까지 기다리거나 기존 인덱스를 제거하고 관리형으로 다시 만들 수 있지만, 즉시 제거 방식은 인덱스가 없는 동안 읽기 쿼리가 느려질 위험이 있다. 운영 중 전환에는 점검 시간과 쿼리 성능 모니터링이 필요하다.
관리형 인덱스의 기존 정의를 직접 ALTER하는 방식도 지원되지 않는다. 변경이 필요하면 정의를 제거하고 새로운 정의로 다시 등록하는 절차를 검토한다.
도입 결정 전에 확인할 사항
도입을 검토하는 팀은 먼저 에디션·MySQL·유지보수 버전을 확인하고, 인덱스 정의가 실제로 관리형 그룹에 연결됐는지 검사해야 한다. 다음으로 복제 지연, 인덱스 생성 실패, 승격과 DR 전환 시나리오를 리허설하고 모니터링 지표를 정해두는 것이 실무적으로 유용하다. 이는 공식 기능의 자동 보장 범위가 아니라 운영 권고다.
별도 과금 여부, 모든 리전에서 동일한 가용성, 특정 비율의 쿼리 성능 개선은 이번 확인 자료만으로 단정할 수 없다. 공식 기능 설명은 존재하지만 실제 운영 인스턴스의 CLI·SQL 실행이나 독립 성능 벤치마크는 수행하지 않았다. 적용 전 현재 리전과 요금 조건을 다시 확인해야 한다.
