데이터 정리 후 데이터베이스 컨테이너의 용량 증가를 막는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Stop a Database Container From Growing After Data Cleanup - Zima Store Online

데이터를 정리한 후에도 데이터베이스 컨테이너의 크기가 계속 증가할 수 있습니다. 삭제된 행, 트랜잭션 로그, 인덱스, 컨테이너 로그는 각각 공간을 회수하는 규칙이 다르기 때문입니다.

컨테이너의 전체 디스크 사용량이 증가한다고 해서 데이터베이스 볼륨도 커지고 있다고 단정하지 마세요. 데이터베이스 데이터 디렉터리, WAL 또는 binlog 디렉터리, Docker 로그 파일, 쓰기 가능 레이어, 백업 또는 임시 경로를 각각 측정하세요. 그런 다음 삭제된 데이터베이스 공간이 내부적으로 재사용 가능하지만 호스트로 반환되지 않는지, 실제로 재작성 작업이 필요한지, 아니면 전혀 다른 파일이 계속 증가하고 있는지 확인해야 합니다.

계속 증가하는 경로 확인하기

한 번의 정리 주기 전후로 명명된 볼륨 또는 바인드 마운트된 데이터베이스 디렉터리, 컨테이너 쓰기 가능 레이어, 호스트 측 컨테이너 로그, 데이터베이스 트랜잭션 로그 디렉터리, 덤프 또는 임시 디렉터리의 크기를 기록하세요.

PostgreSQL 디스크 공간 문제 해결 가이드도 같은 원칙에서 시작합니다. 회수 작업을 선택하기 전에 먼저 공간이 어디에서 사용되는지 확인해야 합니다.

Docker 로그만 증가한다면 데이터베이스 정리는 관련이 없습니다. 데이터 파일 크기는 그대로지만 정리 후 증가가 멈춘다면, 호스트 파일 시스템에서는 크기가 줄어들지 않더라도 데이터베이스 엔진이 이미 해제된 페이지를 재사용하고 있을 수 있습니다.

재사용 가능한 데이터베이스 공간과 반환된 디스크 공간 구분하기

많은 트랜잭션 데이터베이스는 행을 삭제한 직후 테이블 중간의 파일 블록을 즉시 제거하지 않습니다. 대신 내부 페이지를 표시하거나 회수하여 이후 삽입 작업에서 해당 공간을 재사용할 수 있도록 하며, 기반 파일의 크기는 그대로 유지합니다.

PostgreSQL이 명확한 예입니다. 일반적인 VACUUM은 공간을 내부적으로 재사용하지만, 일반적으로 파일 중간 영역을 운영 체제에 반환하지는 않습니다.

정리 후 새 데이터를 삽입할 때 파일이 계속 증가하는지 확인하세요. 파일 크기는 안정적이고 내부 팽창만 감소하는 상황은 제어되지 않는 증가와 다르며, 일반적으로 긴급한 재작성 작업을 정당화하지 않습니다.

일반적인 Docker 정리가 아닌 데이터베이스 엔진의 회수 방법 사용하기

호스트에 용량을 반환하려는 경우 먼저 엔진과 저장 형식을 확인하세요. PostgreSQL, MySQL 또는 MariaDB, SQLite는 서로 대체할 수 있는 하나의 축소 명령을 사용하지 않으며, 일부 회수 작업은 대용량 파일을 재작성하거나 테이블을 잠글 수 있습니다.

MySQL 저장소 관련 글에서는 OPTIMIZE가 InnoDB 테이블을 재구축할 수 있음을 설명합니다. 이는 DELETE가 실행되었다고 해서 호스트가 즉시 해당 바이트를 되찾아야 한다는 의미는 아닙니다.

재작성 작업을 수행하기 전에 데이터베이스를 백업하고 충분한 작업 공간이 있는지 확인하세요. 대용량 테이블의 두 번째 복사본이 필요한 명령을 실행하기에 홈 서버 파일 시스템의 여유 공간이 거의 없는 상황은 최악입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

WAL, Binlog 및 복제 보존 정책을 별도로 확인하기

오래된 애플리케이션 행을 삭제한 후에도 트랜잭션 로그는 계속 증가할 수 있습니다. 아카이브 작업 실패, 오래된 복제 슬롯, 지연된 복제본, 장시간 실행 중인 트랜잭션 또는 백업 보존 요구 사항으로 인해 과거 로그 세그먼트가 디스크에 계속 남을 수 있습니다.

최근 PostgreSQL 복구 관련 문서에서는 사용자가 방금 정리한 테이블 데이터와 무관하게 WAL 보존이 저장 공간을 차지할 수 있음을 보여 줍니다.

WAL 또는 binlog 파일을 파일 시스템에서 직접 삭제하지 마세요. 데이터베이스 엔진을 통해 보존 원인을 해결한 다음 정상적인 로그 재활용이 다시 이루어지는지 확인하세요.

Docker 로그 제한 및 쓰기 가능 레이어 확인하기

표준 출력이나 표준 오류가 제한 없이 Docker 로그에 저장되거나, 임시 내보내기 파일·캐시·데이터베이스 파일이 의도한 영구 볼륨이 아닌 컨테이너 레이어에 기록되면 데이터베이스 컨테이너가 증가하는 것처럼 보일 수 있습니다.

셀프 호스팅 Docker 사례에서는 로그 로테이션이 설정되지 않은 경우 컨테이너 로그가 무한히 증가할 수 있음을 설명합니다.

무언가를 삭제하기 전에 각 대용량 호스트 파일을 컨테이너 내부 경로와 연결해 확인하세요. 향후 증가를 방지하도록 로그 로테이션을 설정하고, 데이터베이스 상태를 임시 쓰기 가능 레이어에 의존하지 말고 명시적인 볼륨에 저장하세요.

정리 작업으로 지속 가능한 여유 공간이 확보되는지 확인하기

선택한 공간 회수 작업을 완료한 후 대표적인 기간 동안 일반적인 쓰기 작업을 실행하고, 호스트의 여유 공간, 데이터베이스 파일 크기, 트랜잭션 로그 크기, Docker 로그, 내부 여유 공간 또는 팽창 지표를 비교하세요.

PostgreSQL 저장 공간 축소 가이드는 모든 삭제 작업이 운영 체제의 파일 크기를 즉시 줄인다고 가정하기보다 대상에 맞는 유지 관리가 필요함을 강조합니다.

예상되는 데이터베이스 증가분이 재사용되거나 제한되고, 각 정리 주기 후 호스트의 용량이 설명할 수 없는 방식으로 더 이상 줄어들지 않으면 문제가 해결된 것입니다. 데이터베이스 파일을 재작성하는 작업을 수행하기 전에 롤백 기준을 마련하려면, 관련 ZimaSpace 가이드의 일관된 데이터베이스 컨테이너 백업을 참고하세요.