셀코의 블로그 셀코의 블로그

개요 MySQL은 세계에서 가장 많이 쓰이는 오픈 소스의 관계형 데이터베이스 관리 시스템(RDBMS)이다. 다중 스레드, 다중 사용자 형식의 구조질의어 형식의 데이터베이스 관리 시스템으로서 오라클이 관리 및 지원하고 있으며, Qt처럼 이중 라이선스가 적용된다. 하나의 옵션은 GPL이며, GPL 이외의 라이선스로 적용시키려는 경우 전통적인 지적재산권 라이선스의 적용을 받는다. 위와 같은 지원 방식은 자유 소프트웨어 재단이 프로젝트에 저작권을 적용하는 방법과 비슷한 JBoss의 모델과 유사하다. 그러나 기반코드가 개인의 소유자에게 저작권이 있고 커뮤니티에 의해 개발되는 아파치 프로젝트와는 다르다. MySQL AB는 또한 MaxDB라고 불리는 MySQL AB와는 기반코드가 다른 데이터베이스 관리 시스템을 판매..

Conf 파일은 yum , apt 를 이용한 설치시 /etc/mongod.conf 에 구성됩니다. Conf 파일은 YAML 포멧을 사용합니다. Command Line 이 길어지면 불편하기 때문에 mongod.conf 를 기준으로 하여 설정사항에 대하여 안내합니다. Command Line 구성시 각 Option 의 Command 는 아래 참조를 확인하세요. Option Command : https://docs.mongodb.com/manual/reference/configuration-file-settings-command-line-options-mapping/#std-label-conf-file-command-line-mapping systemLog Options systemLog: verbosity: ..

dump $ mongodump --host 127.0.0.1 --port 27017 모든 DB를 덤프하며, 해당 위치에 dump 폴더를 생성합니다. --out 옵션을 사용하여 경로를 지정할 수 있습니다. --db 옵션을 사용하여 특정 DB만을 덤프할 수 있습니다. -u, -p 옵션을 사용하여 인증 할 수 있습니다. restore 데이터 복구는 아래의 명령을 통해서 할 수 있습니다. --drop 옵션은 복구하는db와 중복될 경우 drop 시키는 옵션입니다. $ mongorestore --host 127.0.0.1 --port 27017 -u계정명 -p비번 --drop 원래디비에서 드랍시킬 디비명 --db 선택적으로 복구하려는 db명 "복구하려는 덤프된 디렉터리 위치" export -d database -c..

ReadConcern ReplicaSet 에서 Secondary 가 해당 데이터를 가지고 있는지 검증 후 읽기 작업을 진행하는 기능입니다. 이는 Shard Cluster 에서도 적용됩니다. 기본 형식은 다음과 같습니다. readConcern: { level: } level description "local" 추가 검증을 하지 않고 읽기 작업 진행(default) "avaliable" local 과 동일하지만 Shard Cluster 에서의 읽기작업인 경우 "majority" 과반수의 구성원에 대하여 검증 "linearizable" 쓰기 동작이 있을 경우 대기 후 처리 "snapshat" 다중 트랜젝션에서 사용 WriteConcern 쓰기 작업에 대한 요청 승인 수준을 지정할 수 있습니다. ReplicaS..

원자성은 트랜잭션이 시작되고 종료되었는지를 알려주는 메커니즘과 변경 전, 후 데이터의 복사본을 보존하는 것에 의해 실행되며, 이 원자성을 가질 수 있게 해주는것이 tansaction 입니다. 단일 도큐먼트에서는 원자성이 성립하나 여러 개의 도큐먼트를 CRUD하는 경우에는 원자성이 성립하지 않는다는 것입니다. 여러 도큐먼트에서 원자성을 유지하기 위해서는 트랜잭션이 필요합니다. 단순하게 보면 여러개의 작업을 할때, 명령 중 하나가 실패했을때 반영되지 않아야 한다면 트랜잭션 을 사용하면 됩니다. 트랜잭션으로 처리할 수 있는 작업은 도큐먼트를 CRUD하는 것만 가능하며 컬렉션을 생성하는 등 도큐먼트 레벨을 벗어나는 작업은 할 수 없습니다. session = db.getMongo().startSession() s..

ReplicaSet 구성 Primary : 메인 DB Secondary : Primary DB 정보를 동기화 ( Primary 절체시 Primary로 동작 ) Arbiter : 데이터 동기화 하지 않으며, 절체시 다음 Primary를 선정하는데 사용 성능규격상에는 천대이상이 하나의 ReplicaSet으로 구성될 경우 성능상 이슈가 있을 수 있으며, 각 ReplicaSet을 구성하는 서버들은 같은 장비에 구성하지 않는 것을 권고합니다. Primary 레플리카 셋에서 프라이머리 노드는 단 하나만 존재 할 수 있습니다. 프라이머리만이 직접적으로 클라이언트와 정보를 주고 받기 때문에 프라이머리가 장애가 발생하거나 네트워크에 문제가 발생하면 실제 레플리카셋이 구성되어 있더라도 세컨더리가 프라이머리로 올라오는 동안..

각 장비에 mongodb 2개, config server 1개, mongos 1개가 구성됩니다. Config, db, pid 경로 및 파일을 추가생성하여 하나의 서버에서 다수개를 구동할 수 있습니다. 다만 ReplicaSet 의 절체가 정상적으로 이루어지지 않는 경우가 발생할 수 있는점과 성능 및 구조상 이슈로 인하여 MongoDB 에서는 해당 구조를 추천해주지 않지만, 기존 IPRON 의 구조가 장비 2대를 통한 Active/Standby 임으로 임의 구성해보았습니다. 커맨드구성으로도 가능하지만, 차후 관리편의성을 생각해서 systemctl 에 등록하는 방향으로 가이드합니다. 두대의 장비에 이중화 설정 및 Shard Cluster 구성은 다음과 같이 생성됩니다. Shard Cluster 에서 Confi..

Sharding Sharding 은 데이터를 여러서버에 분산해서 저장하고 처리하는 기술을 의미합니다. 일반적인 환경 구성시 Sharding 과 ReplicaSet 둘을 모두 구성합니다. Sharded Cluster Shard : ReplicaSet 을 의미합니다. Mongos : Application 과 Sharded Cluster 간 인터페이스를 제공해주고 라우터와 같은 역활을 합니다. Config Servers : 설정 서버에서는 클러스터의 메타 데이터와 설정들을 저장합니다. 기본적인 Shareded Cluster 는 MongoDB 측에서 다음과 같은 구성을 권장합니다. Shard Key Shard Key 를 이용하여 Collection 의 Document 를 배포합니다. 별도로 지정하지 않을 경우 ..