source

MongoDB 데이터베이스 파일 크기 축소

factcode 2023. 2. 13. 20:49
반응형

MongoDB 데이터베이스 파일 크기 축소

한때는 3GB를 넘는 대용량 MongoDB 데이터베이스를 보유하고 있습니다.그 후 문서가 삭제되었고 그에 따라 데이터베이스 파일의 크기가 줄어들 것으로 예상했습니다.

그러나 MongoDB는 할당된 공간을 유지하므로 파일은 여전히 큽니다.

admin 명령어는 다음과 같습니다.mongod --repair사용되지 않는 공간을 확보하기 위해 사용되지만 디스크 공간이 부족하여 이 명령을 실행할 수 없습니다.

사용하지 않는 공간을 비울 수 있는 방법을 아세요?

업데이트:compact커맨드 및 WiredTiger는 여분의 디스크 공간이 실제로 OS로 해방될 것으로 보입니다.


업데이트: v1.9+ 이후 명령어가 있습니다.

이 명령은 "인라인" 압축을 수행합니다.아직 공간이 좀 더 필요하겠지만, 그렇게 많지는 않을 거예요.


MongoDB는 다음 방법으로 파일을 압축합니다.

  • 새 위치에 파일 복사
  • 문서를 반복하여 재검증/재해결
  • 원본 파일을 새 파일로 바꾸기

은 '압축'을 할 수 .mongod --repair하여 '실행'을 실행함으로써db.repairDatabase().

