[컴] Grafana OSS 버전 사용

 

그라파나 / 모니터링

Grafana OSS 버전 사용

현재 최신버전은 grafana-8.5.0 이다.

1. download
   • Download Grafana | Grafana Labs
   • enterprise 와, open source 는 같은 기능을 갖고 있다. enterprise 에는 라이센스가 있으면 unlock 할 수 있는 기능들이 더 들어가 있다. (즉, 기능은 설치가 되지만, 라이센스가 없으면 사용을 할 수 없다)

config

• location: https://grafana.com/docs/grafana/v7.5/administration/configuration/#config-file-locations

windows 에서는 c:\Program Files\GrafanaLabs\grafana\conf 에 가면, 다음 2개의 ini 를 볼 수 있다. sample.ini 는 default.ini 에서 option 들이 전부 주석처리 되어 있다. 이 sample.ini 로 custom.ini 를 만들면 된다. defaults.ini 는 변경하지 말라고 한다.

• defaults.ini
• sample.ini

접속

• http://localhost:3000/ 로 가면 grafana 의 첫화면을 볼 수 있다.
• port 는 위에서 이야기한 custom.ini 에서 변경할 수 있다.

References

1. Install on Windows | Grafana documentation

[컴][db] mongodb 의 config.system.sessions

몽고db / system.sessions collection 에 무슨 정보가 있는가 ? / 왜 필요한가. / 세션 동기화 / 

mongodb 의 config.system.sessions

mongodb 3.6 버전부터, config db 는 다음을 지원하기 위해서 internal collection 들을 갖는다.

1. standalone, replica sets, sharded clusters 에서의 인과적인 일관적인 세션들(causally consistent sessions)
2. replica sets, sharded clusters 에서의 재시도가능한 write들과 transaction들

이중에서 1번째 “인과적인 일관적인 세션들(causally consistent sessions)” 을 위해서 config.system.sessions 가 필요하다.

다음처럼 $listSessions 명령어를 통해 확인할 수 있다.

당연한 이야기겠지만 system.sessions 를 함부로 조작하지 말라고 한다.(수정, 삭제등)

use config

db.system.sessions.aggregate( [ { 
  $listSessions: { 
    users: [ {user: "myAppReader", db: "test" } ] 
  } 
} ] )

system.sessions collection 은 session record들을 저장한다. 이 session record들은 배포된 모든 member들이 사용가능하다.(available)

user 가 session 을 mongod instance 에서 만들때, session 의 record 은 초기에 그 instance 의 in-memory 에만 존재한다. 주기적으로 그 instance 는 자신의 cached session 들을 system.sessions collection 에 sync 할 것이다. 그 때, 그 record 들은 배포된 모든 member 들에게 visible 하다.

$listSessions 명령어를 이용해서 이 record 들을 확인할 수 있다.

Reference

1. Config Database — MongoDB Manual
2. $listSessions — MongoDB Manual

[컴][db] mongodb replica set 의 Read Preference

replica set 설정 / 읽기 우선순위

ref. 1 에 대한 번역이다.

mongodb replica set 의 Read Preference

• 기본값은 read operation 들을 replica set 의 primary member 에게 보내는 것이다.(즉, read preference mode 가 primary)
• Read preference 는 다음 4가지로 구성된다.
  • read preference mode
  • optional: tag set
  • optional: maxStalenessSeconds
  • optional: headged read : non-primary read preference를 사용하는 read를 위한 MongoDB 4.4+ sharded cluster들에서 가능하다.

4.4 버전부터, non-primary read preference 모드들은 sharded cluster들에서 hedged read 를 지원한다.

Read Preference Mode

• primary : default 값이다. 모든 명령들은 현재 replica set 의 primary 에서 이뤄진다.
  

  read operation들을 가지고 있는 multi-document transactions 들은 primary read preference를 이용해야만 한다. 주어진 transaction에 있는 모든 operation들은 같은 member로 가야 한다.

• primaryPreferred: 대부분의 경우에, opration들은 primary 에서 읽어오지만, 만약 그것이 가능하지 않을때, operation들은 secondary member들에게서 읽어온다.

  4.4버전 부터, primaryPreferred는 shared cluster에서 hedged reads 를 지원한다.

