[Mongodb]웹서비스컴퓨팅_10주차

1. Replication(복제)

    => 어떤 기억 장소에서, 데이터를 원형대로 읽어 내어 그 데이터를 동일한 물리적 형식으로 다른 기억 장소에 써 넣는 것

    => 데이터를 여러 db 서버에 분산하여 저장 관리하는 기술

   => 여러 벌의 동일한 데이터베이스를 운영하기위해 필요한 작업

   => 필요에 따라 클라이언트가 메인 서버가 아닌, 복제 서버에 READ 요청을 하도록 설정
         / 메인 서버 부하를 낮추고, 복제된 데이터를 다른 부가적 용도(리포팅, 백업 용도, 재해 복구)로 사용

 

- 왜 복제를 사용하나?

• To keep your data safe
  • 데이터 안전하게 보관
• High (24*7) availability of data
  • 24시간 데이터 사용 가능 
• Disaster recovery
  • 재해 복구
• No downtime for maintenance (like backups, index rebuilds, compaction)
  • 유지 보수를 위한 다운타임 없음(백업, 인덱스 재구성, 압축)
• Read scaling (extra copies to read from)
  • 읽기 확장
• Replica set is transparent to the application
  • 애플리케이션에 레플리카 세트가 투명함

 

-the process of synchronizing data across multiple servers

-provides redundancy and increases data availability with multiple copies of data on different database servers

-protects a database from the loss of a single server. 

   =>fault tolerance

-allows you to recover from hardware failure and service interruptions.

 

몽고디비에서 Replica set 사용

• Replica set is a group of two or more nodes (generally minimum 3 nodes are required).

  • 2개 이상의 노드로 이루어진 그룹(최소 3개 노드 필요)

• In a replica set, one node is primary node and remaining nodes are secondary.

  • 한 노드는 기본 노드 , 나머지 노드는 보조 노드

• All data replicates from primary to secondary node.

  • 모든 데이터는 기본 노드에서 보조 노드로 복제

• At the time of automatic failover or maintenance, election establishes for primary and a new primary node is elected.

  • 자동 failover또는 유지 보수 시, 기본 노드에 대한 선택이 설정되고, 새로운 기본 노드가 선택

• After the recovery of failed node, it again join the replica set and works as a secondary node.

  • 실패한 노드를 복구한 후 , 다시 복제본 세트로 들어가 보조 노드로 작동

\

