# \`could not create unique index\` 오류로 가져오기 실패

**URL:** <https://meta.discourse.org/t/import-failing-with-could-not-create-unique-index/154693>\
**Category:** Self-hosting\
**Created:** [6월 12, 2020, 7:10오후 UTC](https://meta.discourse.org/t/import-failing-with-could-not-create-unique-index/154693 "2020-06-12T19:10:16Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Paulus\_Schoutsen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paulus_schoutsen/32/183883_2.png) [@Paulus\_Schoutsen](https://meta.discourse.org/u/Paulus_Schoutsen)\
**Post date:** [6월 13, 2020, 5:09오전 UTC](https://meta.discourse.org/t/import-failing-with-could-not-create-unique-index/154693/6 "2020-06-13T05:09:37Z")

</div>

드디어 문제를 해결하고 다시 온라인으로 복귀했습니다. 힌트를 주신 @Falco 님께 감사드립니다.

다른 분들의 문제 해결에 도움이 되고자, 우리가 취한 조치들을 정리해 보았습니다.

수정되지 않은(손상된) 인덱스 몇 개가 가져오기(import) 실패를 유발하고 있었습니다. 중복 항목을 수동으로 삭제하여 문제를 해결할 수 있었습니다. 또한 `username_lower` 값이 중복된 사용자 8명이 있었습니다(마이크나 마르코 같은 이름이 너무 많았기 때문이죠). `username`과 `username_lower`를 모두 업데이트하여 해당 사용자들을 수정했습니다. 사용자 데이터를 확인한 결과, 첫 번째 데이터 손상은 2019년 12월에 발생한 것으로 파악되었습니다.

“백업 생성” → “백업 복원” → “중복 오류 발생” → "수정"이라는 사이클을 반복하는 대신, 모든 인덱스를 다시 인덱싱(reindex)하기로 결정했습니다. 다음 쿼리를 사용하여 고유 제약(unique constraint)이 있는 모든 인덱스를 찾았습니다:

```sql
select idx.relname as index_name, 
       insp.nspname as index_schema,
       tbl.relname as table_name,
       tnsp.nspname as table_schema
from pg_index pgi
  join pg_class idx on idx.oid = pgi.indexrelid
  join pg_namespace insp on insp.oid = idx.relnamespace
  join pg_class tbl on tbl.oid = pgi.indrelid
  join pg_namespace tnsp on tnsp.oid = tbl.relnamespace
where pgi.indisunique --<< 고유 인덱스만 조회
  and tnsp.nspname = 'public'

```

모든 인덱스가 정상적으로 작동하게 되자, 백업을 생성하여 새 인스턴스에 올바르게 가져올 수 있었습니다. 마이그레이션도 예상대로 실행되었고, 인스턴스를 교체한 후 정상적으로 서비스를 재개했습니다 👍 Discourse의 견고함에 감사드립니다 🍻

다시 한번 @Falco 님께 감사드립니다.

좋은 주말 보내세요 🙂

---

_[View the full topic](https://meta.discourse.org/t/import-failing-with-could-not-create-unique-index/154693)._
