REINDEX CONCURRENTLY — 운영 중 무중단 인덱스 재구성 전략
📋 실습 안내
✏️ CODE EDITOR (JSX)
▶ 실행 버튼을 눌러 코드를 테스트하세요.
👁️ 내 미리보기
내 코드 실행 결과
🎯 완성 미리보기
목표
위 에디터 코드를 수정해서 이 결과물과 똑같이 만들어보세요!
💡 TODO 주석을 채워서 위 결과물처럼 동작하게 만들어보세요
🤖 AI 선생님에게 질문하기
이번 강의 전용
▼
선생님이 답변 중이에요...
⚠️ 학습 관련 질문만 답변합니다. 관련 없는 질문은 자동으로 학습으로 유도됩니다.
Q1. 인덱스 Bloat이 발생하는 주요 원인은?
💡 PostgreSQL의 MVCC 구조에서 DELETE/UPDATE는 기존 행을 Dead Tuple로 남깁니다. VACUUM이 이를 재사용 가능 상태로 만들지만, 물리적 파일 크기는 줄지 않습니다. 특히 인덱스의 리프 페이지가 sparse해지면 Bloat이 발생합니다. REINDEX만이 물리적 크기를 줄일 수 있습니다.
Q2. REINDEX와 REINDEX CONCURRENTLY의 가장 중요한 차이는?
💡 일반 REINDEX는 테이블에 배타 락(AccessExclusiveLock)을 걸어 쿼리를 차단합니다. REINDEX CONCURRENTLY(PostgreSQL 12+)는 약한 잠금만 사용하여 읽기/쓰기를 허용하면서 재구성합니다. 단, 2배 정도 느리고 트랜잭션 외부에서만 실행 가능합니다.
Q3. REINDEX CONCURRENTLY 실행 중 실패했을 때 남는 부작용은?
💡 REINDEX CONCURRENTLY가 실패하면 내부적으로 생성된 임시 인덱스(idx_name_ccnew)가 INVALID 상태로 남습니다. 이를 방치하면 쓰기 시 인덱스 갱신 오버헤드가 생깁니다. DROP INDEX CONCURRENTLY로 정리 후 다시 시도해야 합니다.
Q4. pgstattuple의 avg_leaf_density 값이 45%일 때 권장되는 조치는?
💡 avg_leaf_density는 인덱스 리프 페이지의 데이터 밀도를 나타냅니다. 70% 미만이면 Bloat이 심한 것으로 간주하여 REINDEX를 권장합니다. 45%는 리프 페이지의 절반 이상이 빈 공간으로, 인덱스 스캔 효율이 크게 저하된 상태입니다.
Q5. REINDEX CONCURRENTLY가 없는 환경에서 무중단으로 인덱스를 교체하는 올바른 순서는?
💡 무중단 인덱스 교체는: (1) 새 이름으로 CREATE INDEX CONCURRENTLY 실행 — 완료 후 두 인덱스 공존, (2) 구 인덱스 DROP INDEX CONCURRENTLY — 무중단, (3) 새 인덱스를 원래 이름으로 RENAME. 이 순서를 지켜야 중간에 인덱스가 없는 상태를 피할 수 있습니다.
😅
아쉽네요!
점수: 0점 — 70점 이상이 되어야 통과합니다.