데이터베이스 삭제 후 디스크 공간 확보


12

나는 dev 시스템에서 일하고 있는데, 나는 dev 목적으로 사용하고있는 데이터베이스 (foo)를 복원하고있다. 꼬임을 통해 작업하면서 방금 DROP DATABASE foo를 실행했습니다. 그러나 디스크의 모든 공간을 차지한다는 것을 빨리 깨달았습니다. 쓰레기.

다른 논리적 데이터베이스에서 VACUUM FULL이 이전에 삭제 한 데이터베이스 (foo)에서 공간을 비우나요? 나는 다른 논리적 데이터베이스에서 이것을 시도했지만 여유 공간이 회수되었지만 내가 만든 모든 CREATE DATABASE / DROP DATABASE 호출을 설명하는 것으로 충분하지 않다고 생각합니다. 내가 실행 한 논리 데이터베이스를 VACUUM 's했을 수 있습니다.

전체 데이터베이스 초기화를 수행하지 않고 해당 공간을 회수 할 수있는 방법이 있어야합니까?

편집하다

따라서 다음 단계에 따라 백업에서 데이터베이스를 다시 초기화했습니다 . 복원 후 디스크의 공간을 확보했습니다! 현재로서는 작동하지만 삭제 된 데이터베이스를 정리하는 방법에 대한 도움이 여전히 유용합니다.

편집 2

그래서이 문제에 대한 더 많은 정보를 수집했습니다 ... 다음은 제가 예를 들어 생각해 낸 것입니다.

Initial partition size:
                       Size   Used  Avail Use% Mounted on
                        25G   8.1G    16G  35% /apps1

After creating my new database and populating it:
                        25G    18G   6.4G  73% /apps1

After Dropping the database using "DROP database mydb" from a separate logical DB:
                        25G    13G    11G  56% /apps1

새 DB가 디스크에서 ~ 9.6GB를 차지한 것으로 보입니다. 그러나이를 삭제 한 후 재생 디스크 공간은 ~ 4.6G 만 증가했습니다. 그래서 약 5GB의 공간이있어서 무슨 일이 일어나고 있는지 궁금해합니다!?

그리고 다시 만들고 채우고 다시 놓아도이주기가 계속됩니다.

"DROP DATABASE"명령이 발행 된 후에 무엇이 남아 있는지 아는 사람이 있습니까?


보관 기능이 켜져 있다는 점도 주목할 가치가 있습니다. WAL 보관 파일이 작성되는 위치가 다소 큰 것 같습니다. 나는 그것을 면밀히 모니터링하지 않았습니다. 위에 나열된 동일한 절차를 시도하고 해당 디렉토리에서 "du"를 실행하여 모든 공간이 회수되는지 확인합니다. 다시보고하겠습니다.
Jmoney38

나는 진공이 도움이되지 않는다고 가정합니까?
rogerdpack

답변:


6

시도 sudo lsof| grep deleted및 PostgreSQL의 처리가 나타나면 확인합니다. 이 명령은 삭제되었지만 파일 디스크립터가 프로세스에 의해 여전히 열려있는 파일을 찾습니다. 다른 부작용이다 df -hdu -sh /다르다. 이 때문에 du모든 파일의 크기가 최대 파일 시스템과 합계에서 외모와 df물리적 장치를 살펴 봅니다.

방금 후 공간을 확보하지 않은 데이터베이스에 문제 DROP table가 있었고 그 원인이되었습니다.

내가 아는 유일한 해결책은 데이터베이스를 다시 시작하는 것입니다. 리로드 (SIGHUP)를 보내려고 할 수 있습니다.


2
lsof | grep deleted팁은 좋은 사람이었다; 여기에는 여전히 활성화 된 postgresql 세션을 결정하고 세션을 종료하여 파일을 해제하기 만하면됩니다. 필자의 경우, 거의 모든 IDLE 또는 COMMIT에서 500 개 이상의 활성 연결 중 하나 SELECT * FROM pg_stat_activity가 ANALYZE에서 발견되어 갇힌 단일 연결을 삭제하면 삭제 된 파일을 해제하기에 충분했습니다. ! 00GB가 해제되었습니다.
Alex North-Keys

5

내 이해는 데이터베이스를 삭제하면 파일과 파일이 사라진다는 것입니다.

테이블 스페이스를 사용하지 않는 한, 각 데이터베이스는 $ PGDATA / base 아래의 자체 서브 디렉토리에 데이터를 가져야합니다. 예를 들어 내 서버 중 하나를 사용하여 (postgres 사용자로) :

-bash-3.2$ cd $PGDATA/base

-bash-3.2$ ls | wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

이제 새 데이터베이스를 만들면 $ PGDATA / base 아래에 하나 이상의 하위 디렉토리가 있어야합니다.

-bash-3.2$ createdb foo

-bash-3.2$ ls | wc -l
10

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
6.9M    83637
8.0K    pgsql_tmp

다음은 우리가 보는 것입니다 ($ PGDATA / base / 83637은 새 데이터베이스의 하위 디렉토리입니다).

해당 데이터베이스를 삭제하면 데이터 파일도 삭제해야합니다.

-bash-3.2$ dropdb foo

-bash-3.2$ ls wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

$ PGDATA / base / 83637 디렉토리가 사라지면 진공 청소기로 청소할 것이 없습니다.

디스크 공간을 차지하는 다른 것이 없습니까? 다른 데이터베이스 중 하나입니까? 로그 파일?

시도 할 수있는 것은 다음과 같습니다.

-bash-3.2$ cd $PGDATA
-bash-3.2$ du -sh `ls` > ../pre_sizes

다양한 데이터베이스 작업, 작성, 삭제 등을 수행 한 후 다음을 수행하십시오.

-bash-3.2$ du -sh `ls` > ../post_sizes

디스크 공간이 어디로 가고 있는지 알 수 있습니다.


테이블을 추가하면 새 DB가 기본 디렉토리에 나타나고 제거하면 사라집니다. 그러나이 디렉토리는 크기의 전체 차이 (예 : ~ 9.6GB)를 구성하지 않는 것 같습니다
Jmoney38

@ Jmoney38- ls데이터베이스 추가 / 삭제를 수행하기 전후에 $ PGDATA 디렉토리 에서 "du -sh "를 수행하는 것이 권장되는 이유 는 다른 디렉토리에서 도약 및 경계가 증가하고 있음을 표시해야하기 때문입니다.
gsiems 2016 년

@ Jmoney38-추측해야한다면 차이점은 $ PGDATA / pg_log 및 / 또는 $ PGDATA / pg_xlog 디렉토리에 있습니다. 로그 파일은 클러스터 용이며 데이터베이스를 삭제할 때 잘리지 않습니다.
gsiems 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.