'mongoDB'에 해당되는 글 7건

How to reference

https://docs.mongodb.com/manual/reference/command/convertToCapped/

But,
1. This command makes db global lock while end this command. It takes several minutes or more according to how many data is stored.
2. This command will remove all indexes of target collection

1. find all disk attached to this machine
    sudo fdisk -l
    Disk /dev/xvda: 8589 MB, 8589934592 bytes, 16777216 sectors
    ..
    Disk /dev/nvme0n1: 950.0 GB, 950000000000 bytes, 1855468750 sectors
    ..

2. select target to make as a /data folder
    "/dev/nvme0n1"

3. format disk to xfs filesystem
    sudo mkfs -t xfs /dev/nvme0n1

4. mount disk to /data folder
    sudo mkdir -p /data
    sudo mount /dev/nvme0n1 /data
    check mounted disk list: df -TH

5. give permission to mongod user
    sudo chown mongod:mongod /data

http://docs.mongodb.org/manual/administration/monitoring/

프로파일링 하고자하는 DB를 선택해서

db.setProfilingLevel(1)

셋팅을 해주고

db.system.profile.find( { millis : { $gt : 100 } } )

이런식으로 찾으라고 되어있다.

하지만 millis는 그냥 자신의 쿼리가 얼마나 오래 걸린지만 나타낼뿐, 자신이 기다린 db read/write lock time이 얼마나 되며 자신이 수행되는동안 db read/write lock time을 얼마나 잡았는지는 포함되지 않는다.

profile doc 내부에 보면 아래와 같은 lock에 대한 정보가 추가로 있는데

system.profile.lockStats.timeLockedMicros

system.profile.lockStats.timeAcquiringMicros

timeLockedMicros는 자신이 lock을 얼마나 잡았는지, timeAcquiringMicros는 자신이 lock을 잡기위해 기다린 시간을 뜻한다.

따라서 client측에서의 총 기다린 시간은 millis + 자기가 기다린 lock시간이 되겠다. 그리고 자기가 잡은 lock은 그다음 쿼리에 영향을 미칠거고..

만약 자기가 lock을 잡기위해 기다린 시간이 엄청 길다면 앞에 있는 쿼리가 lock을 걸고 기다렸거나 아니면 다른 리소스에서 디스크자원을 써서 기다리는 시간이 길어졌다고 볼수 있다.

보통은 millis로만 검색해서 실제로 lock이 얼마나 있었는지 못보고 지나갈 수도 있는데 이 lock타임으로 검색하거나, 특정 시간때에 몽고디비가 이상 현상이 있었다면 그시간때 ts로 profile doc을 검색해보는 것이 좋을 듯하다.

* 참고로 아마존을 사용할때 EBS Volumes에 Read/Write Bandwidth 그래프를 보고 언제 갑자기 read/write량이 몰렸었는가를 볼 수 있으니 위 내용과 관련해서 같이 보면 좋다. 이런걸 보고 몇 IOPS가 필요한지 판단할 수 있을 듯하고, 그리고 가끔 보면 튀는게 있는데 아마도 클라우드 서비스라 그런지 다른 곳과 총 bandwidth를 나눠쓸거 같다는 생각이 들고 그러다보면 순간적으로 우리쪽에 Disk I/O 기다림이 생길수 있어서 이때 쌓였던 I/O들이 한번에 몰리면서 튀는현상을 만들어 내지 않았나 가정을 해본다.

env:200KDAU500GB1500IOPS

MongoDB Management Service)

* 이점

- Serviced by MongoDB Guys

- Super easy setup and Fancy features (Monitoring + Backup)

- Clear and Clean Dashboard

- Group Alerts (Pager, Email, Hipchat..)

- API Supported

일단, Backup을 셋팅하기 위해서는 Backup을 저장할 instance가 하나 필요하고 이곳에는 mongod가 실행되어있어야 한다. type은 sharded 또는 replica-set으로 되어있어야 하며 standalone으로 되어있으면 mms에서 Backup용으로 감지가 안된다. 또한 MMS에서 Backup용으로 감지되기위해서는 monitoring agent와 backup agent가 설치되어있어야 한다.

정리하자면 Backup용 instance에 아래 1,2,3번이 설치되어있고 4번이 설정되어있으면됨.

1. mongod

2. monitoring agent

3. backup agent

4. db sharding or replica set 설정

(sharded 된 벡업 db를 쓴다면 각 디비 instance에 2,3번을 설치할 필요는 없고 config서버에만 설치하면된다. sharding이 안되어있고, replica set하나인 경우는 primary에만 설치되면 된다)

요 설정이 끝나면, MMS에서 Backup 탭을 눌렀을때 자동으로 감지가 된다. 이후 부터는 설정된 주기에 따라 자동으로 Backup된다.