• replica set(복제 세트)
  
  • mongoDB에서 사용되는 복제 기술(과거 : 마스터 슬레이브)
  • 같은 데이터를 저장하고, 백업하기 위해 여러 대의 DB 서버가 운영되고, 각각의 서버에 유지하는 복수개의 Mongodb
    인스턴스가 모인 추상적인 그룹
  • 주 노드 1개 / 보조 노드 복수개 사용 가능 
  • A group of mongod instances that maintain the same data set
  • 구성 
    • nodes with data
      1. ONE PRIMARY NODE(DB를 공유시킬 서버(메인)):주노드
         • receives and does all write operations
         •  records all changes to its data sets in its operation log, i.e. oplog (capped collection)
         • 클라이언트 앱들의 쓰기 / 읽기 요청을 모두 받음 . 변화된 모든 내용을 운영 로그 (oplog)에 남김
      2. Secondary nodes(공유되는 DB받을서버(복제 / 백업 공간(여러대 가능)):보조노드
         • apply operations asynchronously using oplog from the primary so that they have the same data set
         • oplog에 기록된 내용들을 동일하게 연산하여 주 노드와 항상 같은 데이터 유지 
    • a node without data(optional)
      1. an arbiter node(PRIMARY / SECONDARY 서버를 모니터링 해주는 역할(끊어지는지 확인 가능)):결정권자
         • 결정권 자는 주 노드의 데이터를 복제하지 않는다 
         • 데이터가 없기 때문에, 주 노드가 될 수 없다
         • 역할 : heartbeat를 통해 노드의 상태를 확인하고 , 유사 시 선거에만 참가

arbiter(결정권자)

 

기본적인 Replica Set 구성

2.  주 노드의 교체 

   => 주 노드와 보조 노드 사이에 주기적으로 주고 받는 heartbeat(=ping/ 2s) 신호 통해 주 노드가 정상적이지 않은 상황 발견하면, 
        나머지 보조 노드들의 선거(election)을 통해 새로운 주 노드를 선발 
   => 원래 주 노드가 정상 상태로 돌아오면, 다시금 주 노드의 역할 맡게 된다 

   => replicate the primary’s oplog and apply the operations to their data sets such that the secondaries’ data sets reflect the primary’s data set

   =>  Replica set members send heartbeats (pings) to each other every 2 seconds. If a heartbeat does not return within 10 seconds, the other members mark the member as inaccessible.

• 주 노드 서버가 정상인 경우

주 노드 서버 정상

 

• 주 노드 서버가 정상 작동하지 않는 경우(primary node 대체 : automatic failover)

주 노드 서버가 정상 작동하지 않음

- 보조 노드들은 자신들의 상태, 미리 지정한 Priority  값을 판단하여 어떤 보조 노드가 주 노드로 승격될 것인지 선거

- 만약, 점수가 동일하게 나오면 가장 최근에 반영된 데이터를 반영한 보조 노드가 승격 대상

- 선거가 끝나기 전 까지 Read 수행은 보조 노드를 통해 가능하게 미리 설정(선거 시간 10초 넘기지 않는다)가능,
    Write는 주 노드가 없는 상태이므로 불가능

- 주 노드가 정상 상황 아닌 경우 실패한 write 연산을 retry 하는 기능 있음 

-  If the primary is unavailable, an eligible secondary will hold an election to elect itself the new primary node
    (기본 선거 시간 : 10초)

- The replica set cannot process write operations until the election completes successfully

- The replica set can continue to serve read queries if such queries are configured to run on secondaries while the primary is offline

 

 

3. Read 연산(read preference)

read preference

- 기본적, 응용 프로그램은 읽기 작업을 복제세트의 기본 구성원으로 보냄

   그러나, 클라이언트는 읽기 기본 설정을 지정하여 읽기 작업을 보조로 보낼 수 있다.

- secondary 에 대한 비동기식 복제는 secondary가 primary data 상태를 반영하지 않은 data를 반환한다

- By default, clients read from the primary;
   however, clients can specify a read preference to send read operations to secondaries.

- Asynchronous replication to secondaries means that reads from secondaries may return data that does not reflect the    state of the data on the primary.

 

4. 여러 데이터 센터에 Replica Set 분산

• 복수의 데이터 센터에 멤버들을 어떻게 분산?
  • 각 DB 노드들을 데이터 센터 분산에서는 멤버(member)로 호칭
  • 데이터 센터의 수를 홀수로 하면, 선거에서 동점이 나올 확률 줄일 수 있다.
  • 각 데이터 센터에는 최소한 1개의 멤버를 배포하는 것이 원칙
  • 주로 서비스를 수행할 데이터 센터와, 대체 운영 및 백업의 목적인 데이터 센터를 결정
  • 주 노드를 뽑는 선거는 모든 멤버 50% 이상의 과반수 득표를 해야 함
  • 과반수의 멤버를 특정 데이터 센터에 분산

 

- EX ) Replica Set 멤버가 5인 경우

Case 1) 2개의 데이터 센터

3개의 멤버는 데이터 센터 1에, 2개의 나머지 2개의 멤버는 데이터 센터 2에 분산한다.

- 만약 데이터 센터 1에 문제가 발생하면, replica set은 READ ONLY가 된다.

- 만약 데이터 센터 2에 문제가 발생하면, 데이터 센터 1의 멤버들의 수는 여전히 과반수가 넘으므로,

   replica set은 WRITE가 가능하다.

​

Case 2) 3개의 데이터 센터

2개의 멤버는 데이터 센터 1에, 2개의 나머지 2개의 멤버는 데이터 센터 2에, 1개의 멤버는 데이터 센터 3에 배포.

- 만약 어떤 데이터 센터에 문제가 발생하더라도, 나머지 데이터 센터의 멤버들이 선거가 가능한 상황이므로,
   replica set은 WRITE가 가능하다.

 

어느 데이터 센터가 문제가 생기더라도 주 노드의 유지가 가능한 멤버 분포

