mongodb의 cluster의 최종편.... 후 힘드네....
mongos 이름하여 mongo cluster server 라 한다. 거두 절미 하고 셋팅 파일 부터 보자..
머 기존꺼랑 비슷하다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | #yml 파일이 존재 하지 않으면 /var/local/mongdb/data 에 data를 저장. (경로도 마찬가지로 없으면 default 경로에 저장.) #log역시 설정 정보가 없으면 /var/local/mongdb/logs/log.log에 저장. #net - network 설정 #하위 구조로 bindIp와 port를 설정한다. #bindIP는 mongoDB 자신의 ip를 설정. #port는 mongDB 의 port를 설정. net: bindIp: "192.168.0.105" port: 45005 #processManagement - 실행 옵션. #fork 는 백그라운드 옵션. processManagement: fork: true #storage - data 저장 경로를 설정. #dbpath - data를 저장할 실제 경로. #journal - data를 쓰기 전 , data write query를 파일에 저장하는 옵션. (일종의 검증, 복구를 위한 작업인듯...) # enabled - journal 을 쓸지 말지의 설정. #storage: # dbPath: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/cluster # journal: # enabled: true #destination: file, syslog 2가지 옵션 사용 가능 #file로 선언하면 path 옵션을 필수로 넣어서 경로를 직접 설정 #syslog로 선언하면 경로 설정 없이 디폴트 로그파일에 저장 # #verbosity: 로그 기록 레벨 # default : 0 # 0 ~ 5 숫자 값으로 레벨 구분 # 0 : all # 1 : debug, # 2: information # 3: warning # 4: errorm # 5: fatal systemLog: verbosity: 1 destination: file logAppend: true path: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/cluster_logs/cluster_log.log sharding: configDB: "192.168.0.105:45004" chunkSize: "64" | cs |
이것도 마지막 부분만 틀리다 sharding 이라는 설정 값이 추가 됬다 . 일단 옵션은 보통 한개면 될듯 보인다. configDB라는 옵션만.....
configDB는 앞서 설명한 config server의 아이피와 포트가 온다. 필자는 한개만 썻지만 여러개 썻다면 "xxx.xxx.xxx.xxx:12345, xxx.xxx.xxx.xxx:23456" 요렇게 하면된다. 그리고 두번째 chunkSize라는 넘이 있다. default는 64이다. mongodb의 chunk 는 데이터의 크기의 묶음(?) 정도가 되겠다.
이 말은 위에 구성은 여러개의 shard는 대략 저 크기로 데이터를 나눈다. 64M 이하인 data는 특정 shard 한군데를 정해서 데이터를 쌓을 것이다.
실행은 mongd가 아닌 mongos로 실행한다. 실행후 process를 확인해보자.
1 2 3 4 | 500 17431 1 0 Nov19 ? 00:01:45 ./bin/mongos -f cluster.yml | cs |
자 이제 모든 환경 셋팅은 끝났다. 근데 이상한게 보일 것이다. replicaset과 연동은????
이제 mongos 인 cluster server에 접속하자. 접속은 기존과 동일하게 ip와 port만 cluster server로 하면된다.
1 2 3 4 5 6 7 | sh.enableSharding("testDB");//없으면 만든다. sh.addShard("192.168.0.105:45001"); sh.status(); | cs |
접속후 sharding과 관련된 명령어인 sh 로 먼저 어떤 db를 sharding을 할지 설정한다.
addShard 명령어로 셋팅을 한다. 재미난 점은 위 예시는 primary 로 잡혀있는 서버를 했지만 secondary로 해도 된다.
그럼 제대로 shard를 하기 위해서 독립서버 55001을 한개 띄우고
sh.addShard("192.168.0.105:55001");
추가한다. 마지막으로 sh.status()로 상태 정보 를 확인해보자
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("564aff51f77bed76dca6ba70") } shards: { "_id" : "elastic", "host" : "elastic/192.168.0.105:45001,192.168.0.105:45002,192.168.0.105:45003" } { "_id" : "shard0000", "host" : "192.168.0.105:55001" } databases: { "_id" : "admin", "partitioned" : false, "primary" : "config" } { "_id" : "latis", "partitioned" : true, "primary" : "elastic" } latis.users shard key: { "index" : 1 } chunks: shard0000 4 elastic 5 { "index" : { $minKey : 1 } } -->> { "index" : 1 } on : shard0000 Timestamp(5000, 1) { "index" : 1 } -->> { "index" : 4369 } on : shard0000 Timestamp(3000, 0) { "index" : 4369 } -->> { "index" : 6554 } on : elastic Timestamp(4000, 1) { "index" : 6554 } -->> { "index" : 8739 } on : elastic Timestamp(1000, 4) { "index" : 8739 } -->> { "index" : 10923 } on : elastic Timestamp(3000, 2) { "index" : 10923 } -->> { "index" : 14000 } on : elastic Timestamp(3000, 3) { "index" : 14000 } -->> { "index" : 16184 } on : shard0000 Timestamp(4000, 2) { "index" : 16184 } -->> { "index" : 19000 } on : shard0000 Timestamp(4000, 3) { "index" : 19000 } -->> { "index" : { $maxKey : 1 } } on : elastic Timestamp(5000, 0) { "_id" : "users", "partitioned" : true, "primary" : "elastic" } { "_id" : "db", "partitioned" : false, "primary" : "elastic" } { "_id" : "test", "partitioned" : false, "primary" : "elastic" } | cs |
필자는 현재 data를 넣어봐서 위와 같은 그림이 보인다.
중요한 것은 위에 shards이다. 추가한 아이피와 포트가 다 생성 되있다...
이상으로 cluster는 완성 되었다.
다음은 cloud의 꽃(?)이라 불리는 aggregation과 mapreduce를 ......
앞서 보여준 그림을 보시면 오른쪽 위가 config server 되있을 것이다. 이는 shard에 대한 모든 쿼리(?) 들을 저장하며, 이를 가지고 백업 등에 사용 하게 된다. 그림의 가운데 위 mongos 라 써있는 서버 보다 먼저 셋팅 해야하는 이유는 mongos 에 config server의 설정을 써야 하므로 config server 를 먼저 셋팅 해야한다.
설정 정보는 기존 yml 파일과 거의 비슷하다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | #yml 파일이 존재 하지 않으면 /var/local/mongdb/data 에 data를 저장. (경로도 마찬가지로 없으면 default 경로에 저장.) #log역시 설정 정보가 없으면 /var/local/mongdb/logs/log.log에 저장. #net - network 설정 #하위 구조로 bindIp와 port를 설정한다. #bindIP는 mongoDB 자신의 ip를 설정. #port는 mongDB 의 port를 설정. net: bindIp: "192.168.0.105" port: 45004 #processManagement - 실행 옵션. #fork 는 백그라운드 옵션. processManagement: fork: true #storage - data 저장 경로를 설정. #dbpath - data를 저장할 실제 경로. #journal - data를 쓰기 전 , data write query를 파일에 저장하는 옵션. (일종의 검증, 복구를 위한 작업인듯...) # enabled - journal 을 쓸지 말지의 설정. storage: dbPath: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/shard journal: enabled: true #destination: file, syslog 2가지 옵션 사용 가능 #file로 선언하면 path 옵션을 필수로 넣어서 경로를 직접 설정 #syslog로 선언하면 경로 설정 없이 디폴트 로그파일에 저장 # #verbosity: 로그 기록 레벨 # default : 0 # 0 ~ 5 숫자 값으로 레벨 구분 # 0 : all # 1 : debug, # 2: information # 3: warning # 4: errorm # 5: fatal systemLog: verbosity: 1 destination: file logAppend: true path: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/shard_logs/log.log #replication: # replSetName: elastic sharding: clusterRole: configsvr | cs |
기존 replica set 과 다른점은 replication을 안쓰고 sharding이라는 설정이 추가 됐다. 그리고 clusterRole이라는 항목에 configsvr 이라는 configserver의 약자를 써주면 된다.
공식 사이트에선 이 서버를 여러대 설치 하라고 권장한다. 이유는 다른 정책 서버가 장애가 났을 시 다른 서버에서 값을 가져올 수 있으므로 권장한다. 머 다른이유는 없는거 같다.
서버는 replicaset 과 동일하게 실행하면 된다.
실행 후 process는 다음과 같은 형태가 될 것이다.
1 2 3 4 5 | 500 12235 1 0 Nov17 ? 00:07:42 ./bin/mongod -f startup2.yml 500 12251 1 0 Nov17 ? 00:07:05 ./bin/mongod -f startup3.yml 500 12267 1 0 Nov17 ? 00:07:03 ./bin/mongod -f startup4.yml 500 12298 1 0 Nov17 ? 00:10:28 ./bin/mongod -f shard_config.yml | cs |
아래 shard_config.yml이 정책 서버가 된다. 그럼 다음에는 mongos에 대해 알아본다.
이번에는 replicaset에 대해 설정해보자. 먼저 단일 서버를 셋팅한 yml 파일을 복사후 replication name을 셋팅하면 된다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 | #yml 파일이 존재 하지 않으면 /var/local/mongdb/data 에 data를 저장. (경로도 마찬가지로 없으면 default 경로에 저장.) #log역시 설정 정보가 없으면 /var/local/mongdb/logs/log.log에 저장. #net - network 설정 #하위 구조로 bindIp와 port를 설정한다. #bindIP는 mongoDB 자신의 ip를 설정. #port는 mongDB 의 port를 설정. net: bindIp: "192.168.0.105" port: 45001 #processManagement - 실행 옵션. #fork 는 백그라운드 옵션. processManagement: fork: true #storage - data 저장 경로를 설정. #dbpath - data를 저장할 실제 경로. #journal - data를 쓰기 전 , data write query를 파일에 저장하는 옵션. (일종의 검증, 복구를 위한 작업인듯...) # enabled - journal 을 쓸지 말지의 설정. storage: dbPath: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/data2 journal: enabled: true #destination: file, syslog 2가지 옵션 사용 가능 #file로 선언하면 path 옵션을 필수로 넣어서 경로를 직접 설정 #syslog로 선언하면 경로 설정 없이 디폴트 로그파일에 저장 # #verbosity: 로그 기록 레벨 # default : 0 # 0 ~ 5 숫자 값으로 레벨 구분 # 0 : all # 1 : debug, # 2: information # 3: warning # 4: errorm # 5: fatal systemLog: verbosity: 1 destination: file logAppend: true path: /home/solrslave/src/mongodb-linux-x86_64-rhel62-3.0.4/logs2/repl_log1.log replication: replSetName: elastic | cs |
1 2 3 | 500 12235 1 0 Nov17 ? 00:07:42 ./bin/mongod -f startup2.yml 500 12251 1 0 Nov17 ? 00:07:05 ./bin/mongod -f startup3.yml 500 12267 1 0 Nov17 ? 00:07:03 ./bin/mongod -f startup4.yml | cs |
그럼 위에 서버들이 replicaset으로 제대로 셋팅이 되었는지 확인해보자.
아무 몽고 서버에 먼저 접속을 한다. (robomngo tool 추천 또는 ./bin/mongo 아이피:포트 로 접속 하면된다.)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 | use dbaname //사용할 db로 이동. show dbs //모든 db의 이름 확인 show collections //모든 collection 이름 정보 확인 rs.status(); /* 1 */ { "set" : "elastic", "date" : ISODate("2015-11-20T09:44:41.517Z"), "myState" : 1, "members" : [ { "_id" : 1, "name" : "192.168.0.105:45001", "health" : 1.0000000000000000, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 258290, "optime" : Timestamp(1448006114, 22), "optimeDate" : ISODate("2015-11-20T07:55:14.000Z"), "electionTime" : Timestamp(1447920217, 1), "electionDate" : ISODate("2015-11-19T08:03:37.000Z"), "configVersion" : 1, "self" : true }, { "_id" : 2, "name" : "192.168.0.105:45002", "health" : 1.0000000000000000, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 92465, "optime" : Timestamp(1448006114, 22), "optimeDate" : ISODate("2015-11-20T07:55:14.000Z"), "lastHeartbeat" : ISODate("2015-11-20T09:44:40.779Z"), "lastHeartbeatRecv" : ISODate("2015-11-20T09:44:40.805Z"), "pingMs" : 0, "syncingTo" : "192.168.0.105:45001", "configVersion" : 1 }, { "_id" : 3, "name" : "192.168.0.105:45003", "health" : 1.0000000000000000, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 92465, "optime" : Timestamp(1448006114, 22), "optimeDate" : ISODate("2015-11-20T07:55:14.000Z"), "lastHeartbeat" : ISODate("2015-11-20T09:44:40.808Z"), "lastHeartbeatRecv" : ISODate("2015-11-20T09:44:40.783Z"), "pingMs" : 0, "syncingTo" : "192.168.0.105:45001", "configVersion" : 1 } ], "ok" : 1.0000000000000000, "$gleStats" : { "lastOpTime" : Timestamp(0, 0), "electionId" : ObjectId("564d825928cf905edab537fb") } } | cs |
mongodb의 replication 정보는 rs 명령어로 한다. rs.status() 함수를 하면 위 정보와 같이 나온다. 여기서 누가 primary이고 secondary인지 알 수있다. 기본적으로 모든 cloud는 대장(?)을 선출하는데 mongodb는 primary라 칭한다. 설정 정보를 보고싶으면, rs.config() 를 하면된다.
다음은 shard config server에대해 알아보겠다.