반응형

MongoDB 를 Sharded cluster 로 구축 후 운영하면서 수정했던 파라메터 중 하나를 공유합니다.

TaskExecutorPool은 mongos 에서 설정하는 파라메터 값 중 하나입니다.
(해당 문서는 4.4 위주로 작성 되었습니다.)

 

TaskExecutorPool?

  • Real MongoDB(235page)
  • MongoDB 라우터(mongos)는 MongoDB 클라이언트로부터 요청되는 쿼리들을 처리하기 위해서 내부적으로 서버의 CPU 코어 개수만큼 TaskExecutorPool 를 준비
  • Thread Pool 과 동일한 개념으로 생각하면 이해가 쉬움
  • MongoDB Shard 노드(Member)와의 연결 정보를 가지는 connection pool를 하나씩 가지며, Connection pool은 내부적으로 sub-connectionpool를 보유
  • 샤드 서버당 하나씩 생성
  • 만약 2개의 샤드(노드)가 존재한다면, 하나의 샤드당 connnection pool은 2개씩의 sub-connectionpool를 보유 (소스 상 specific-pool 이라고 명칭)
  • taskExecutorPoolSize 조정의 예시
    • app과 같은 서버에서 mongos가 실행된다면, app에서 많은 연결 및 작업을 한다면 TaskExecutorPool의 개수를 수동으로 증가 시키는 것도 가능
    • CPU 코어가 많은 서버라면, connection 이 너무 과도하게 생성되어 오히려 mongo shard(node)에 부하가 발생한다고 판단되면, TaskExecutorPool 개수를 제한도 가능
  • 모니터링 시 해당 수치가 높게 나오면 Sharded Clsuter 에 문제가 있기 때문에 반드시 체크가 필요 합니다.

 

taskExecutorPoolSize
  • 주어진 mongos에 사용할 Task Executor Connection Pool 의 수
  • 사용 가능한 코어 수로 default 설정 (최소 4, 최대 64)
    • 4.2 에서는 Default 가 1이며, cpu core 수에서 해당 값 만큼 설정
    • 0 으로 설정 시 자동으로 설정
    • 4.0 이전에는 core 수가 4 이하면 4, core 수가 64 이상일 경우 64로 설정
  • open connection 수를 줄이려면 낮은 값으로 설정
    • 부하 발생 시 적절하게 대처하기 힘들 수 있음.
  • default 값이 적절하며, 코어 수가 많은 서버에서는 해당 옵션을 16 이하로 설정하는 것이 좋음
  • mongos는 multiple thread pool을 유지 가능
  • 코어 수당 최대 connection 는 ShardingTaskExecutorPoolMaxSize 만큼 설정 가능
    • ex > ShardingTaskExecutorPoolMaxSize : 100 으로 설정 하고, taskExecutorPoolSize 를 4로 설정 시 최대 400개의 connection 을 생성 및 연결

Task Executor Pool

sub-ConnectionPool (SpecificPool)
  • connection pool의 connection을 얼마나 보유할지 결정
  • ShardingTaskExecutorPool로 시작
  • value 값들은 모두 3.2.11 이후부터 설정가능

 

ShardingTaskExecutorPoolHostTimeoutMS

  • mongos 가 host 와 통신하지 않아 끊는 시간(Timeout)
  • Default 300000 (5 분)
  • 시간이 길수록 피크 발생 시 유연하게 대처가 가능.
  • 일반적으로 피크 기간?의 3~4배 시간으로 설정하는 것이 tip (피크-spike 치는 시간이 가령 5분동안 지속된다면, 해당 ShardingTaskExecutorPoolHostTimeoutMS을 15~20분 으로 설정하는 것을 추천)
    • Real MongoDB에서는 30분에서 1시간 정도를 추천

 

ShardingTaskExecutorPoolMaxSize

  • taskExecutor connection pool 이 mongod(sharded) 에 대해 connection 할 수 있는 최대 개수 ( 하나의 coonection pool 이 접속할 수 있는 최대 connection 수)
  • default 값이 무제한
  • 최대 connection 수는 ShardingTaskExecutorPoolMaxSize * taskExecutorPoolSize 로 계산
  • connection floods 가 발생하면 해당 값을 제한하여 설정하는 것이 유용
    • connection floods : TCP connection floods라고 하며, 공격자가 서버에 사용 가능한 TCP connection slot 을 고갈시키는 행위 (여기서는 사용 가능한 connection 이 없을 경우를 의미)