1. Download the 32-bit or 64-bit deb package.

$ curl -OL https://mms.mongodb.com/download/agent/monitoring/mongodb-mms-monitoring-agent_2.1.0.35-1_amd64.deb

2. Install the package
$ sudo dpkg -i mongodb-mms-monitoring-agent_2.1.0.35-1_amd64.deb

3. Edit /etc/mongodb-mms/monitoring-agent.config and enter your API key, as shown below
$ mmsApiKey=6d2f19515939c45d6905ef9f0d584e1c

4. Start the agent
$ sudo start mongodb-mms-monitoring-agent

5. Continue to setup @ mms console

* 호스트 추가시 팁

에이전트는 기본적으로 모든 정보를 알아서 MMS에 전송하는데(Outbound only) MMS 콘솔에서 호스트에 대한 자세한 정보를 맵핑시켜놓기 위해 호스트를 추가하는 메뉴가 있다. 그런데 이때 묻는 정보들에 당황하지 않고, 다음의 팁들을 염두하고 입력하면 수월할지어다.

- 호스트 타입은 Standalone / Shard Cluster / Replica Set / Master Slave 가 있다.

- Standalone 은 Config 서버 입력할때 쓰면 좋다.

- Shard Cluster 는 Mongos 서버 입력할떄 쓰면 좋다. (보통 이거 하면 알아서 Replica Set 다 찾아줌)

- Replica Set / Master Slave 로 구성했다면 요걸로 고르면 됨.

- 그리고 호스트네임은 수집된 정보에서 호스트 식별해내기 위한 것으로 Public IP / Private IP 구분 없다. (울 서버에 Inbound 요청하려고 하는것이 아님)

The Backup Agent requires network access. To avoid contention for network and CPU resources, we recommend running the Backup Agent on a separate host from your mongod instances. Performance impact on the cluster is similar to adding an additional secondary node. The Backup agent has the same performance profile impact as a secondary. For the initial backup, the load scales with the size of your data set. Once an initial backup exists, the load scales with oplog gigabytes used per hour. Within the US, MMS Backup sends snapshots at 50-100Mbps. Assuming a compression factor of 4x and transmission speeds of 50Mbps, a 250 GB snapshot will take 2.5 hours.  

1. Download the 32-bit or 64-bit deb package.

$ curl -OL https://mms.mongodb.com/download/agent/backup/mongodb-mms-backup-agent_1.4.6.43-1_amd64.deb

2. Install the package

$ sudo dpkg -i mongodb-mms-backup-agent_1.4.6.43-1_amd64.deb

3. Edit /etc/mongodb-mms/backup-agent.config and enter your API key, as shown below

apiKey=6d2f19515939c45d6905ef9f0d584e1c

4. Start the agent 

$ sudo start mongodb-mms-backup-agent

* References

https://jira.mongodb.org/secure/attachment/34148/backup-manual.txt 

mongoDB에서 샤딩을 해주기 위해서는 shard key를 정해주어야 한다.

샤딩을 하는 이유는 읽기와 쓰기를 분산시켜 디비의 부하를 줄이기 위함인 것처럼

이 목적을 가장 잘 달성할  수 있는 컬럼을 shard key로 잡아야 한다.

거의 대부분은 _id를 샤드키로 잡고 쓴다고 하고, mongodb도 기본적으로 _id에 맞추어 샤드를 테스트하고 최적화 했을 것이다.

샤딩 key로 데이터쓰기를 할때 range 방법과 hash방법이 있는데, range는 데이터가 얼마나 들어올지 fix된 상황에 적합할 것이고, 대부분의 경우는 hash방법이 좋지 않을까 생각한다.

그리고 샤드는 컬렉션 단위로 이루어지는데, 디비에 저장된 전체 데이터를 읽어서 처리해야 하는 데이터같은 경우는 샤드에 포함시키지 않아야 한다. 샤드된다면 각 샤드를 모두 뒤져서 가져와햐 하기 때문이다. 이때 샤드에 포함되지 않은 컬렉션은 따로 디비를 만들어 사용할 수도 있지만 그렇지 않은경우는 샤드들중 primary shard에 저장된다. 따라서 request에 따라서 primary shard에 부하가 집중될 수도 있으니 디자인을 잘 설계해야 할 것이다.

그리고 샤드들중 db하나가 lock이 걸리면 다른 샤드들은 정상동작하고 하나의 샤드만 lock이 걸린다. (collection이 1,2,3,4로 나눠졌을때 3번샤드의 collection때문에 락이 걸리면 그 collection이 속한 db가 락이 걸릴텐데 이때 3번샤드의 db만 락이 걸린다는 소리)