각 복제 멤버의 우선 순위 설정값을 통해, 주 노드로의 승격 가능성 조정

데이터 센터 수가 많을 수록 멤버들은 고루 분포되기 때문에, 선거 때 동점이 발생할 수 있고, 관리자가 사전에 특정 데이터 센터 내의 멤버들이 선거에서 주 노드로 선택될 확률을 더 많이 주고 싶을 수 있다.

   => 각 멤버 속성을 정의할 때, Priority  값을 미리 정의하여 조정할 수 있다.

 

- EX) Replica Set 멤버가 3인 경우

Case 1) 2개의 데이터 센터

두 개의 멤버는 데이터 센터 1에, 나머지 하나의 멤버는 데이터 센터 2에 둔다. 만약 결정권자(arbiter)를 둔다면, 멤버의 수가 더 많은 데이터 센터 1에 운영한다.

​

- 데이터 센터 1에 문제가 발생하면, 과반수의 멤버가 불능이 되어, 선거를 할 수 없는 상황이다. 데이터 센터 1이 정상적인 상태로 돌아올 때까지 replica set 자체는 READ ONLY 상태가 된다.

- 데이터 센터 2에 문제가 발생하면, 데이터 센터 1의 멤버들은 과반수이고 선거를 할 수 있으므로, 새로운 주 노드를 선임하여, replica set은 여전히 WRITE가 가능하다.

​

위와 같이, 데이터 센터 2개의 경우, WRITE가 불가능한 상황이 발생할 수 있기 때문에, 데이터 센터의 수는 최소 3개 이상으로 하는 것이 안전하다.

​

Case 2) 3개의 데이터 센터

각각의 데이터 센터에는 멤버가 1개씩 존재하는 구조가 된다.

- 데이터 센터 1,2, 3 어디든 문제가 발생하면, 나머지 2개의 멤버들은 선거를 통해 새로운 주 노드를 찾을 것이고, replica set은 여전히 WRITE가 가능하다.

​

Case 3) 5개의 데이터 센터

각각의 데이터 센터에는 멤버가 1개씩 존재하는 구조가 된다.

replica set 멤버 3 / 활용 연습 도식화

[1단계] 3개 멤버 노드에 대한 데이터 폴더 생성

• c:\data\node1

• c:\data\node2

• c:\data\arbiter

 

[2단계] 3개의 명령창에서 mongod 인스턴스를 각각 실행

• replSet 옵션 : 복제 세트 이름 지정

• bind_ip_all 옵션 : 3대의 컴퓨터 사용시 (local 연습 시에는 불필요)

#1 => c:\> mongod -–port 27111 -–dbpath c:\data\node1 -–replSet myrs -–oplogSize 256

#2  => c:\> mongod -–port 27112 -–dbpath c:\data\node2 -–replSet myrs -–oplogSize 256

#3  => c:\> mongod -–port 27113 -–dbpath c:\data\arbiter -–replSet myrs -–oplogSize 256

 

[3단계] 4번째 명령창에 mongo 쉘로 첫 번째 인스턴스에 접속

#4  => c:\> mongo -–port 27111 . . . >

 

[4단계] 4번째 명령창에서 Replica set 환경 설정 문서를 변수 conf에 저장(여기서, 첫 번째 인스턴스만 멤버로 설정)

#4  => > conf = {_id:”myrs”, members:[{_id:0, host:”localhost:27111”}]} //실제 IP 입력

 

[5단계] 4번째 명령창에서 Replica Set 초기화

#4 = > > rs.initiate(conf) // 복제 세트 초기화

                 . . . .

                 myrs:SECONDARY>

                myrs:PRIMARY>

 

• 출력된 실행 결과 (“ok”:1) 메시지 확인

• 잠시 대기 후 프롬프트 기호 변화 확인

 ->  27111 포트에서 수행 중인 mongod 인스턴스가 프라이머리 노드가 됨

 

[6단계] 4번째 명령창에서 나머지 두 인스턴스를 Replica Set에 추가 후 프롬포트 기호 변경 및 복제 상태 확인(brief summary)