ShardingTaskExecutorPoolMinSize

  • 각 TaskExecutor connection pool 이 sharded node에 connection 할 수 있는 최소 수
  • default 1
  • cold start 시 대기 시간 문제가 있는 경우 해당 값 증가가 도움
  • 해당 값을 증가시키면, mongos 프로세스가 ShardingTaskExecutorPoolHostTimeoutMS 가 만료될때까지 open 된 상태 유지 (TaskExecutorPoolSize * PoolMinSize * mongos 개수 per shard)
    • Real MongoDB에서는 10개 정도의 값도 충분

 

ShardingTaskExecutorPoolRefreshRequirementMS

  • connection pool 안에서 connection heartbeat로 시도할 때 wait 최대 시간
  • Default 60000 (1 분)
  • default 값을 추천
  • 해당 값을 높이면 heartbeat 트래픽이 증가하여 idle load 가 증가
  • 해당 값을 낮추면 일시적인 네트워크 오류 수를 줄일 수 있음(connection timeout 으로 인한 오류 내역을 줄일 수 있음)

 

ShardingTaskExecutorPoolRefreshTimeoutMS

  • mongos가 heartbeat timeout 을 기다리는 최대 시간
  • Default 20000 (20 초)
  • 해당 값이 낮으면 mongos가 pool 안의 connection을 유지할 수 없음
  • 네트워크 대기 시간이 긴 경우 해당 값을 늘려 네트워크 연결 유지를 향상 가능
# 설정 방법 1 (mongos config 로 등록)
sharding:
  #configDB: config_replSet/10.28.195.139:27017,10.28.195.140:27017,10.28.195.141:27017
  configDB: config_replSet/10.6.98.32:27017,10.6.102.126:27017,10.6.98.62:27017
net:
  bindIp: 0.0.0.0
  port: 27019
processManagement:
  fork: true
  pidFilePath: "/data/mongos/mongos.pid"
security:
#  authorization: enabled
  keyFile: /usr/local/mongodb/mongo_repl.key
systemLog:
  destination: file
  path: "/data/mongos/log/mongos.log"
# logAppend: true


setParameter:
  taskExecutorPoolSize: 0
# 설정 방법 2 (명령어로)
mongos> db.runCommand({setParameter:1,taskExecutorPoolSize:0})
{
    "was" : 1,
"ok" : 1,
  "$clusterTime" : {
        "clusterTime" : Timestamp(1631672362, 1),
          "signature" : {
                    "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                "keyId" : NumberLong(0)
            }
},
        "operationTime" : Timestamp(1631672362, 1)
}

#확인 방법
mongos> db.runCommand({getParameter:1,taskExecutorPoolSize:1})
{
    "taskExecutorPoolSize" : 0,
        "ok" : 1,
  "$clusterTime" : {
        "clusterTime" : Timestamp(1631672363, 1),
          "signature" : {
                    "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                "keyId" : NumberLong(0)
            }
},
        "operationTime" : Timestamp(1631672363, 1)
}

 

반응형

Connection pool 확인

  • TaskExecutorPool 개수를 확인 가능 (16개)
    • 내부에 각 Shard DB들로 추가 connection 확인 가능
