잘못된 인덱스 재구축

제품 지원 자체 호스팅
1

180만 개 포스트가 있는 사이트를 2.7.0.beta2로 업그레이드하고, 이와 함께 PG10에서 PG13으로의 업그레이드도 진행했습니다. beta3가 방금 출시되었고 "데이터베이스 마이그레이션 성능 개선"이 포함되어 있다고 해서 바로 다시 업그레이드했습니다.

reindex concurrently를 시도하면 다음과 같은 오류가 발생합니다.

WARNING:  cannot reindex invalid index "public.allowed_pm_users_pkey_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "public.index_allowed_pm_users_on_user_id_and_allowed_pm_user_id_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "public.index_allowed_pm_users_on_allowed_pm_user_id_and_user_id_ccnew" concurrently, skipping

해당 인덱스를 삭제하고 다시 인덱싱하려고 했지만, 현재 소스에서 ccnew를 찾을 수 없어 어떻게 해야 할지 모르겠습니다.

2

다음 글에 따르면 _ccnew 인덱스는 동시 재인덱싱(concurrent reindex) 과정의 일부인 것 같습니다:

  • 재인덱싱 대상 인덱스의 복제본(일부 예외가 있음, 예를 들어 파티션 인덱스는 생성 시점에 상속 의존성이 등록되지 않고 스왑 시점에 등록됨)으로 카탈로그에 새로운 인덱스를 생성합니다. 이 새로운 임시 인덱스에는 “_ccnew” 접미사가 붙습니다. 간단히 말해.

concurrently 키워드 없이 해당 인덱스를 재인덱싱할 수 있을까요?

또는, 같은 글의 후반부에서:

그러면 REINDEX TABLE CONCURRENTLY는 잘못된(invalid) 인덱스를 건너뜁니다. 왜냐하면 연속적이고 여러 번의 실패가 발생하는 경우, 인덱스 수가 단순히 증가하여 각 실행마다 두 배가 되고, 후속 재인덱싱 작업에 많은 불로트(bloat)를 유발할 수 있기 때문입니다:
…
그러나 REINDEX INDEX CONCURRENTLY만으로도 잘못된 인덱스를 재인덱싱하는 것은 가능합니다:

3

_ccnew는 이전의 reindex concurrently에서 생성을 시도했지만 실패한 인덱스들을 가리키며, 보통 고유성 제약 조건을 위반하기 때문에 생성이 되지 않은 경우입니다. 실패한 reindex concurrently 시도는 해당 위치에 남아 있으므로 수동으로 삭제해야 합니다.

reindex concurrently를 두 번째로 실행할 때 PostgreSQL은 이러한 실패 잔여물을 건너뜁니다.

4

라파엘, 감사합니다! 그게 문제였네요. 해당 인덱스를 drop하고 다시 동시 재인덱싱을 수행했는데 아무 문제 없었습니다.