All Articles

MongoDB 데이터 파일 구조 WiredTiger engine 이 만들어 내는 파일들

MongoDB 의 데이터 파일 구조를 살펴봅니다.

DB 라 하면 역시 “Disk I/O 를 어떻게 줄일 것인가?” 에 대한 고민을 하게 됩니다. 그런데 그 파일들에 대해 알아보려 해본적이 없다는게 생각이 나서 이번 기회에 알아보고 갑니다.

MongoDB configuration

설정을 살펴보면 storage.dbPath 가 나타내는 곳이 데이터 파일이 저장된 path 입니다.

컴퓨터마다, 설정마다 다르기 때문에 직접 mongo conf 파일에서 확인하는게 좋겠습니다.

저는 대체적으로 default 를 사용하지만(로컬) 실제 서버에서는 회사 규칙에 맞게 설정이 되어 있을테고, 학습 목적으로 설정을 고치다 보니 제가 함부로 path 를 올리면 도움이 안될것 같습니다.

mongodb data file structure

들어가서 보면 이렇게 파일들이 존재합니다.

sizeStorer.wt

  • collection 전체 document 건수와 각 컬렉션의 데이터 파일 크기를 저장
db.idolz.count()

의 경우 실제 쿼리를 실행하는것이 아니라 sizeStorer.wt 파일에 저장된 정보를 반환 합니다.

이건 무조건 전체 document 의 갯수를 보여주니 정확한 정보를 원한다면 query 를 사용해 실행하는 편이 좋겠네요

cat sizeStorer.wt

명령어로 어떤 데이터가 있는지 확인하면

size storer wt

이러한 데이터가 있습니다. 뭔 말인지 알아보기 어렵지만 눈에 힘을 주고 읽어보면 뭔가 보이는게 있네요

WiredTiger.lock

  • 데이터 파일들에 대해서 다른 인스턴스가 동시에 사용하지 못하도록 잠금역할을 합니다.
  • wired tiger 엔진이 정상적으로 shutdown 되었는지 판단할 때 참조된다.
  • 이 파일이 남아 있다면, 정상적으로 종료된 것이 아닙니다.

    wired tiger lock file

  • 의외로 별거 없네

WiredTiger.turtle

wired tiger 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 https://github.com/10gen/ftdc-utils 로 확인이 가능하다
  • 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})

내일 QA 서버에 적용해 봐야겠다.

그런데 github 들어가 보면

ftdc util github diagnostic

지금 2020년 6월 11일 인데 3, 4 years ago 라는건… 내가 사용하는 MongoDB 4.2.2 대응이 될까..?

ftdc util github diagnostic installation

설치 되면 한번 돌리기라도 해보고 싶은데 한참동안 반응이 없다. ㅠㅠ

새벽 2시니까 얼른 자야겠다.