mongos> db.runCommand({"connPoolStats":1})
{
        "numClientConnections" : 0,
        "numAScopedConnections" : 0,
        "totalInUse" : 1,
        "totalAvailable" : 180,
        "totalCreated" : 5871,
        "totalRefreshing" : 0,
        "replicaSetMatchingStrategy" : "matchPrimaryNode",
        "pools" : {
                "NetworkInterfaceTL-ShardRegistry" : {
                        "poolInUse" : 0,
                        "poolAvailable" : 3,
                        "poolCreated" : 41,
                        "poolRefreshing" : 0,
                        "192.168.0.126:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 4,
                                "refreshing" : 0
                        },
                        "192.168.1.32:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 35,
                                "refreshing" : 0
                        },
                        "192.168.1.62:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 2,
                                "refreshing" : 0
                        }
                },
                "NetworkInterfaceTL-TaskExecutorPool-0" : {
                        "poolInUse" : 0,
                        "poolAvailable" : 9,
                        "poolCreated" : 355,
                        "poolRefreshing" : 0,
                        "192.168.0.101:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 2,
                                "refreshing" : 0
                        },
                        "192.168.0.199:27017" : {
                        ...
                        
                   "NetworkInterfaceTL-TaskExecutorPool-1" : {
                        "poolInUse" : 1,
                        "poolAvailable" : 8,
                        "poolCreated" : 366,
                        "poolRefreshing" : 0,
                        "192.168.0.101:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 5,
                                "refreshing" : 0
                        },
                        "192.168.0.199:27017" : {
                        ...
                  "NetworkInterfaceTL-TaskExecutorPool-10" : {
                        "poolInUse" : 0,
                        "poolAvailable" : 12,
                        "poolCreated" : 342,
                        "poolRefreshing" : 0,
                        "192.168.0.101:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 2,
                                "refreshing" : 0
                        },
                        "192.168.0.199:27017" : {
                        ...
               "NetworkInterfaceTL-TaskExecutorPool-15" : {
                        "poolInUse" : 0,
                        "poolAvailable" : 10,
                        "poolCreated" : 349,
                        "poolRefreshing" : 0,
                        "192.168.0.101:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 2,
                                "refreshing" : 0
                        },
                        "192.168.0.199:27017" : {
                                "inUse" : 0,
                                "available" : 1,
                                "created" : 1,
                                "refreshing" : 0
                        },
                        "192.168.0.92:27017" : {
                        ...

 

[참고]

Real MongoDB

Line Games 성세일님

AWS 이덕현님

https://www.mongodb.com/docs/v4.4/reference/parameters/#mongodb-parameter-param.taskExecutorPoolSize

https://muralidba.blogspot.com/2018/03/what-are-tunable-options-for-mongos.html

이미지 : https://www.modb.pro/db/52603

반응형
반응형

지난 블로그에서 Replica Set을 Archive 목적으로 StandAlone 으로 변경 후, 보안 이슈로 인해 Version Upgrade 도중 Local DB 관련하여 에러가 발생하여 Trouble Shooting 을 진행 하였습니다.

 

그래서 이번에는 Replica Set에서 StandAlone 으로 문제 없이 깨끗?하게 변경하는 부분에 대하여 테스트를 진행 하였습니다.

이번 테스트를 진행하면서 느낀점은, 몇몇 외국 블로그에 나온 내용들을 보면, 인증을 사용안하는 것일까 라는 의문이 생겼습니다. 왜냐하면 이번 테스트를 진행 하면서 인증(authorization) 로 인해 Local DB가 삭제가 되지 않는 이슈가 발생하였기 때문입니다.

 

글보다는 제가 진행한 방법에 대해서 이미지와 방법을 보시면 쉽게 변경 가능할 것 같습니다.

 

진행 방법

  1. Replica Set 멤버들 제거 (primary는 제거되지 않습니다. 물론 제거하는 방법도 존재-맨 하단 리플리케이션-멤버-재설정 참고)

  2. mongod.conf 에서 replication / security 모두 주석 처리 후 재 시작
  3. local DB 삭제 진행
  4. mongod.conf 에서 security 모두 원복 후 재 시작
  5. Local DB에서 startup_log collection 만 생성 되었는지 확인 및 방금 startup 로그만 존재하는 지도 확인
  6. 정상적으로 StandAlone DB 변경 완료
# 1. 멤버 삭제
# Primary 에서 진행되며, 각 멤버들만 삭제가 가능
# 기본형태 : rs.remove("host명:port")

replSet:PRIMARY> rs.remove("127.0.0.1:57018")
replSet:PRIMARY> rs.remove("127.0.0.1:57019")
----------------------------------------------------------------------------
# 2. config 수정 및 mongodb 재시작

$ vi /etc/mongod.conf

systemLog:
   destination: file
   path: /data/mongo_test/log/mongo.log
...
net:
   bindIp: 0.0.0.0
   port: 57017

#replication:
#   replSetName: "replSet"

#security:
#  authorization: enabled
#  keyFile: /data/mongo_test_repl.key


$ systemctl restart mongod.service
----------------------------------------------------------------------------
# 3. local DB 삭제 진행
$ mongo --port 57017
# 현재 standalone 으로 올라왔으며, security를 주석처리하였기 때문에 인증 없이 접속
> use local
> db.dropDatabase()

# 정상적으로 local DB가 삭제 된 것을 확인 가능
----------------------------------------------------------------------------
# 4. mongod.conf 에서 security 모두 원복 후 재시작

$ vi /etc/mongod.conf

systemLog:
   destination: file
   path: /data/mongo_test/log/mongo.log
...
net:
   bindIp: 0.0.0.0
   port: 57017

#replication:
#   replSetName: "replSet"

security:
  authorization: enabled
  keyFile: /data/mongo_test_repl.key
----------------------------------------------------------------------------
# 5. Local DB 확인 
$ mongo admin -uadmin -p --port 57017
> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
test    0.000GB
> 
> use local
switched to db local

> db.startup_log.find().pretty()

----------------------------------------------------------------------------
# 6. 완료

Replica Set 멤버 삭제

Replica Set member 들
Replica Set 멤버 제거

Stand Alone 형태의 단독 Mongodb 의 초기 모습

  • 단순 local 내에는 startup_log collection 만 존재하며, 해당 collection 에는 startup 에 대한 로그들이 존재

 

Authorization 상태에서 Local DB삭제 시 다음과 같은 에러 발생

  • 참고로, 4.2 부터는 writeConcern이 majority 라서 majority를 1로 주고 진행 하더라도 에러 발생하는 것을 확인 가능 (writeConcern의 문제가 아님)

그외

  • 일부 블로그에서는 각 collection 마다 삭제하는 것도 있었는데, 실제로 삭제가 되는 collection 이 있는가 하면, 반대로 동일하게 Auth 로 인해서 삭제가 되지 않는 collection  도 존재 하는 것을 확인

 


아래 내용은 replication 재설정 관련하여 도움을 받았던 블로그 입니다.

이 부분도 실제로 진행하였는데, 자료를 남기지 않아 추후 테스트하여 공유 하도록 하겠습니다.

출처: https://knight76.tistory.com/entry/mongodb-레플리케이션-멤버-재설정하기 [김용환 블로그(2004-2020):티스토리]

 

그 외 참고

https://9to5answer.com/how-to-convert-a-mongodb-replica-set-to-a-stand-alone-server

https://adelachao.medium.com/downgrade-mongodb-replica-set-to-a-standalone-node-fc50d58addf2

https://medium.com/@cjandsilvap/from-a-replica-set-to-a-standalone-mongodb-79fda2beaaaf

 

반응형
반응형

기존 Mongodb Upgrade 와 비슷한 문서이나, Replica set 에서 Archive 목적으로 StandAlone 으로 변경 후 Upgrade 진행 중 발생한 이슈에 대한 문서 입니다.

Replica Set using rpm upgrade (3.4 to 4.2)

 

[MongoDB] 3.4 to 4.2 upgrade (rpm)

RPM 으로 설치된 Replica Set 에 대해 Upgrade 방법 입니다. 기본적으로 Downtime 을 가지고 진행 합니다. Secondary 를 standalone 형태로 변경 후, 업그레이드 한다면 Downtime 없이 가능하며, 실제로 진행한 결..

hyunki1019.tistory.com

  • mongod.conf 에서 replica set 제거
  • 해당 상태에서 stand alone 형태로 startup 진행
  • Version Upgrade 진행

 

Repo 추가 및 설정

  • 하나의 yum Repository 로도 가능하나, 별도의 repository 추가하여 진행 하였습니다. (별다른 이유는 없습니다.)
  • 여기 까지는 위의 문서와 동일
cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-3.6.repo 
$ cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-4.0.repo 
$ cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-4.2.repo
# 3.6 추가
$ vi /etc/yum.repos.d/mongodb-org-3.6.repo 

[mongodb-org-3.6] 
name=MongoDB Repository 
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/3.6/x86_64/ 
gpgcheck=1 
enabled=1 
gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc

# 4.0 추가
$ vi /etc/yum.repos.d/mongodb-org-4.0.repo 

[mongodb-org-4.0] 
name=MongoDB Repository 
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.0/x86_64/ 
gpgcheck=1 
enabled=1 
gpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc

# 4.2 추가
$ vi /etc/yum.repos.d/mongodb-org-4.2.repo 

[mongodb-org-4.2] 
name=MongoDB Repository 
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.2/x86_64/ 
gpgcheck=1 
enabled=1 
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

# yum 초기화 진행
$ yum clean all 
$ yum update list

 

MongoDB Replica Set to Standalone 

  • 단순히 conf 파일에서 replication 관련 항목을 주석 후 진행 (<- 원인)
$ vi /etc/mongod.conf 
# 아래 replication 내역 주석 처리
...
#replication:
#   replSetName: "replSet"
...

$ systemctl stop mongod.service

 

MongoDB 3.4 to 4.2 Upgrade 진행

  • 해당 문서를 보면서 upgrade 를 진행 한다면 4.0 까지만 upgrade 진행 후 아래 모든 내용의 글을 읽으신 후에 4.2 로 진행 하시기 바랍니다.!!!!!
############ 3.6 ############
# mongo 서버 종료
$ systemctl stop mongod.service

# yum 으로 update 진행
$ yum -y update mongodb-org-3.6.23

# mongodb 서버 시작
$ systemctl start mongod.service

# mongodb 접속 후 확인
$ mongo admin -uadmin -p

# 현재값 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

# 중요!!!# featureCompatibilityVersion 수정
> db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )

# 정상적으로 변경되었는지 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

############ 4.0 ############
# mongo 서버 종료
$ systemctl stop mongod.service

# yum 으로 update 진행
$ yum -y update mongodb-org-4.0.27

# mongodb 서버 시작
$ systemctl start mongod.service

# mongodb 접속 후 확인
$ mongo admin -uadmin -p

# 현재값 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

# 중요!!!# featureCompatibilityVersion 수정
> db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )

# 정상적으로 변경되었는지 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

############ 4.2 ############
# mongo 서버 종료
$ systemctl stop mongod.service

# yum 으로 update 진행
$ yum -y update mongodb-org-4.2.18

# mongodb 서버 시작
$ systemctl start mongod.service
############################### 에러 발생하면서 startup 이 안되는 이슈 발생

 

발생 이슈

  • 전제 : 기존 Replica Set에서 StandAlone 형태로 변경 후 버전 업그레이드 진행
    • cf) Replica set 에서 업그레이드 진행시 다음과 같은 문제는 발생하지 않음
  • 문제 : 4.0 에서 4.2로 업그레이드 진행 후 startup 진행 시 startup 이 되지 않는 이슈
  • 에러 내역 (로그)
    • 주요 에러 내역
      • shutting down with code:100
      • exception in initAndListen: Location40415: BSON field 'MinValidDocument.oplogDeleteFromPoint' is an unknown field., terminating
$ systemctl start mongod.service
-> error 발생하면서 startup 이 되지 않음

mongod.log

2022-07-01T17:02:59.368+0900 I  CONTROL  [main] ***** SERVER RESTARTED *****
2022-07-01T17:02:59.370+0900 I  CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2022-07-01T17:02:59.373+0900 W  ASIO     [main] No TransportLayer configured during NetworkInterface startup
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] MongoDB starting : pid=36325 port=27017 dbpath=/data/mongo/repl_0 64-bit host=192.168.0.1
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] db version v4.2.21
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] git version: b0aeed9445ff41af57e1f231bce990b3
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] allocator: tcmalloc
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] modules: none
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] build environment:
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten]     distmod: amazon2
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten]     distarch: x86_64
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten]     target_arch: x86_64
2022-07-01T17:02:59.373+0900 I  CONTROL  [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "0.0.0.0", port: 27017 }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongod.pid" }, security: { authorization: "enabled" }, storage: { dbPath: "/data/mongo/repl_0", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log", quiet: true } }
2022-07-01T17:02:59.373+0900 I  STORAGE  [initandlisten] Detected data files in /data/mongo/repl_0 created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2022-07-01T17:02:59.373+0900 I  STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=7360M,cache_overflow=(file_max=0M),session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress],
2022-07-01T17:02:59.914+0900 I  STORAGE  [initandlisten] WiredTiger message [1656662579:914502][36325:0x7ff6d143a080], txn-recover: Recovering log 71644 through 71645
2022-07-01T17:02:59.985+0900 I  STORAGE  [initandlisten] WiredTiger message [1656662579:985670][36325:0x7ff6d143a080], txn-recover: Recovering log 71645 through 71645
...
2022-07-01T17:03:00.247+0900 I  STORAGE  [initandlisten] WiredTiger message [1656662580:247926][36325:0x7ff6d143a080], txn-recover: Set global recovery timestamp: (0, 0)
2022-07-01T17:03:00.258+0900 I  RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2022-07-01T17:03:00.260+0900 I  STORAGE  [initandlisten] No table logging settings modifications are required for existing WiredTiger tables. Logging enabled? 1
2022-07-01T17:03:00.267+0900 I  STORAGE  [initandlisten] Starting OplogTruncaterThread local.oplog.rs
2022-07-01T17:03:00.267+0900 I  STORAGE  [initandlisten] The size storer reports that the oplog contains 44774827 records totaling to 53269933556 bytes
2022-07-01T17:03:00.267+0900 I  STORAGE  [initandlisten] Sampling the oplog to determine where to place markers for truncation
2022-07-01T17:03:00.269+0900 I  STORAGE  [initandlisten] Sampling from the oplog between Jun 12 09:53:56:57 and Jun 30 10:45:36:1 to determine where to place markers for truncation
2022-07-01T17:03:00.269+0900 I  STORAGE  [initandlisten] Taking 992 samples and assuming that each section of oplog contains approximately 451255 records totaling to 536871395 bytes
2022-07-01T17:03:00.743+0900 I  STORAGE  [initandlisten] Placing a marker at optime Jun 12 13:10:49:4
2022-07-01T17:03:00.743+0900 I  STORAGE  [initandlisten] Placing a marker at optime Jun 12 17:58:42:4
....
2022-07-01T17:03:00.743+0900 I  STORAGE  [initandlisten] Placing a marker at optime Jun 30 08:04:48:175
2022-07-01T17:03:00.743+0900 I  STORAGE  [initandlisten] WiredTiger record store oplog processing took 475ms
2022-07-01T17:03:00.744+0900 I  STORAGE  [initandlisten] Timestamp monitor starting
2022-07-01T17:03:00.771+0900 I  STORAGE  [initandlisten] exception in initAndListen: Location40415: BSON field 'MinValidDocument.oplogDeleteFromPoint' is an unknown field., terminating
2022-07-01T17:03:00.771+0900 I  REPL     [initandlisten] Stepping down the ReplicationCoordinator for shutdown, waitTime: 10000ms
2022-07-01T17:03:00.771+0900 I  SHARDING [initandlisten] Shutting down the WaitForMajorityService
2022-07-01T17:03:00.771+0900 I  NETWORK  [initandlisten] shutdown: going to close listening sockets...
2022-07-01T17:03:00.771+0900 I  NETWORK  [initandlisten] Shutting down the global connection pool
2022-07-01T17:03:00.771+0900 I  STORAGE  [initandlisten] Shutting down the FlowControlTicketholder
2022-07-01T17:03:00.771+0900 I  -        [initandlisten] Stopping further Flow Control ticket acquisitions.
2022-07-01T17:03:00.771+0900 I  STORAGE  [initandlisten] Shutting down the PeriodicThreadToAbortExpiredTransactions
2022-07-01T17:03:00.771+0900 I  STORAGE  [initandlisten] Shutting down the PeriodicThreadToDecreaseSnapshotHistoryIfNotNeeded
2022-07-01T17:03:00.771+0900 I  REPL     [initandlisten] Shutting down the ReplicationCoordinator
2022-07-01T17:03:00.771+0900 I  SHARDING [initandlisten] Shutting down the ShardingInitializationMongoD
2022-07-01T17:03:00.771+0900 I  REPL     [initandlisten] Enqueuing the ReplicationStateTransitionLock for shutdown
2022-07-01T17:03:00.771+0900 I  -        [initandlisten] Killing all operations for shutdown
...
2022-07-01T17:03:01.196+0900 I  STORAGE  [initandlisten] WiredTiger message [1656662581:196670][36325:0x7ff6d143a080], txn-recover: Set global recovery timestamp: (0, 0)
2022-07-01T17:03:01.335+0900 I  STORAGE  [initandlisten] shutdown: removing fs lock...
2022-07-01T17:03:01.335+0900 I  -        [initandlisten] Dropping the scope cache for shutdown
2022-07-01T17:03:01.335+0900 I  CONTROL  [initandlisten] now exiting
2022-07-01T17:03:01.335+0900 I  CONTROL  [initandlisten] shutting down with code:100

 