• secondary : 모든 operation들은 replica set 의 secondary member들에게서 읽는다.

  4.4버전 부터, secondary는 shared cluster에서 hedged reads 를 지원한다.

• secondaryPreferred: 대부분의 경우에, operation들은 secondary member들에게서 읽어온다. 그러나 가능한 secondary member가 없거나, operation들이 sharded cluster의 primary 에서 읽어온다.

  4.4 버전부터, secondaryPreferred 는 shared cluster에서 hedged reads 를 지원한다.

• nearest : operation들(명령어들)은 member 가 primary 인지 secondary 인지 관계없이 정의된 latency threshold 에 기초해서 random eligible replica set member 에게서 읽어온다. operation 들은 latency 를 계산할 때 다음을 고려한다.

  • localThresholdMS connection string option
  • maxStalenessSeconds read preference option
  • 정의된 tag set들

  4.4 버전부터, nearest option 은 sharded cluster들에 hedged reads 를 지원한다. 그리고 기본적으로 hedged read option 을 enable 한다.

자세한 사항은 Read Preference Modes 를 참고하자.

• Read Preference Modes | Read Preference — MongoDB Manual

동작

• primary read preference 모드를 제외한 모든 read preference mode 들은 stale data (오래된 data) 를 반환할 수 있다. 왜냐하면 secondary는 비동기 처리로 operation들을 복제하기 때문이다.

  non-primary 모드를 사용하도록 선택한 경우 응용 프로그램에서 오래된 데이터(stale data)를 사용해도 문제가 없는지 확인해야 한다.

• read preference 는 데이터의 visibility에 영향을 주지 않는다. 즉, 클라이언트들은 write 결과를, 그 결과 들이 승인(acknowlegded)되기 전에, 또는 대부분의 replica set member들로 전파되기 전에 볼 수 있다. 자세한 내용은 Read Isolation, Consistency, and Recency 를 보자.

• read preference 은 인과적 일관성(casual consistency)에 영향을 주지 않다.

  ‘majority’ read concern read operation 들과 ‘majority’ write concern write operation 들을 위한 casual consistency guarantees 는 인과적으로 일관된 세션들에 의해 제공된다.

  이 인과적 일관성 보장들(casual consistency guarantees)은 MongoDB deployment의 모든 member들에 걸쳐 유지된다.

maxStalenessSeconds

• Read Preference maxStalenessSeconds — MongoDB Manual

maxStalenessSeconds read preference option 은 seondary들에서 읽기를 하면서, ’primary의 writes를 replicating하는 것에 아주많이 뒤떨어진 seondary들’로 부터 읽기를 하는 것을 피하고 싶어하는 application 들을 위한 것이다.

예를 들어 seondary들는 자신과 primary 간의 네트워크 중단으로 인해 복제가 중단될 수 있다. 이 경우 관리자가 운영 중단을 해결하고 seondary들이 따라잡기 전까지 클라이언트는 seondary들에서 읽기를 중지해야 한다.

이 옵션을 이용하기 위해서는 모든 node instance 의 mongod version 이 3.4이상이어야 한다. 하나라도 버전이 낮으면 driver가 error 를 발생시킨다.

이 옵션은 primary mode 에서는 호환되지 않고, 단지 secondary member 를 선택하는 때에만 사용된다.

maxStalenessSeconds 를 이용해서 read operation 을 위한 서버를 선택할 때,

• client들은 각각의 secondary 가 얼마나 오래됐는지를(how stale) 측정한다. 이 측정은 secondary 의 “primary 로의 마지막 write”을 비교하는 것을 통해서 하게 된다.
• 그리고나서, client 는 read operation 을 그것의 측정된 지연(estimated lag) 이 maxStalenessSeconds이하인 secondary 로 향하게 한다.
• primary 가 없으면 client 는 비교를 위한 write중 ’가장 최근 write’를 가진 secondary 를 이용한다.
• 기본적으로, staleness 에 max 값은 없다. 그리고 client 들은 read operation을 어디로 보내는지 선택할 때 secondary의 지연을 고려하지 않는다.
• maxStalenessSeconds 값은 90초 이상으로 지정해야 한다. 이보다 작은 maxStalenessSeconds 값을 지정하면 오류가 발생한다.
• maxStalenessSeconds 값을 90초 미만으로 적용할 수 없는 이유
  • client들은 각 replica set member의 최신 write 날짜를 주기적으로 확인하여 secondary들의 staleness 측정한다.
  • 이러한 검사는 자주안하기 때문에 staleness 추정치는 대략적입니다. 따라서 client들은 maxStalenessSeconds 값을 90초 미만으로 적용할 수 없다.

