mongodb에서 replication member를 재설정해야 할 때가 있다.


master가 (not reachable/healthy) 되어 있거나, slave가 다른 장비로 교체되야 할 때, 재구성해야 할 필요성이 있다..


이럴 때를 위한 mongodb 어드민 툴을 제공한다


slave만 삭제하거나 추가할 때는 아래와 쉽게 할 수 있다. 


rs.remove("1.1.1.1:27017")

rs.add("1.1.1.2:27017")



그러나 클러스터가 완전히 깨져 있고, master가 없는 상황이라면 다시 재구성해야 한다. 


cfg = rs.conf()


master, slave 구성과 상관없이 cfg에 rs.conf() 결과를 저장하고, 살아있는 일부 서버만으로 구축할 수 있다. 이 중 한 대만 구축하려고 진행한다.



cfg.members = [cfg.members[0]]



그리고 마지막으로 re.reconfig를 실행하고 강제(force:true) 설정한다. 


rs.reconfig(cfg, {force : true})

{ "ok" : 1 }





참고


https://docs.mongodb.com/manual/tutorial/reconfigure-replica-set-with-unavailable-members/

Posted by '김용환'
,



telegraf에서 mongodb 모니터링를 지원한다.


https://github.com/influxdata/telegraf/tree/master/plugins/inputs/mongodb


이전에 알아야 할 내용은 http://knight76.tistory.com/entry/grafana(먼저 influxDB, grafana, telegraf를 설치한다.)를 참조한다.




$ cd /etc/telegraf


$ sudo sh -c 'telegraf -sample-config -input-filter mongodb -output-filter influxdb > telegraf.conf'




$ sudo vi /etc/telegraf/telegraf.conf


  urls = ["http://monitir.google.io:8086"] # required

  database = "mongodb" # required




테스트하고 정상적인지 확인한다.


$ telegraf -config telegraf.conf -input-filter mongodb -test

* Plugin: inputs.mongodb, Collection 1



telegraf 데몬을 시작한다. 


$ sudo service telegraf start








Posted by '김용환'
,



mongo db 3.2-> mongo db 3.4 migration 설명이다. 

이미 wiredTiger 버전을 사용 중이라 큰 이슈가 없지만, 

cenots 부분에서는 조금 mongo 3.4 부터 centos 6과  7 버전으로 나누어지지, 잘 유의해서 설치해야 한다. 

(참고로 centos6 관점에서 mongdb 3.2는 70M인 반면, mongodb 3.4는 100M이다)


https://docs.mongodb.com/manual/administration/install-enterprise-linux/




새로 추가된 mongodb 3.4의 기능은 다음과 같다. 


https://docs.mongodb.com/manual/release-notes/3.4/




slave에서 먼저 셧다운한다. 


$ mongo


MongoDB shell version: 3.2.10

connecting to: test

replset:SECONDARY> use admin

switched to db admin

replset:SECONDARY> db.shutdownServer()

server should be down...



binary를 교체한다. 재시작하기 전에 /etc/mongodb.conf 설정 파일을 수정한다. 



cd /usr/local

sudo wget ..mongodb-linux-x86_64-rhel62-3.4.1.tgz

sudo tar zxvf mongodb-linux-x86_64-rhel62-3.4.1.tgz

sudo rm mongodb-linux-x86_64-rhel62-3.4.1.tgz

sudo chown www:www mongodb-linux-x86_64-rhel62-3.4.1

sudo rm mongodb

sudo ln -sf  mongodb-linux-x86_64-rhel62-3.4.1 mongodb




다음에 mongodb를 실행한다.


/usr/local/mongodb/bin/mongod -f /etc/mongod.conf



아래와 같은 문구가 mongo 경고가 발생하지만, 큰 문제 아니다. xfs를 써야 좋아진다거나 acl을 쓰라는 경고이다. 


** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine

 **          See http://dochub.mongodb.org/core/prodnotes-filesystem


** WARNING: Access control is not enabled for the database.

