부분적으로 구축되어 정전으로 종료 된 인덱스가 차지하는 공간을 회수하는 방법


9

Mac (10.10.4)에서 postgres (postgis) 9.4.2를 실행하고 있습니다.

나는 몇 개의 큰 테이블 (몇 TB)을 가지고 있습니다.

일주일 정도 걸리는 인덱스를 구축하는 동안 배터리 유닛과 시스템보다 정전이 오래 지속될 때 인덱스가 완료 될 것으로 예상되는 시점에서 사용 가능한 HD 공간이 줄어드는 것을 보았습니다. 내려 갔다. 버퍼가 꺼져 있었고 fillfactor=100정적 데이터 소스이므로 빌드 중입니다. 다시 부팅 할 때 드라이브에 남아있는 사용 가능한 공간은 인덱스 빌드의 거의 끝 부분에 있습니다. 진공 분석은 공간을 확보하지 않습니다.

나는 테이블을 떨어 뜨리고 다시 시도했지만 공간을 떨어 뜨리지 않았습니다. 이제 색인을 만들 공간이 부족한 곳에 있습니다.

인덱스 빌드 중에 생성 된 파일이 정전 중에 시스템이 다운되는 방식으로 인해 시스템에서 제거 할 수없는 일부 림보에 갇혀 있습니까?

db의 테이블 크기 + 인덱스 (해당 드라이브의 유일한 데이터)를 보면 최대 6TB가 됩니다. 드라이브는 8TB 이고 드라이브에 500GB 미만의 메모리가 남아 있으므로 인덱스 크기보다 약 1.5TB 정도 손실 된 것 같습니다.

어떤 아이디어?


색인이 여전히 이와 같은 쿼리로 나열되어 있습니까? SELECT r.relname, r.relkind, n.nspname FROM pg_class r INNER JOIN pg_namespace n ON r.relnamespace = n.oid WHERE relkind = 'i';
Kassandry

아니요, 해당 쿼리의 결과에 표시되지 않습니다.
dkitchel

1
당신은 목록에 SELECT indexrelid::regclass, indrelid::regclass FROM pg_catalog.pg_index WHERE NOT indisvalid;당신에게 제공하는 것이 있습니까?
dezso

아냐, 비어있어
dkitchel

답변:


5

일반적으로 postgres가 다시 시작되면 응급 복구 프로세스가 롤백 된 인덱스와 관련된 파일을 데이터 디렉토리에서 제거했을 것으로 예상됩니다.

작동하지 않거나 최소한 수동으로 점검해야한다고 가정 해 봅시다.

datadir에 있어야하는 파일 목록은 다음과 같은 쿼리로 설정할 수 있습니다.

select pg_relation_filenode(oid)
   from pg_class
  where relkind in ('i','r','t','S','m')
    and reltablespace=0
  order by 1;

reltablespace=0기본 테이블 스페이스입니다. 기본이 아닌 테이블 스페이스에서 문제점이있는 인덱스를 작성한 경우의 0OID로 바꿔야합니다 pg_tablespace.

i, r, t, S, m은 relkind각각 인덱스, 테이블, 토스트 공간, 시퀀스, 구체화 된 뷰에 해당합니다. 이러한 모든 객체는 이름이 일치하는 파일에 데이터를 갖습니다 pg_relation_filenode(oid).

디스크에서 데이터 파일은 아래에있는 $PGDATA/base/oid/oid은 IS oid데이터베이스에 의해 얻을 select oid,datname from pg_database. 기본 테이블 스페이스에 대해 이야기하지 않으면 대신 base대체 PG_version_somelabel됩니다.

해당 디렉토리의 relfilenode와 일치하는 파일을 나열하고 정렬하십시오.

ls | grep -E '^[0-9]+$' | sort -n > /tmp/list-of-relations.txt

(실제로 1Gb보다 큰 관계의 첫 번째 세그먼트 만 유지합니다. 느린 세그먼트가 연결되어 있지 않으면 별도로 고려되어야합니다)

위의 쿼리 결과로 해당 파일을 비교하십시오.

db가 알고있는 객체에 해당하지 않는 데이터 파일이 남아 있으면 해당 diff에 나타나야합니다.


대박! datadir에서 선택 목록에 표시되지 않은 파일 1 개를 찾았습니다. 해당 파일을 안전하게 제거 할 수 있습니까?
dkitchel

실제로 499807.484와 같이 점 뒤에 반복되는 약 800 개의 파일에 해당합니다.이 파일을 안전하게 제거 할 수 있습니까?
dkitchel

@ dkitchel : 그것은 거대한 지수에 대해 각각 1Gb의 세그먼트입니다. 인덱스 생성이 실행될 때 타임 스탬프가 일치하는지 확인하십시오. 그것들을 삭제하는 것에 관해서는, 나는 위의 나의 추론이 정확하기를 희망하지만 그것이 당신의 데이터이므로 궁극적으로 결정입니다!
Daniel Vérité

예, 타임 스탬프는 인덱스가 작성 될 때와 일치하며 파일 크기의 합은 인덱스 크기와 일치합니다. 당신의 추론은 확실해 보입니다. 나는 그것을 확신을 가지고 갈 것이다. 정말 감사합니다.
dkitchel

동일한 곤경에 처한 다른 사람들이 @DanielVerite의 솔루션을 자신있게 사용할 수 있도록 추적합니다. 그의 솔루션은 실제로 완벽하게 작동했습니다.
dkitchel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.