References

1. Read Preference — MongoDB Manual

[컴][db] MongoDB 의 Replica Set Data 동기화

몽고db 동기화 과정 / 데이터 동기화 / replica set 의 동기화 / 어떻게 동기화 / 싱크 / 데이터 싱크 /

ref.1 에 대한 번역의 일부이다.

MongoDB 의 Replica Set Data 동기화

• replica set 의 secondary member 들은 다른 멤버들로 부터 sync 또는 data 를 복제한다.
• mongodb 가 2가지 형태의 data sync 를 사용한다.
• initial sync 는 새로운 멤버들이 full data set 과 함께 시작할 수 있게 하기위해서이고,
• 복제(replication) 은 계속진행되는 변경을 모든 data set 에 적용하기 위해서 한다.

initial Sync

replica set 의 한 member 의 모든 data 를 다른 member 에게 copy 하는 것이다.

mongodb 4.4 부터 initialSyncSourceReadPreference parameter 를 이용해서 선호하는 iniitial sync source 를 지정할 수 있다.

과정

1. local database 를 제외한 모든 database 를 복제한다(clnoe). 복제하기 위해서 mongod 는 각 source database 에 있는 모든 collection 을 scan 하고, 모든 data 를 이 collection 들의 복사본에 넣는다.

   3.4 부터는 initial sync 는 document들이 각 collection 에 copy 될 때, collection 의 모든 index들을 만든다. 예전에는 _id index 들만 만들었다고 한다.

   3.4 부터는 data copy 를 하는 동안에 새롭게 추가된 oplog record 들을 pull 한다. target member 는 local database 안에 충분한 disk space 를 갖는 것을 보장해야 한다. 이 local database 에 data copy stage 동안에 pull 하는 oplog record들을 임시적으로 저장하기 때문이다.

2. 모든 변경들이 data set 에 적용된다. source에서 온 oplog 를 이용해서 mongod 는 replica set 의 current state 를 반영하기 위해 data set를 update 한다. initial sync 가 끝나면, member 는 STARTUP2 에서 SECONDARY 로 바뀐다.

Replication

initial sync 이후에 Secondary members 들은 data 를 계속해서 복사한다. secondary member들은 oplog 를 sysnc from source 로 부터 oplog 를 copy 하고, 이 작업들(operations)을 비동기 처리로 적용한다.

Secondary 들은 필요할 때 자동으로 그들의 sync from source 를 변경한다. 변경할 때는 다른 멤버들의 replication 의 상태와 ping time 의 변화에 근거해서 변경한다.

sync source 를 선택하는 법은 여기를 참고하자.

Streaming Replication

sync from source들은 그들의 “동기화하는 secondary 들”에게 연속적인 oplog 항목들의 stream 을 보낸다. streaming replication 은 높은 부하와 높은 대기시간(latency) 에 있는 네트워크에서 생기는 복제 지연(replication lag) 을 완화시킬 수 있다.

그것은 또한:

• secondary들로 부터의 읽기에 대한 staleness(만든지 오래된) 를 줄인다.
• w: 1 write operation들을 잃어버리는 위험을 줄인다.
• w: "majority" 와 w: >1 write operation 들의 latency 를 줄인다.(즉, replication 을 기다리는 모든 write concern )

v4.4 이전에서는 secondary 들은 sync from source 에 대한 request 를 발행하고 response 를 기다리는 방식으로 oplog entries 의 batch 들을 가져왔다.(fetch)

이를 위해 각 oplog entries 의 batch에 대한 네트워크 roundtrip이 필요했다. MongoDB 4.4는 스트리밍 복제를 비활성화하고 이전 복제 동작을 사용하기 위해 oplogFetcherUsesExhaust 라는 startup parameter를 추가한다.