#4  => myrs:PRIMARY> rs.add(“localhost:27112”)

             myrs:PRIMARY> rs.add(“localhost:27113”, {arbiterOnly:true}) 또는

                                             rs.addArb(“localhost:27113”)

            myrs:PRIMARY>

            myrs:PRIMARY> db.isMaster() // 상세 정보 보기는 rs.status() 사용

 

[7단계] 5 또는 6 번째 명령창에 mongo 쉘로 위 인스턴스 중 하나에 접속하여 세컨터리 및 아비터 노드임 확인

#5 => c:\> mongo -–port 27112

            . . .

            myrs:SECONDARY>

 

#6 =>  c:\> mongo -–port 27113

            . . .

           myrs:ARBITER>

 

• 프롬프트 기호 확인(세컨더리 멤버, 아비터 멤버)

[8단계] 4 또는 5번째 명령창에서 Replica Set 용 db 및 컬렉션 확인

# 4 => myrs:PRIMARY> use local // Replica Set 용 db 선택

             myrs:PRIMARY> db.getCollectionNames() // 또는 show Collections

 

[9단계] 4 또는 5번째 명령창에서 Replica Set 멤버 및 멤버 정보 확인

#4 => myrs:PRIMARY> db.system.replset.find().pretty()

 

[10단계] 4 또는 5번째 명령창에서 Replica Set 상태 자세히 확인

#4  => myrs:PRIMARY> rs.status()

 

[11단계] 4번째 명령창 (프라이머리 멤버) 에서 문서 삽입

#4  => myrs:PRIMARY> use sample

              myrs:PRIMARY> db.col.insert({uname:”kim”, age:19})

              myrs:PRIMARY> db.col.find().pretty() 

 

[12단계] 5번째 명령창(세컨더리 멤버) 에서 문서 검색

#5  => myrs:SECONDAY> rs.status()

             myrs:SECONDAY> rs.slaveOk() // 세컨더리 노드에서도 검색 허용

             myrs:SECONDAY> use sample

             myrs:SECONDAY> show collections

             myrs:SECONDAY> db.col.find().pretty()

 

[13단계] 4번째 명령창에서 프라이머리 mongod 멤버 셧다운

• 2 및 3번째 명령창(나머지 두 인스턴스 실행 중)에 출력되는 메시지 확인

#4  => myrs:PRIMARY> use admin

             myrs:PRIMARY> db.shutdownServer()

              . . .

             c:>

 

[14단계] 5번째 명령창(세컨더리 멤버)에서 멤버 상태 재확인

• 이전 프라이머리 및 새로운 프라이머리 확인

#5 => myrs:SECONDAY> rs.status()

           . . .

          myrs:PRIMARY> // 프롬프트 기호가 변화된 것에 주목

 

[15단계]5 번째 명령창(새로운 프라이머리)에서 새로운 문서 삽입

#5 => myrs:PRIMARY> db.col.insert({uname:”cho”, age:23})

           myrs:PRIMARY> db.col.find().pretty() 

 

[16단계] 1번째 창에서 명령창에서 첫 번째 mongod 인스턴스 재실행

#1  => c:\> mongod -–port 27111 -–dbpath c:\data\node1 -–replSet myrs -–oplogSize 256

 

[17단계] 4번째 창에서 mongod 쉘로 위 첫번째 인스턴스에 재접속

#4  => c:\> mongo -–port 27111

              . . .

              myrs:SECONDARY> // 프롬프트 기호 변화 주목

              myrs:SECONDARY> rs.status()

              myrs:SECONDARY> rs.slaveOk()

              myrs:SECONDARY> use sample

              myrs:SECONDARY> show collections

              myrs:SECONDARY> db.col.find().pretty()

 

[17단계] 4 -> 6 -> 5번째 명령창 (mongo쉘) 에서 각 mongod 인스턴스 셧다운

#4   => myrs:SECONDARY> use admin

              myrs:SECONDARY> db.shutdownServer()

              . . .

              > exit

 

#6    => myrs:ARBITER> use admin

               myrs:ARBITER> db.shutdownServer()

                . . .

                > exit

 

#5    => myrs:PRIMARY> myrs:SECONDARY> // 프롬프트 기호 변화 주목

               myrs:SECONDARY> use admin

               myrs:SECONDARY> db.shutdownServer()

              . . .

               > exit