해결 방안

  • 4.0 Downgrade 진행 및 local DB의 replset.minvalid 컬렉션의 oplogDeleteFromPoint 필드 unset 진행
# 4.0 Downgrade 진행
$ yum -y downgrade mongodb-org-4.0.27

# mongodb startup 진행
$ systemctl start mongod.service

# mongodb 접속 후 확인
$ mongo admin -uadmin -p

# local 에서 replset.minvalid Collection 의 oplogDeleteFromPoint 필드 $unset 진행
> use local
switched to db local

> db.replset.minvalid.find({}).pretty ();
{
        "_id" : ObjectId("5ec3b7c56db7b066b3f5d5e3"),
        "ts" : Timestamp(1643225280, 1),
        "t" : NumberLong(7),
        "oplogDeleteFromPoint" : Timestamp(0, 0)
}

# update 진행 검색 조건은 _id 결과로 $unset 진행
> db.replset.minvalid.update(
...  { "_id" : ObjectId("5ec3b7c56db7b066b3f5d5e3")},
...    { $unset: { oplogDeleteFromPoint: ""} }
... );
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })

# 해당 필드 값 확인
> db.replset.minvalid.find({}).pretty ();
{
        "_id" : ObjectId("5ec3b7c56db7b066b3f5d5e3"),
        "ts" : Timestamp(1643225280, 1),
        "t" : NumberLong(7)
}
> exit