sync from source에 리소스 제약 조건이 있거나 replication에 대한 MongoDB의 네트워크 대역폭 사용을 제한하려는 경우에만 oplogFetcherUsExhaust 를 false로 설정하자, 이 값이 false 이면, streaming replication 을 사용하지 않는다는 의미이다.

Multithreaded Replication

MongoDB는 동시성(concurrency)을 향상시키기 위해 여러 스레드를 사용하여 묶어서 한번에(in batches) write operations 를 한다. MongoDB는 document ID(WiredTiger)에 따라 batch를 그룹화하고 동시에, 다른 스레드를 사용하여 각 operation에 대한 group을 만든다. MongoDB는 항상 document에 대해서 그들의 원래 write order 로 write operation을 한다.

버전 4.0에서 변경

MongoDB 4.0부터는, 만약 read 가 이 replcation batch 들이 적용되어지는 secondary 에서 수행된다면, secondary들에서 수행하면서, read concern level 이 local 또는 majority 로 설정된 읽기 작업들(read operations)은 WiredTiger snapshot data로 부터 data 를 읽어오게 된다.

snapshot 에서 읽으면 데이터를 일관되게 볼 수 있으며, lock 없이 지속적인 복제(replication)와 동시에 읽기가 가능하다. 따라서 이런 read concern level 들을 필요로 하는 secondary read 들은 더이상 replication batch들이 적용되기를 기다릴 필요가 없으며, 수신되는대로 처리할 수 있다.

me: local, marjority 라는 read concern level 을 사용하면 snapshot 에서 data 를 읽어오게 되고, 그런 이유로 replication batch 로 인해 발생할 수 있는 대기시간을 없앨 수 있다.

Flow Control

MongoDB 4.2 부터, 관리자들은 primary 가 그것의 write 들이 “replica set 의 대다수의 member 들에게 oplog 가 write 되는 시간(majority comitted lag)” 을 유지하면서 write들을 수행하도록 비율(rate)을 제한할 수 있다.

이것은 flowControlTargetLagSeconds를 이용해서 할 수 있는데, 이 설정값에 ‘지연(lag)’ 의 최대치’를 설정할 수 있다.

기본적으로, flow control 은 enabled 되어 있다. enableFlowControl 로 설정할 수 있다.

see also:

• Flow Control | Troubleshoot Replica Sets — MongoDB Manual

replication sync source 선택

• 쿠…sal: [컴][db] 몽고db의 replication sync source 선택

MongoDB 4.4 부터, initial sync source 를 선택할때는 startup parameter initialSyncSourceReadPreference replica set 의 settings.chainingAllowed 세팅보다 우선순위를 갖는다.

replica set member 가 성공적으로 initial sync 를 수행한 후, replication sync source를 선택할때는 chainingAllowed 를 따르게 된다.

See Also

1. Initial Sync Source Selection | Replica Set Data Synchronization — MongoDB Manual

Reference

1. Replica Set Data Synchronization — MongoDB Manual

[컴][db] 몽고db의 replication sync source 선택

 

몽고db / mongodb replication set / replica set / how to sync / 동기화 방법 / 동기화 소스 선택 방법 / sync source selection

ref. 1 에 대한 번역이다.

몽고db의 replication sync source 선택

replica set 의 channing setting 에 달려있다. channing 의 기본값은 ‘enabled’ 이다.

• channing setting 이 enabled 이면, replica set member 중에서 sync source 를 선택하는데,
• channing 이 disabled 되어 있으면, primary 를 sync source 로 선택한다. 만약 primary 가 unavailable 또는 unreachable 하면, error 를 log 하고, 주기적으로 primary 가 가능한 상황인지를 체크한다.

다음 2개의 pass 를 거쳐서 sync source 를 선택한다. 만약 2가지 pass 후에도 sync source를 결정하지 못하면, error log 를 남기고, ‘1초’ 후에 selection process를 재시작 한다.

1번째 Pass

member 는 first pass 를 수행할 때, 각각의 replica set member 에게 다음 결정조건(criteria) 을 적용한다.

