MongoDB 배포 환경에서의 디스크 공간 관리 및 확보
MongoDB 디스크 사용량을 모니터링하고, 과도한 컬렉션과 인덱스를 찾아내며, TTL, 압축 또는 복원 워크플로를 통해 안전하게 공간을 확보하는 방법을 알아봅니다.
MongoDB 배포에서 디스크 공간 관리 및 확보
MongoDB 디스크 공간 문제는 일반적으로 두 가지 방식으로 나타납니다: 파일 시스템이 거의 가득 찼거나, 데이터를 삭제한 후에도 MongoDB가 여전히 크게 보이는 경우입니다. 두 번째 경우는 WiredTiger가 내부적으로 확보된 공간을 재사용할 수 있지만 운영 체제에 즉시 반환하지 않기 때문에 많은 팀을 놀라게 합니다.
목표는 실제 성장, 재사용 가능한 내부 여유 공간, 과도한 인덱스, 그리고 유지 관리 창이 필요한 조각화를 구분하는 것입니다.
호스트 수준에서 디스크 사용량 확인
MongoDB의 dbPath가 포함된 파일 시스템부터 시작하세요. 해당 볼륨이 가득 차면 MongoDB가 안전하게 쓰기를 계속할 수 없습니다.
df -h /var/lib/mongodb
또한 어떤 디렉토리가 증가하고 있는지 확인하세요:
du -sh /var/lib/mongodb/* | sort -h
실제 dbPath를 사용하세요; /var/lib/mongodb는 Linux 패키지에서 일반적이지만 보편적이지는 않습니다.
MongoDB 스토리지 메트릭 확인
mongosh 내에서 논리적 데이터 크기와 할당된 스토리지 크기를 비교하세요.
use myDatabase
db.stats()
유용한 필드는 다음과 같습니다:
dataSize: 문서 데이터의 논리적 크기.storageSize: 컬렉션 데이터에 할당된 공간.indexSize: 인덱스가 사용하는 공간.
특정 컬렉션의 경우:
db.orders.stats({ scale: 1024 * 1024 })
size, storageSize, totalIndexSize를 확인하세요. storageSize가 size보다 훨씬 크면 컬렉션에 업데이트 및 삭제로 인한 재사용 가능한 내부 공간이 있을 수 있습니다. totalIndexSize가 크면 인덱스가 디스크 사용량을 줄이는 가장 빠른 방법일 수 있습니다.
MongoDB 디스크 증가의 일반적인 원인
높은 삭제 및 업데이트 변동은 WiredTiger 파일 내부에 내부 여유 공간을 남길 수 있습니다. MongoDB는 종종 향후 쓰기를 위해 해당 공간을 재사용하지만, 운영 체제는 여전히 파일이 크게 표시될 수 있습니다.
인덱스도 디스크의 많은 부분을 소비할 수 있습니다. 복합 인덱스, 텍스트 인덱스, 와일드카드 인덱스 및 중복 인덱스는 빠르게 누적됩니다.
보존 간격도 또 다른 일반적인 원인입니다. 로그, 세션, 이벤트 및 감사 컬렉션은 오래된 문서를 보관하거나 만료시키지 않으면 영원히 증가합니다.
향후 증가를 줄이는 안전한 방법
최상의 디스크 수정은 일반적으로 무제한 증가를 방지하는 것입니다.
시간 기반 데이터의 경우 TTL 인덱스를 생성하세요:
db.logEvents.createIndex(
{ createdAt: 1 },
{ expireAfterSeconds: 86400 }
)
TTL 삭제는 백그라운드 모니터에 의해 처리되며 초 단위로 즉시 이루어지지 않습니다. 정확한 삭제 타이밍이 중요하지 않은 로그, 세션 및 임시 이벤트에 여전히 적합합니다.
인덱스를 삭제하기 전에 검토하세요:
db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])
$indexStats는 프로세스가 시작된 이후 인덱스가 사용되었는지 여부를 보여줄 수 있습니다. 이를 증거가 아닌 단서로 취급하세요. 월간 보고서 인덱스는 조용한 주에 사용되지 않은 것처럼 보일 수 있습니다.
확인된 사용되지 않는 인덱스를 이름으로 삭제하세요:
db.orders.dropIndex('customerId_1_createdAt_-1')
기존 파일에서 공간 확보
문서를 삭제해도 일반적으로 디스크의 WiredTiger 파일이 축소되지는 않습니다. 파일 시스템에 공간을 반환하려면 재작성 또는 압축 전략이 필요합니다.
compact 신중하게 사용
compact는 컬렉션 및 인덱스 데이터를 재작성하여 디스크 사용량을 줄일 수 있습니다. 리소스 집약적이며 MongoDB 버전 및 배포에 따라 영향을 받는 컬렉션에서 작업을 차단할 수 있습니다.
db.runCommand({ compact: 'orders' })
유지 관리 창 동안 실행하고, 먼저 테스트하고, 정확한 MongoDB 버전에 대한 문서를 읽으세요. 복제 세트에서는 많은 팀이 한 번에 하나의 세컨더리를 압축하고, 따라잡도록 한 다음, 필요에 따라 멤버를 단계적으로 다운하거나 교체합니다.
심각한 조각화를 위한 덤프 및 복원
심하게 조각난 데이터의 경우 덤프 및 복원은 컬렉션 파일을 깔끔하게 재구축합니다. 제자리에서 수행하면 중단되므로 백업, 다운타임 또는 복제 기반 마이그레이션을 계획하세요.
mongodump --db myDatabase --collection orders --out /backup/mongo-dump
덤프를 확인하고 전환을 계획한 후 대상 환경으로 복원하세요:
mongorestore --db myDatabase --collection orders \
/backup/mongo-dump/myDatabase/orders.bson
확인된 백업과 롤백 계획이 없으면 프로덕션 데이터를 삭제하지 마세요.
하지 말아야 할 것
파일 시스템에서 WiredTiger, 저널 또는 컬렉션 파일을 수동으로 삭제하지 마세요. 데이터베이스가 손상될 수 있습니다.
du와 MongoDB 논리적 크기가 일치해야 한다고 가정하지 마세요. 압축, 인덱스, 내부 여유 공간 및 파일 시스템 동작이 모두 숫자에 영향을 미칩니다.
MMAPv1 스타일 사전 할당에 대한 오래된 조언에 주의하세요. 최신 MongoDB 배포는 일반적으로 WiredTiger를 사용하며, 스토리지 동작이 다릅니다.
실용적인 요점
MongoDB 디스크 사용량이 잘못 보일 때, 먼저 호스트를 측정한 다음 데이터베이스, 컬렉션 및 인덱스를 측정하세요. TTL 인덱스와 보관을 사용하여 증가를 늦추세요. 확인된 불필요한 인덱스만 삭제하세요. 실제 파일 시스템 공간 확보를 위해 삭제가 즉시 파일을 축소할 것으로 기대하지 말고 compact 또는 덤프 및 복원 워크플로를 계획하세요.