Read and write access to data and configuration is unrestricted.




mongo 3.4에서 다음 커맨드를 실행한다.


use admin

db.runCommand( { replSetGetStatus : 1 } )




레플리카 저오를 포함하는 optimes가 새로 추가되었다. 

(https://docs.mongodb.com/manual/reference/command/replSetGetStatus/)


"optimes" : {

"lastCommittedOpTime" : {

"ts" : Timestamp(1483325059, 2),

"t" : NumberLong(-1)

},

"appliedOpTime" : Timestamp(1483325059, 2),

"durableOpTime" : Timestamp(1483325059, 2)

},





동기화가 잘 완료되었는지 명확히 알기는 어렵지만, rs.status() 결과에 slave에 아래 heartbit 관련 필드가 포함되어 있다면 동기화가 완료된 것으로 생각하고 있다.(자세한 것은 소스보며 추후 살펴 볼 예정이다)


optimeDurableDate

lastHeartbeat

lastHeartbeatRecv





Posted by '김용환'
,


쉘에서 mongodb 클라이언트를 사용하려면, sudo yum install mongodb를 실행해 mongodb를 설치한다. 


그리고, mongo 커맨드에 mongodb 서버에 커맨드를 실행한다. 



$ mongo abc.google.io:27017/mydb --eval "db.api_feeds_list"

MongoDB shell version: 2.4.14

connecting to: abc.google.io:27017/mydb

mydb.api_feeds_list



db 상태를 볼 수 있다. 하지만, 바로 js 객체로만 나온다. 


$ mongo abc.google.io:27017/mydb --eval "db.stats()"

MongoDB shell version: 2.4.14

connecting to: abc.google.io:27017/mydb

[object Object]



DB 상태를 보기 위해 printjson과 같은 함수를 써서 상세하게 볼 수 있다. 


$ mongo abc.google.io:27017/mydb --eval "printjson(db.stats())"

MongoDB shell version: 2.4.14

connecting to: abc.google.io:27017/mydb

{

"db" : "mydb",

"collections" : 620,

"objects" : 326613,

"avgObjSize" : 1669.3089405504375,

"dataSize" : 545218001,

"storageSize" : 250097664,

"numExtents" : 0,

"indexes" : 620,

"indexSize" : 29995008,

"ok" : 1

}




마찬가지로 object Object로 리턴하면 printjson으로 확인할 수 있다. 


$ mongo abc.google.io:27017/mydb --eval "printjson(db.api_feeds_list.findOne())"

MongoDB shell version: 2.4.14

connecting to: abc.google.io:27017/mydb

{

"_id" : ObjectId("564c808630325673616b25ad"),

"date" : "20151117",

"max" : 18133,

"sum" : 49779120,

"stdev" : 17.49,

"max_user" : 75847769,

"uniq_user" : 8153500,

"mean" : 6.1

}



자바 스크립트를 안다면, 다음처럼 파일로 전달해 처리할 수 있다. 


$ cat > mytest.js

printjson(db.stats())


$ mongo abc.google.io:27017/mydb mytest.js

MongoDB shell version: 2.4.14

connecting to: abc.google.io:27017/mydb

{

"db" : "mydb",

"collections" : 620,

"objects" : 326635,

"avgObjSize" : 1669.559428720131,

"dataSize" : 545336544,

"storageSize" : 250134528,

"numExtents" : 0,

"indexes" : 620,

"indexSize" : 29995008,

"ok" : 1

}




Posted by '김용환'
,



replica 구성한 mongodb(wiredTiger)의 3.2.0을 3.2.10으로 버전업한 내용을 설명한다. (별 내용은 아니지만..)


replica 버그가 의심되는 부분이 있어서 버전업을 진행했다.


관련 내용 : http://knight76.tistory.com/entry/mongodb-32%EC%9D%98-slave%EC%9D%98-recovering-%EC%83%81%ED%83%9C-%EB%B3%B5%EA%B5%AC%ED%95%98%EA%B8%B0




먼저 slave 한대에 서버에 접속해서 shutdown한다. (그냥 kill 하면 pid 파일도 같이 지워야 하니. 이 명령대로 사용하는 것이 좋다.


$mongo


> use admin

>db.shutdownServer({timeoutSecs: 1});




새로운 mongodb를 설치한다. 나는 SSL을 지원하지 않는 linux x386 64 비트 파일(mongodb-linux-x86_64-3.2.10.tgz)를 설치했기 때문에, 3.2.10에 맞춰 다운로드했다.


$ which mongo

/usr/local/mongodb/bin/mongo


$ sudo tar zxvf mongodb-linux-x86_64-3.2.10.tgz


$ sudo chown -R www:www mongodb-linux-x86_64-3.2.10


$ sudo rm mongodb


$ sudo ln -sf mongodb-linux-x86_64-3.2.10 mongodb




이제 데몬을 재실행한다.

설정 파일을 항상 따로 두어야. 업그레이드시 손이 덜 간다.


$ /usr/local/mongodb/bin/mongod -f /etc/mongod.conf


테스트해본다.


$ mongo

MongoDB shell version: 3.2.10

connecting to: test

replset:SECONDARY> rs.status()

..


정상적이다.


이렇게 다른 slave, master에 적용하고, 마지막에 rs.status()로 제대로 동작되는지 확인한다.






참고


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




Posted by '김용환'
,


mongodb 3.2 wiredTiger 버전을 사용 중이고, 대용량 트래픽을 조금씩 받고 있는 mongodb가 있다. 


하지만, mongodb의 replicaset 구축하고 나서, mariadb(mysql) 만큼 안정성이 높지 않은 것에 대해 최근 경악한 일이 있어서 공유한다. 



mongodb가 slave가 RECOVERING 상태가 오래동안 두면, 자동으로 복구가 되길 바라지만 복구가 절대 되지 않는 경우가 있는 것 같다. 그러면 FAILED였으면 더 좋았을 뻔.. 


내가 겪은 내용 뿐 아니라 mongodb는 안전화될 때까지 주기적으로 손을 봐야하고, 안전화가 필요한 것으로 보여진다. (jira 참조)






Replication 상태를 확인해본다. Slave 한대가 Recovering 상태이고, 동기화가 안된지 꽤 오랜 시간이 걸렸다.  slave 자입의 optimeDate가 오래되었다. 동기가 실패된지 꽤 오랜 시간이 되었음을 알린다. 


$ mongo

MongoDB shell version: 3.2.0

connecting to: test

replset:RECOVERING> rs.status()

{

"set" : "replset",

"date" : ISODate("2016-10-21T01:40:13.146Z"),

"myState" : 3,

"term" : NumberLong(-1),

"heartbeatIntervalMillis" : NumberLong(2000),

"members" : [

{

"_id" : 0,

"name" : "1.1.1.1:27017",

"health" : 1,

"state" : 3,

"stateStr" : "RECOVERING",

"uptime" : 25473606,

"optime" : Timestamp(1457316114, 1871),

"optimeDate" : ISODate("2016-03-07T02:01:54Z"),

"maintenanceMode" : 328882,

"infoMessage" : "could not find member to sync from",

"configVersion" : 1,

"self" : true

},

{

"_id" : 1,

"name" : "2.2.2.2:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 3521143,

"optime" : Timestamp(1477013949, 1),

"optimeDate" : ISODate("2016-10-21T01:39:09Z"),

"lastHeartbeat" : ISODate("2016-10-21T01:40:12.320Z"),

"lastHeartbeatRecv" : ISODate("2016-10-21T01:40:12.999Z"),

"pingMs" : NumberLong(0),

"electionTime" : Timestamp(1451540357, 1),

"electionDate" : ISODate("2015-12-31T05:39:17Z"),

"configVersion" : 1

},

...





이제 제대로 동기화되게 해보자.



1.1.1.1 (slave)서버에 가서 몽고 셧다운을 한다. 


$ mongod --shutdown

killing process with pid: 26867

$ ps -ef | grep mongo

(없음)




/etc/mongod.conf 에 정의된 db데이터-디렉토리를 백업해두고 새로 디렉토리를 생성한다.


$ mv db데이터-디렉토리  백업디렉토리

$ mkdir db데이터-디렉토리




$  /usr/local/mongodb/bin/mongod -f /etc/mongod.conf


about to fork child process, waiting until server is ready for connections.

forked process: 19670

child process started successfully, parent exiting

$ ps -ef | grep mongo

/usr/local/mongodb/bin/mongod -f /etc/mongod.conf






2.2.2.2(master) 서버에서 replication 상태를 보기 위해 rs.status() 를 실행한다. 1.1.1.1(slave) 서버의 상태가 STARTUP2로 변경되었다. 



$ mongo

MongoDB shell version: 3.2.0

connecting to: test

replset:PRIMARY> rs.status()

{

"set" : "replset",

"date" : ISODate("2016-10-21T01:45:15.535Z"),

"myState" : 1,

"term" : NumberLong(-1),

"heartbeatIntervalMillis" : NumberLong(2000),

"members" : [

{

"_id" : 0,

"name" : "1.1.1.1:27017",

"health" : 1,

"state" : 5,

"stateStr" : "STARTUP2",

"uptime" : 28,

"optime" : Timestamp(0, 0),

"optimeDate" : ISODate("1970-01-01T00:00:00Z"),

"lastHeartbeat" : ISODate("2016-10-21T01:45:15.081Z"),

"lastHeartbeatRecv" : ISODate("2016-10-21T01:45:14.171Z"),

"pingMs" : NumberLong(0),

"lastHeartbeatMessage" : "syncing from: 172.17.58.238:27017",

"syncingTo" : "172.17.58.238:27017",

"configVersion" : 1

},

{

"_id" : 1,

"name" : "2.2.2.2:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 25474192,

"optime" : Timestamp(1477014306, 1),

"optimeDate" : ISODate("2016-10-21T01:45:06Z"),

"electionTime" : Timestamp(1451540357, 1),

"electionDate" : ISODate("2015-12-31T05:39:17Z"),

"configVersion" : 1,

"self" : true

},

...






처음 상태는 STARTUP2가 되고, 데이터 동기가 완료되면, SECONDARY로 상태가 변경된다.


데이터가 많을수록, IO(N/W) 시간이 느릴 수록 동기화 완료가 늦어진다.  (이래서 SLAVE 장비가 좋아야 한단 것인가..)




동기화가 완료되면, 제대로 싱크되는지 확인할 수 있다.


replset:SECONDARY> db.printSlaveReplicationInfo()

source: ip:27017

syncedTo: Thu Jan 01 1970 09:00:00 GMT+0900 (KST)

1477015631 secs (410282.12 hrs) behind the primary

source: ip:27017

syncedTo: Fri Oct 21 2016 11:07:11 GMT+0900 (KST)

0 secs (0 hrs) behind the primary




또한, rs.status() 명령어를 실행하면 SECONDARY로 돌아온 것을 확인할 수 있다.





이 문제를 해결하기 위해 다양하게 접근 중이다. 문제 해결을 위해 다양한 해결 방식을 채택하면서 모니터링하면서 살펴봐야할 것 같다. 



1. mongodb 업그레이드

mongodb 3.x는 여진히 진화 중이다. 여전히 버그가 많아서 게속 버전 업을 진행해야 한다. 




2. oplog 크기



몽고DB 문서(https://docs.mongodb.com/manual/core/replica-set-oplog/#replica-set-oplog-sizinghttps://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/)에 따르면, oplog 디폴트 크기는 다음과 같다. 

WiredTiger Storage Engine5% of free disk space990 MB50 GB

oplog size를 확인해본다.


$ mongo

MongoDB shell version: 3.2.0

connecting to: test

replset:PRIMARY>  rs.printReplicationInfo()

configured oplog size:   10240MB




설정파일에서 oplog size를 설정할 수 있다. 나는 이미 10G로 내가 임의로 설정할 수 있다. 


replication:

  oplogSizeMB: 10240

  replSetName: "replset"





3. /var/log/mongodb/mongod.log 파일에서 로그 분석


마지막으로 끊긴 시간을 기준으로 로그를 분석해 본다.

"optimeDate" : ISODate("2016-03-07T02:01:54Z"),



해당 일자 단위로 slave 로그를 보면, stale 상태로 된 것을 확인할 수 있다.



[ReplicationExecutor] syncing from: ip:27017

[rsBackgroundSync] we are too stale to use ip:27017 as a sync source

[ReplicationExecutor] could not find member to sync from

[rsBackgroundSync] too stale to catch up -- entering maintenance mode

[rsBackgroundSync] our last optime : (term: -1, timestamp: Mar  7 11:01:54:74f)

[rsBackgroundSync] oldest available is (term: -1, timestamp: Mar  7 11:09:19:21f)

[rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember

[ReplicationExecutor] going into maintenance mode with 524 other maintenance mode tasks in progress



로그가 가르키는 문서를 참조해 본다.

https://docs.mongodb.com/manual/tutorial/resync-replica-set-member/



stale 상태가 되면 데이터를 지우고 resync 작업을 진행하고 초기화 작업을 진행한다.

위에서 진행한 작업이 사실상 resync&init 작업이었다. 



  1. Stop the member’s mongod instance. To ensure a clean shutdown, use the db.shutdownServer()method from the mongo shell or on Linux systems, the mongod --shutdown option.
  2. Delete all data and sub-directories from the member’s data directory. By removing the data dbPath, MongoDB will perform a complete resync. Consider making a backup first.





4. 다른 방법


성능이 좋은 장비를 써서 mongodb 쿼리가 빠르게 실행되도록 해야 한다. 

찾아보니,  대용량  map reduce 가 상황에 따라서 blocking을 유발시킬 수 있다고 한다.  관련 내용을 찾아보고 있다. 


http://blog.mlab.com/2013/03/replication-lag-the-facts-of-life/ 글에 따르면 slave가 recovering(stale) 상태에 빠지지 않는 여러 방법을 제안했다. 


1. Make sure your secondary has enough horsepower

2. Consider adjusting your write concern

3. Plan for index builds

4. Take backups without blocking

5. Be sure capped collections have an _id field & a unique index

6. Check for replication errors





5. 툴을 이용한 모니터링


http://www.slideshare.net/revolutionistK/mongo-db-monitoring-mongodb-korea


상용 툴 : mongodb mms

https://www.mongodb.com/cloud


grafana쪽도 살펴봐야 할 것 깉다. 



좀 더 모니터링해보고, 정확한 문제에 대한 해결 방법을 정리해야 할 것 같다. .




6. 다양한 공부



https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/






*****


나중에 해보니.. 


3.4로 업글하고,

replication의 oplogSizeMB을 작게 줄이니(10G->1G) 대용량 트래픽에도 replication이 끊어지지 않게 되었다. 


Posted by '김용환'
,

[mongdob] protocol version

mongodb 2016. 2. 23. 16:08


mongodb 에서 rs.conf() 명령어에서 나오는 protocol version은 3.2부터 추가된 필드이다. 

이전 버전은 아예 이 정보가 없다. 


https://docs.mongodb.org/manual/reference/replica-configuration/



protocolVersion

New in version 3.2.

Type: number

Default: 1 for new replica sets

Version of the replica set election protocol.

Set to 1 to enable the replication election enhancements introduced in MongoDB 3.2.

By default, new replica sets in MongoDB 3.2 use protocolVersion: 1. Previous versions of MongoDB use version 0 of the protocol and cannot run as members of a replica set configuration that specifies protocolVersion 1.


Posted by '김용환'
,


mongodb 로그 분석 툴은 mtools을 사용한다.


https://github.com/rueckstiess/mtools


git으로 다운받고 python 설치를 했다.



git clone https://github.com/rueckstiess/mtools.git

cd mtools

python setup.py builds

sudo python setup.py install



/usr/local/bin/에 mtools가 설치되었다. 느린 커맨드와 패턴을 보기 위해 로그 파일을 분석해 본다.


$ mloginfo mongod.log --queries

     source: mongod.log

       host: orange096:27017

      start: 2015 Sep 22 16:03:16.892

        end: 2016 Jan 26 11:05:40.943

date format: iso8601-local

     length: 1322382

     binary: mongod

    version: 3.0.6 -> 3.2.0

    storage: wiredTiger


QUERIES

...




명령어에 대한 문서는 https://github.com/rueckstiess/mtools/wiki에 존재한다.



Posted by '김용환'
,


mongodb 3.x에서 collection shema를 보고 싶다면, getIndexes()를 호출하다. DB 세계의 describe table()과 비슷하다.



> db.google.getIndexes()

[

{

"v" : 1,

"key" : {

"_id" : 1

},

"name" : "_id_",

"ns" : "staticmap.google"

},

{

"v" : 1,

"key" : {

"expireAt" : 1

},

"name" : "expireAt_1",

"ns" : "staticmap.google",

"expireAfterSeconds" : 0

},

{

"v" : 1,

"key" : {

"placeId" : 1

},

"name" : "placeId",

"ns" : "staticmap.google"

}

]


참조

https://docs.mongodb.org/v3.0/reference/method/db.collection.getIndexes/


Posted by '김용환'
,


mongodb 3.0.6을 설치했었다.

http://knight76.tistory.com/entry/mongodb-replica-set-%EB%A7%8C%EB%93%A4%EA%B8%B0


이제 안정화 버전 3.2.0으로 업그레이드했다. (참고로 홀수 버전은 (3.1버전) 테스트 버전이다..)

이미 wiredtiger storage를 쓰고 있어서 특별한 설정(/etc/mongod.conf) 변경은 없다.



0, 1, 2 번 레플리카 (replica set)을 구축한 상태이고, 0 번이 master 이고, 1 번이 master를 바라보는 secondary 이며, 2번은 1번을 바라보는 sencondary로 되어 있다.


즉, 0 <----1 <----- 2 형태로 replica가 구축되어 있다. 

(참고로, redis에서는 이렇게 master-slave 작업을 해야 했었는데, mongodb는 자동으로 되어 있다.)


작업시 안전하게 redis 에서 작업한 경험대로 2, 1, 0번 순서대로 업그레이드를 했다.






먼저 2번 몽고에서 mongo shutdown을 한다. (참조 : https://docs.mongodb.org/manual/tutorial/manage-mongodb-processes/)


$mongo --port 27017 --eval 'db.adminCommand("shutdown")'


3.2.0 mongodb를 다운받고, 심볼링 링크를 걸고, 재시작한다. 


$ cd /usr/local

$ wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.2.0.tgz

$ sudo tar zxvf mongodb-linux-x86_64-3.2.0.tgz

$ sudo chown -R www.www mongodb-linux-x86_64-3.2.0

$ sudo rm mongodb

$ sudo ln -sf mongodb-linux-x86_64-3.2.0 mongodb

$  /usr/local/mongodb/bin/mongod -f /etc/mongod.conf


이런 식으로 하나씩 재시작하면 된다.  wiredtiger를 사용하는 3.0.6의 설정(위의 링크 참조)을 바꾸지 않고 그대로 3.2.0에서 사용했다.


재미있는 것은 replica 구성시 primary 서버에서 rs.status() 명령을 이용해서 레플리카의 상태를 체크할 수 있다.


1. 2번 slave에서 몽고 데몬을 내린 후, primary 서버에서 rs.status()로 확인하면 다음 상태를 확인할 수 있다. 



{

"_id" : 2,

"name" : "2.2.2.2:27017",

"health" : 0,

"state" : 8,

"stateStr" : "(not reachable/healthy)",

"uptime" : 0,

"optime" : Timestamp(0, 0),

"optimeDate" : ISODate("1970-01-01T00:00:00Z"),

"lastHeartbeat" : ISODate("2015-12-30T11:03:02.452Z"),

"lastHeartbeatRecv" : ISODate("2015-12-30T10:54:27.856Z"),

"pingMs" : 0,

"lastHeartbeatMessage" : "Failed attempt to connect to 1.1.1.1:27017; couldn't connect to server 1.1.1.1:27017 , connection attempt failed",

"configVersion" : -1

}


2. 2번 slave에서 몽고 데몬을 업그레이드 한 후, 실행한 후, primary 에서 rs.status()를 실행한다. 

2번 slave가 잘 동기화했고(syncingTo), optime이 1번과 동일해졌다. 잘 동기화되었음을 표시한다. 


{

"_id" : 1,

"name" : "1.1.1.1:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"optime" : Timestamp(1451473740, 44),

                        "syncingTo" : "0.0.0.0:27017",

}

{

"_id" : 2,

"name" : "2.2.2.2:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"optime" : Timestamp(1451473740, 44)

"syncingTo" : "1.1.1.1:27017",

}


3. 1번도 2번 몽고에서 작업한 것처럼 처리한다.


4. 원래 0번이 primary 몽고인데, shutdown했다.

원래는 내부적인 쿼럼 투표를 진행한다고 적혀 있긴 한데.

사실상 1번 slave 가 primary가 되었다. (0 <--------- 1 <--------- 2) 의 구성이라 직관적으로 1번이 primary가 되니 기분이 나쁘지 않았다 (redis쪽도 그렇게 되서..)



5. 1번 primary에서 rs.status()로 보면,  0번 mongo는 다음 상태가 된다. 

{

"_id" : 0,

"name" : "1.1.1.1:27017",

"health" : 0,

"state" : 8,

"stateStr" : "(not reachable/healthy)",

"uptime" : 0,

"optime" : Timestamp(0, 0),

"optimeDate" : ISODate("1970-01-01T00:00:00Z"),

"lastHeartbeat" : ISODate("2015-12-30T11:24:54.301Z"),

"lastHeartbeatRecv" : ISODate("2015-12-30T11:24:27.674Z"),

"pingMs" : NumberLong(0),

"lastHeartbeatMessage" : "Connection refused",

"configVersion" : -1

},


6. 0번 mongodb에서 업그레이드 후 데몬을 실행하면, secondary 몽고가 된다.


{

"_id" : 0,

"name" : "0.0.0.0:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 7,

"optime" : Timestamp(1451474879, 6),

"optimeDate" : ISODate("2015-12-30T11:27:59Z"),

"lastHeartbeat" : ISODate("2015-12-30T11:28:30.481Z"),

"lastHeartbeatRecv" : ISODate("2015-12-30T11:28:32.258Z"),

"pingMs" : NumberLong(0),

"lastHeartbeatMessage" : "syncing from: 2.2.2.2:27017",

"syncingTo" : "2.2.2.2:27017",

"configVersion" : 89449

},



레플리카의 동기여부는 unique한 optime(operation log time)이 서로 맞는지 확인하면 된다. 자세한 내용은 몽고 문서 참조(https://docs.mongodb.org/v3.0/reference/command/replSetGetStatus/)한다. 




* 참고

자동으로 잘 동작하면,  혹시 확인차 테스트해보았다. 처음 하는 사람이라면, rs.slaveOk()를 사용하여 테스트하는 것도 괜찮을 것 같다. 

http://knight76.tistory.com/entry/mongodb-replicaset-%EC%97%90%EC%84%9C-slave%EC%97%90%EC%84%9C-%EC%BF%BC%EB%A6%AC-%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B0






Posted by '김용환'
,