• sync source 는 replication state 가 PRIMARY 또는 SECONDARY 여야 한다.
• sync source 는 online 이면서 reachable 이어야 한다.
• sync source 는 new oplog entry들을 가지고 있어야 한다.(즉, sync source 가 ahead of the member 여야 한다.)
• sync source 는 visible 해야 한다.
• sync source 는 primary 의 가장 새로운 oplog entry 의 30초내에 있어야 한다.
• 만약 member 가 index들을 build 하면, sync source 는 index들을 build 해야만 한다.
• 만약 member 가 replica set 선거에 투표하면(vote), sync source도 vote 를 해야만 한다.
• 만약 member 가 delayed member 가 아니라면, sync source는 delayed 되지 않아야만 한다.
• 만약 member가 deplayed member라면, sync source는 ‘좀 더 짧은 설정된 delay’(shorter configured delay) 를 가지고 있어야만 한다.
• sync source는 현재 best synce source 보다 더 빨라야 한다.(더 낮은 latency 여야만 한다.)

2번째 Pass

member는 replication sync source를 정하기위한 2번째 pass를 할때, 다음 결정조건(criteria)를 각각의 replica set member 에게 적용한다.

• sync source 는 replication state 가 PRIMARY 또는 SECONDARY 여야 한다.
• sync source 는 online 이면서 reachable 이어야 한다.
• 만약 member 가 index들을 build 하면, sync source 는 index들을 build 해야만 한다.
• sync source는 현재 best synce source 보다 더 빨라야 한다.(더 낮은 latency 여야만 한다.)

maxNumSyncSourceChangesPerHour

• maxNumSyncSourceChangesPerHour | MongoDB Server Parameters — MongoDB Manual

이 값을 mongodb version 5.0 부터 사용가능. 기본값은 3이다.

동기화 소스들은(sync sources) sync source가 업데이트될 때마다 그리고 노드가 oplog entries의 batch를 fetch할때마다, 평가된다.(evaluated)

1시간동안의 source의 변경이 maxNumSyncSourceChangesPerHour 에 설정한 값보다 많은 경우, 노드가 해당 동기화 소스의 re-evaluating를 일시적으로 중지한다. 이 매개 변수를 높은 값으로 설정되면, 노드가 불필요한 소스 변경을 수행할 수 있다.

이 parameter는 노드에 sync source를 가지고 있지 않은 경우, 다른 노드를 이용해서 동기화를 시작하는 것을 막지는 않는다. 동기화 소스가 invalid 되면, 노드는 re-evaluate 한다. 비슷하게, primary 가 변경되고, chainning이 disabled 면, 노드는 new primary 로 부터 동기화하도록 update 된다.

References

1. Replication Sync Source Selection | Replica Set Data Synchronization — MongoDB Manual

[컴][db] mongodb 에서 ObjectId 의 created_at 를 이용하는 방법

 

mongodb _id / 쿼리 / query / 날짜 이용 query / _id 이용 / 사용법 / insert 시간 확인방법

mongodb 에서 ObjectId 의 created_at 를 이용하는 방법

var objIdMin = ObjectId(Math.floor((new Date('2022-12-01T01:00:00Z'))/1000).toString(16) + "000
0000000000000")
var objIdMax = ObjectId(Math.floor((new Date('2022-12-01T02:00:00Z'))/1000).toString(16) + "000
0000000000000")
db.myCollection.find({
  _id: {
    $gt: objIdMin, 
    $lt: objIdMax
  }
})

References

1. Mongodb: Perform a Date range query from the ObjectId in the mongo shell - Stack Overflow

[컴][db] mongodb 의 mongotop

 

몽고db / mongodb / mongo database / 통계 몽고 통계 /

mongodb 의 mongotop

기본적으로 개별 collection 에 대한 초(second) 당 read/write 값이다. mongotop 에 보이는 collection 이 지금 활동(activity) 가 있는 collection 이다. activity 가 없으면 보이지 않는다.

뒤에 sleeptime 을 줄 수 있다.

# 30초 마다 reporting
mongotop 30

json option 을 주면, polling interval 동안의 동작(operations) 수의 개수를 같이 준다.

--json

Returns output for mongotop in JSON format. In addition to timing data, the –json option also returns a count of the number of operations which took place during the polling interval.

Reference

1. mongotop — MongoDB Database Tools