# 이후 다시 mongodb 4.2 upgrade 진행
# mongo 서버 종료
$systemctl stop mongod.service

# yum 으로 update 진행
yum -y update mongodb-org-4.2.18

# mongodb 서버 시작
$ systemctl start mongod.service

# mongodb 접속 후 확인
$ mongo admin -uadmin -p

# 현재값 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

# 중요!!!# featureCompatibilityVersion 수정
> db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

# 정상적으로 변경되었는지 확인
> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

 

발생 원인

  • Replica set 을 정상적으로 삭제 하지 않고 단순 config 파일에서 수정 후 진행하다가 발생한 이유
  • mongodb 4.2에서 MinValidDocument.oplogDeleteFromPoint dependency (예상)

 

발생 방지 방법

  • MongoDB Replica set 에서 StandAlone 으로 변경 시 정상적인 방법으로 진행
# 1. 모든 Secondary 삭제 진행
repl_set:PRIMARY> rs.remove("Secondary 호스트 이름:27017")
repl_set:PRIMARY> rs.remove("Arbiter 호스트 이름:27018")

# 2. config 파일에서 replication 주석 처리 또는 제거
$ vi /etc/mongod.conf
...
#replication:
#   replSetName: "replSet"
...

# 3. mongodb 재시작(Primary)
$ systemctl restart mongod.service

# 4. local database 삭제
# mongodb 접속 시 현재 standalone 상태
> use local
> db.dropDatabase()

# 5. mongodb 깔끔하게 확인차 재시작(Primary)
$ systemctl restart mongod.service

 

결론

  • Replica Set의 동작 방식 뿐만 아니라 각 DB(Local, admin 등)들의 역할에 대해서 다시 한번 공부가 필요
  • MongoDB에 대한 공부 공부 공부!!!

 

해당 문제를 해결하는 과정에 많은 도움을 주신 TechPM 박경배 팀장님에게 감사 인사 드립니다.

반응형

+ Recent posts