MongoDB 의 데이터 파일 구조를 살펴봅니다.
DB 라 하면 역시 “Disk I/O 를 어떻게 줄일 것인가?” 에 대한 고민을 하게 됩니다. 그런데 그 파일들에 대해 알아보려 해본적이 없다는게 생각이 나서 이번 기회에 알아보고 갑니다.
설정을 살펴보면 storage.dbPath 가 나타내는 곳이 데이터 파일이 저장된 path 입니다.
컴퓨터마다, 설정마다 다르기 때문에 직접 mongo conf 파일에서 확인하는게 좋겠습니다.
저는 대체적으로 default 를 사용하지만(로컬) 실제 서버에서는 회사 규칙에 맞게 설정이 되어 있을테고, 학습 목적으로 설정을 고치다 보니 제가 함부로 path 를 올리면 도움이 안될것 같습니다.
들어가서 보면 이렇게 파일들이 존재합니다.
sizeStorer.wt
•
collection 전체 document 건수와 각 컬렉션의 데이터 파일 크기를 저장
db.idolz.count()
SQL
복사
의 경우 실제 쿼리를 실행하는것이 아니라 sizeStorer.wt 파일에 저장된 정보를 반환 합니다.
이건 무조건 전체 document 의 갯수를 보여주니 정확한 정보를 원한다면 query 를 사용해 실행하는 편이 좋겠네요
cat sizeStorer.wt
SQL
복사
명령어로 어떤 데이터가 있는지 확인하면
이러한 데이터가 있습니다. 뭔 말인지 알아보기 어렵지만 눈에 힘을 주고 읽어보면 뭔가 보이는게 있네요
WiredTiger.lock
•
데이터 파일들에 대해서 다른 인스턴스가 동시에 사용하지 못하도록 잠금역할을 합니다.
•
wired tiger 엔진이 정상적으로 shutdown 되었는지 판단할 때 참조된다.
•
이 파일이 남아 있다면, 정상적으로 종료된 것이 아닙니다.
•
의외로 별거 없네
WiredTiger.turtle
•
storage engine 의 설정 내용을 담고 있습니다.
•
엔진의 옵션을 어떻게 설정했는지 확인이 가능합니다.
•
변경한 옵션이 제대로 반영되었는지 확인이 가능합니다.
•
중요한 파일중에 하나이니 백업 범위에 들어가야하고 변경이나 삭제가 되지 않도록 해야합니다.
•
db.serverStatus 로도 확인이 가능함.
mdbcatalog.wt
•
storage engine collection 과 index 목록
•
인덱스나 컬렉션이 사용하는 데이터 파일의 목록
•
위와 같은 meta data 를 관리한다.
WiredTigerLAS.wt
•
이게 제일 신기함.
•
engine 의 cache 에서 재활용 할 수 있는 공간이 부족하면 eviction 서버는 필요한 만큼의 여유공간을 만들어야 한다.
•
제거 범위에 들어온 캐시 데이터 페이지들이 dirty page 상태여서 disk 기록이 필요하다면 임시로 사용한다.
•
캐시 용도로 사용 되는 파일
•
LAS: Look Aside Table
◦
임시로 기록된 dirty page 는 나중에 원래 데이터 파일로 기록되거나 다시 캐시로 읽어야 한다.
◦
이런 특성 때문에 이름이 위와 같이 정해졌다.
아직 캐시를 넘어갈 상황을 경험해보지 못했지만(회사에서 운영할 땐 서버를 상당히 넉넉하게 주다보니..) 진짜 여기에 어떠한 정보가 캐싱되는지 확인해보고 싶긴 합니다.
캐시를 모두 사용해 어쩔 수 없는 상황에서만 사용되지 않을까 싶네
diagnostic.data (directory)
•
내부 정보를 1초에 한번씩 모아서 별도의 파일로 기록한다.
•
운영체제 상태정보
◦
/proc/stats, /proc/meminfo, /sys/block/*/stat
◦
server status
◦
replSetGetStatus
◦
local.oplog.rs.stats 컬렉션의 collStas
◦
buildinfo
◦
getCmdLineOpts
◦
hostinfo
•
진단 데이터는 초 단위로 상세히 수집된다.
•
•
FTDC 명령어로도 확인이 가능하다.
사실 이런게 있는줄도 몰랐다. 회사에서 TPS 테스트 할때 열어봐야겠다.
그냥 cat 명령어나 vim 으로는 확인할 수 없으니 FTDC 로 한번 깔끔하게 볼 필요는 있을것 같다.
MongoDB 가 시작할 때 option 을 줄 수도 있지만, 실행 중인 상태라도 옵션 설정이 가능하다.
db.runCommand({setParameter: 1, diagnosticDataCollectionEnabled: true})
db.runCommand({setParameter: 1, diagnosticDataCollectionDirectorySizeMB: 100})
db.runCommand({setParameter: 1, diagnosticDataCollectionFileSizeMB: 100})
db.runCommand({setParameter: 1, diagnosticDataCollectionPeriodMillis: 1000})
JSON
복사
내일 QA 서버에 적용해 봐야겠다.
그런데 github 들어가 보면
지금 2020년 6월 11일 인데 3, 4 years ago 라는건… 내가 사용하는 MongoDB 4.2.2 대응이 될까..?