어느 경우든 파일을 복사할 공간이 필요합니다.압축할 공간이 부족한 이유는 알 수 없지만 공간이 더 많은 다른 컴퓨터가 있는 경우에는 몇 가지 옵션이 있습니다.

  1. 다른 로 내보냅니다(Mongo를 사용).mongoexport 다음 수 (「 Import」(「 Import 。mongoimport이렇게 하면 새로운 데이터베이스가 더 압축됩니다. 원래 하던 수 .mongod새 데이터베이스 파일로 교체하면 바로 사용할 수 있습니다.
  2. 현재 mongod를 중지하고 데이터베이스 파일을 더 큰 컴퓨터에 복사한 후 해당 컴퓨터에서 복구를 실행합니다.그런 다음 새 데이터베이스 파일을 원래 시스템으로 다시 이동할 수 있습니다.

현재 Mongo를 사용하여 "압축"할 수 있는 좋은 방법은 없습니다.그리고 몽고는 확실히 많은 공간을 흡수할 수 있다.

현재 가장 좋은 압축 전략은 마스터-슬레이브 설정을 실행하는 것입니다.그런 다음 슬레이브를 압축하여 따라잡고 전환할 수 있습니다.아직 털북숭이인건 알아Mongo 팀이 더 좋은 컴포넌트를 내놓을지도 모르지만, 그들의 리스트에는 그다지 없다고 생각합니다.드라이브 공간은 현재 저렴한 것으로 가정됩니다(일반적으로 그렇습니다).

Mongo v1.9+는 컴팩트 대응이 되어 있는 것 같습니다.

> db.runCommand( { compact : 'mycollectionname' } )

다음 문서를 참조하십시오.http://docs.mongodb.org/manual/reference/command/compact/

"repair Database와 달리 콤팩트 명령어는 작업을 수행하기 위해 이중 디스크 공간이 필요하지 않습니다.작업 중에는 약간의 추가 공간이 필요합니다.게다가 컴팩트한 것이 고속입니다.

저도 같은 문제가 있었습니다.커맨드 라인에서 간단하게 다음과 같이 해결했습니다.

mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename

현재 데이터베이스의 모든 컬렉션 압축

db.getCollectionNames().forEach(function (collectionName) {
    print('Compacting: ' + collectionName);
    db.runCommand({ compact: collectionName });
});

는, 「」를 사용해 .repairpath가능한 공간이 더 .사용 가능한 공간이 더 많은 디스크를 가리킵니다.

예를 들어 Mac에서 사용한 것은 다음과 같습니다.

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair

업데이트: MongoDB 코어 서버 티켓 4266마다 추가가 필요할 수 있습니다.--nojournal러를회 회피: :

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal

Mongo 2.8 버전부터는 압축을 사용할 수 있습니다.WiredTiger 엔진 mmap에서는 다음 3가지 수준의 압축이 제공됩니다(2.6에서는 기본값이 압축되지 않습니다).

다음은 16GB의 데이터를 저장할 수 있는 공간의 예를 제시하겠습니다.

여기에 이미지 설명 입력

데이터는 이 문서에서 가져온 것입니다.

Storage Engine을 기반으로 두 가지 방법을 해결해야 합니다.

1. MMAP() 엔진:

명령어: db.repair Database()

메모: 복구 데이터베이스에는 현재 데이터 세트의 크기와 동일한 빈 디스크 용량과 2기가바이트가 필요합니다.dbpath를 보유한 볼륨에 충분한 공간이 없는 경우 별도의 볼륨을 마운트하여 복구에 사용할 수 있습니다.복구를 위해 별도의 볼륨을 마운트할 경우 명령줄에서 repairDatabase를 실행하고 --repairpath 스위치를 사용하여 임시 복구 파일을 저장할 폴더를 지정해야 합니다.예: DB 크기가 120GB라고 가정하면 (120*2)+2 = 242GB의 하드 디스크 공간이 필요합니다.

수집을 적절하게 수행하는 다른 방법: db.runCommand({compact: 'collectionName'))

2. WiredTiger:그것은 자동적으로 해결되었다

MongoDB의 공간 재확보에 대해 상당한 혼란이 있었습니다.또, 일부의 권장되는 프랙티스는, 특정의 전개 타입에서는 매우 위험합니다.상세한 것에 대하여는, 이하를 참조해 주세요.

TL;DR repairDatabase디스크 파손으로부터 복구하려고 하는 스탠드아론 MongoDB 전개로부터 데이터를 복구하려고 합니다.공간을 회복하면 순전히 부작용이다.공간 회복이 실행의 주요 고려사항이 되어서는 안 됩니다.repairDatabase.

독립 실행형 노드의 공간 복구

WiredTiger: WiredTiger를 사용한 스탠드아론 노드, 실행 중compact는 OS에단 하나의는 OS입니다.compactMongoDB 3.0.x 위의 WiredTiger 명령어는 이 오류의 영향을 받았습니다.SERVER-21833은 MongoDB 3.2.3에서 수정되었습니다.이 버전 이전에는compactWiredTiger wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired wired.

MMAPv1: MMAPv1의 동작 방식 때문에 MMAPv1 스토리지 엔진을 사용하여 공간을 복구할 수 있는 안전하고 지원되는 방법은 없습니다. compactMMAPv1의 경우 데이터 파일을 조각 모음하여 새 문서에 사용할 수 있는 공간을 확보할 수 있지만 OS에 공간을 다시 확보하지는 않습니다.

당신은 달릴 수 있을지도 모릅니다.repairDatabase잠재적으로 위험한 명령어의 결과를 충분히 이해하고 있는 경우(아래 참조),repairDatabase기본적으로 손상된 문서를 삭제하여 전체 데이터베이스를 다시 작성합니다.이로 인해 단편화 없이 새로운 MMAPv1 데이터 파일이 생성되고 공간이 OS로 다시 해방됩니다.

모험적인으로는 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★mongodump ★★★★★★★★★★★★★★★★★」mongorestore는 배치 규모에 따라 MMAPv1 배치에서도 사용할 수 있습니다.

복제본 집합의 공간 복구

복제 세트 구성의 경우 공간을 복구하는 가장 안전하고 최선의 방법은 WiredTiger와 MMAPv1 모두에 대해 초기 동기화를 수행하는 것입니다.

세트의 모든 노드에서 공간을 복구해야 하는 경우 롤링 초기 동기화를 수행할 수 있습니다.즉, 각 세컨더리 상에서 초기 동기화를 수행한 후 최종적으로 프라이머리를 종료하고 초기 동기화를 수행합니다.초기 동기 방식은 복제 세트 유지보수를 수행하는 가장 안전한 방법이며, 다운타임이 발생하지 않습니다.

롤링 초기 동기화 실행 가능성은 배포 규모에 따라 달라집니다.대규모 전개에서는 초기 동기화가 불가능할 수 있기 때문에 옵션이 다소 제한됩니다.WiredTiger를 사용하는 경우 세컨더리 하나를 세트에서 분리하여 스탠드아론으로 시작하여 실행할 수 있습니다.compact그 위에 올려놓고 다시 세트로 들어가세요.

★★★에 repairDatabase

복제 세트 노드에서 실행하지 마십시오.이는 repairDatabase 페이지에서 설명한 바와 같이 매우 위험한 작업입니다.

repairDatabase명령어는 아무것도 복구하지 않기 때문에 약간 오해의 소지가 있습니다.이 명령어는 독립 실행형 노드에서 디스크가 손상되어 문서가 손상될 수 있는 경우에 사용하기 위한 것입니다.

repairDatabase을 사용하다 수 를 다시 .

MMAPv1 배치에서는 이 데이터베이스 파일 재구축에 의해 OS에 대한 공간이 해방됩니다.OS에 공간을 개방하는 것은 결코 목적이 아닙니다.

의과의 repairDatabase

복제 세트에서 MongoDB는 집합의 모든 노드가 동일한 데이터를 포함할 것으로 예상합니다.<고객명>을repairDatabase에서는 노드에 되지 않은 파손이 되어 있을 또, 「」는 검출되지 않은 파손입니다.repairDatabase해 드립니다.

예상대로 이 노드에 포함된 데이터 집합의 나머지 데이터 집합과는 다른 데이터 집합이 있습니다.업데이트가 해당 단일 문서에 도달하면 전체 세트가 충돌할 수 있습니다.

설상가상으로, 이 상황이 오랫동안 잠복해 있다가 뚜렷한 이유 없이 갑자기 타격을 받을 수도 있다.

컬렉션에서 큰 데이터 청크가 삭제되고 컬렉션에서 삭제된 공간을 새 문서에 사용하지 않는 경우, 다른 데이터베이스 또는 컬렉션에서 사용할 수 있도록 이 공간을 운영 체제로 반환해야 합니다.디스크 공간을 조각 모음하고 사용 가능한 빈 공간을 다시 확보하려면 압축 또는 복구 작업을 수행해야 합니다.

압축 프로세스의 동작은 다음과 같이 MongoDB 엔진에 따라 달라집니다.

db.runCommand({compact: collection-name })

MMAPv1

압축 조작은 데이터 파일 및 인덱스를 조각 모음합니다.그러나 운영체제에 공간을 개방하지는 않습니다.이 작업은 MongoDB에서 재사용할 수 있도록 조각 모음을 수행하고 더 많은 연속된 공간을 만드는 데 유용합니다.그러나 사용 가능한 디스크 공간이 매우 적으면 아무 소용이 없습니다.

압축 작업 중에는 최대 2GB의 추가 디스크 공간이 필요합니다.

압축 작업 중에 데이터베이스 레벨 잠금이 유지됩니다.

와이어드 타이거

WiredTiger 엔진은 기본적으로 MMAPv1보다 적은 디스크 공간을 사용하는 압축을 제공합니다.

컴팩트한 프로세스에서는 빈 공간이 운영체제로 해방됩니다.압축 작업을 실행하는 데 필요한 최소한의 디스크 공간만 있으면 됩니다.또한 WiredTiger는 데이터베이스 레벨 잠금이 필요하기 때문에 데이터베이스의 모든 작업을 차단합니다.

MMAPv1 엔진의 경우 컴팩트한 Doest를 실행해도 운영체제로 공간이 반환되지 않습니다.사용되지 않은 공간을 해제하려면 복구 작업을 실행해야 합니다.

db.runCommand({repairDatabase: 1})

Mongodb 3.0 이상은 새로운 스토리지 엔진인 WiredTiger를 탑재했다.제 경우 스위칭 엔진은 디스크 사용량을 100Gb에서 25Gb로 줄였습니다.

데이터베이스 파일의 크기를 줄일 수 없습니다.데이터베이스를 "복구"하는 동안 mongo 서버에서 일부 파일만 삭제할 수 있습니다.대량의 데이터가 삭제된 경우 mongo 서버는 복구 중에 기존 파일 중 일부를 "해제"(삭제)합니다.

일반적으로 repairDatabase보다는 compact가 선호됩니다.그러나 콤팩트보다 복구가 더 좋은 점 중 하나는 전체 클러스터에 대해 복구를 수행할 수 있다는 것입니다.각 샤드에 로그인해야 하는 컴팩트한 작업입니다. 좀 짜증나죠.

같은 문제가 발생했을 때 mongo 서버를 정지하고 명령어를 사용하여 다시 시작하였습니다.

mongod --repair

복구 작업을 실행하기 전에 HDD에 사용 가능한 공간이 충분한지 확인해야 합니다(최소 용량은 데이터베이스 크기입니다).

스탠드아론 모드의 경우 컴팩트 또는 리페어를 사용할 수 있습니다.

지금까지의 경험에 의하면, 샤드 클러스터 또는 레플리카 세트의 경우, 프라이머리에서 콤팩트 실행 후, 세컨더리 데이터베이스의 사이즈는 작아졌지만 세컨더리 데이터베이스의 사이즈는 작아지지 않았습니다.멤버 재동기화를 실행하여 세컨더리 데이터베이스의 크기를 줄일 수 있습니다.이렇게 하면 secondary 데이터베이스의 크기가 primary 데이터베이스보다 더 작아질 수 있습니다.compact 명령어는 컬렉션을 압축하지 않습니다.그래서 레플리카 세트의 프라이머리와 세컨더리를 바꿔 멤버 재동기화를 다시 하게 되었습니다.

결론적으로 샤드 세트 또는 샤드 세트의 크기를 줄이는 가장 좋은 방법은 멤버 재동기, 프라이머리 세컨더리 스위치, 재동기입니다.

mongoDB - 클러스터가 샤드된 경우에는 복구가 권장되지 않습니다.

복제본 집합 샤드 클러스터를 사용하는 경우, compact 명령을 사용합니다. 그러면 모든 컬렉션의 모든 데이터 및 인덱스 파일이 다시 작성 및 조각 모음됩니다.구문:

db.runCommand( { compact : "collection_name" } )

force:true와 함께 사용하면 복제 세트의 기본에서 압축 실행이 수행됩니다. db.runCommand ( { command : "collection_name", force : true } )

기타 고려해야 할 사항: - 작업을 차단하므로 유지 보수 윈도우에서 실행하는 것이 좋습니다. - 복제 세트가 서로 다른 서버에서 실행되는 경우 각 멤버에서 개별적으로 실행해야 합니다. - 샤드 클러스터인 경우 압축은 각 샤드 멤버에서 개별적으로 실행해야 합니다.mongos 인스턴스에 대해 실행할 수 없습니다.

내가 할 수 있었던 방법 중 하나야기존 데이터의 안전성에 대한 보장은 없습니다.위험을 감수하고 해 보세요.

데이터 파일을 직접 삭제하고 mongod를 재시작합니다.

예를 들어 ubuntu(데이터의 기본 경로: /var/lib/mongodb)를 사용하면 collection.#과 같은 이름의 파일이 두 개 있었습니다.collection.0은 보관하고 나머지는 모두 삭제했습니다.

데이터베이스에 심각한 데이터가 없다면 더 쉬운 방법인 것 같습니다.

언급URL : https://stackoverflow.com/questions/2966687/reducing-mongodb-database-file-size

반응형