위키원
"기본노드"의 두 판 사이의 차이
| 1번째 줄: | 1번째 줄: | ||
| − | '''프라이머리 노드'''(Primary Node)<!--프라이머리노드, Primary Node, PrimaryNode, 주 노드, 기본노드, 주노드, 기본 노드-->는 응용 프로그램이 실행되는 노드이며, 여기서 보조 노드로 데이터가 복제된다. | + | '''프라이머리 노드'''(Primary Node)<!--프라이머리노드, Primary Node, PrimaryNode, 주 노드, 기본노드, 주노드, 기본 노드-->는 응용 프로그램이 실행되는 노드이며, 여기서 보조 노드로 데이터가 복제된다. '''기본 노드''', '''주 노드'''로 불리기도 한다. |
==개요== | ==개요== | ||
프라이머리 노드는 기본 서버의 구성 중 하나이다. 시스템 장애로 인해 다른 서버로 전환해야 할 때까지 이 서버에서 처리가 수행된다. 로컬 노드라고도 불린다. 프라이머리 상태는 일시적이고 동적이므로, 특정 머신에 고정되어 있지 않다.<ref>〈[http://qsupport.quantum.com/kb/flare/Content/stornext/SN5_DocSite/Guide_Users/Topics/Primary_Node.htm Primary Node]〉, 《StorNext 5》</ref> | 프라이머리 노드는 기본 서버의 구성 중 하나이다. 시스템 장애로 인해 다른 서버로 전환해야 할 때까지 이 서버에서 처리가 수행된다. 로컬 노드라고도 불린다. 프라이머리 상태는 일시적이고 동적이므로, 특정 머신에 고정되어 있지 않다.<ref>〈[http://qsupport.quantum.com/kb/flare/Content/stornext/SN5_DocSite/Guide_Users/Topics/Primary_Node.htm Primary Node]〉, 《StorNext 5》</ref> | ||
| + | |||
| + | ==몽고디비== | ||
| + | 몽고디비(MongoDB)에서는 마스터-슬레이브 복제와 레플리카 셋 복제라고 하는 두 가지 방식의 복제를 지원한다. 마스터-슬레이브 복제는 몽고디비가 만들어졌던 초기에 사용하던 복제 방식으로, 몽고디비3.2 버전에서는 권장하지 않는 방식이다. 또한 마스터-슬레이브 복제 방식은 마스터의 장애에 대한 페일오버를 관리자가 수동으로 처리해야 하며, 최근 버전의 몽고디비에서는 거의 기능이 개선되거나 보완되지 않고 있다. 그에 반해서 레플리카 셋 복제는 안정되고 많은 부분 자동화되어 처리될 수 있게 개발됐다. | ||
| + | |||
| + | * '''복제''' | ||
| + | : 복제는 여러 서버가 서로의 데이터를 동기화하는 것을 의미하는데, 서로 주고받는 데이터에 따라서 논리 복제와 물리 복제로 나눌 수 있다. DRBD(Distributed Replicated Block Device)와 같이 리눅스 서버가 데이터의 내부를 전혀 모르는 상태에서 디스크의 블록만 복제하는 형태를 물리적 복제라고 한다. 그리고 MySQL 서버나 MongoDB 서버와 같이 데이터베이스 서버가 직접 서버간의 데이터를 동기화하는 방식을 논리적 복제라고 한다. 물리적 복제는 데이터베이스가 전혀 관여하지 않으므로 운영체제 차원에서 응용 프로그램에 투명하게 복제를 처리할 수 있지만, 응용 프로그램의 캐시나 내부 처리 로직에서 변경된 데이터를 사용하지 못하는 문제점도 있다. 몽고디비는 MySQL 서버의 복제와 아주 비슷하게 논리적 복제 수단을 가지고 있으며, 더불어 프라이머리 노드의 선출과 네트워크 단절로 인한 스플릿 브레인(Split-Brain) 현상을 막을 수 있는 기능까지 내장하고 있다. | ||
| + | |||
| + | 복제의 가장 큰 목적은 동일한 데이터를 이중 삼중으로 유지함으로써 레플리카 셋의 특정 멤버에서 데이터 손실이 발생하더라도 다른 멤버의 데이터로 대체할 수 있도록 하기 위함이다. 즉 고가용성(High-Availability)을 위해서 중복된 데이터 셋을 준비하는 것이다. 고가용성을 위해서 몽고디비 레플리카 셋의 각 멤버는 서로 다른 멤버가 살아있는지 계속 확인하는 하트비트 메시지를 주고 받는다. 만약 프라이머리 노드와 통신되지 않으면 새로운 프라이머리 노드를 선출해 서비스가 계속 지속되도록 한다. 복제의 또 다른 목적으로는 데이터조회 쿼리의 로드 분산을 생각할 수 있다. 몽고디비에서 데이터의 변경은 프라이머리 노드에서 시작되지만, 각 세컨드리 노드는 데이터변경은 하지 못하지만 조회쿼리의 요청은 받을 수 있다. 즉, 읽기 성능을 높히기 위해 세컨드리 노드를 확장해서 사용하기도 한다. | ||
| + | |||
| + | * '''컨센서스 알고리즘'''(Consensus Algorithm) | ||
| + | : 켄센서스 알고리즘은 크게 Paxos와 Raft 컨센서스 알고리즘이 있다. Raft 켄센서스 알고리즘의 가장 큰 특징은 리더 기반의 복제와 각 멤버 노드가 상태를 가진다는 것이다. 하나의 레플리카 셋에는 반드시 하나의 리더만 존재할 수 있고, 리더는 사용자의 모든 데이터 변경 요청을 처리한다. 그리고 리더는 사용자의 요청 내용(데이터 변경)을 로그에 기록하고, 모든 팔로워는 리더의 로그를 가져와서 동기화를 수행한다. Raft 켄센서스 알고리즘의 리더를 몽고디비에서는 프라이머리 노드라고 하고 팔로워는 세컨드리 노드라고 한다. 그리고 로그를 몽고디비에서는 OpLog(Operation Log)라고 한다.<ref>코딩초보 여성게, 〈[https://coding-start.tistory.com/m/274?category=815805 DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)]〉, 《티스토리》, 2019-09-12</ref> | ||
{{각주}} | {{각주}} | ||
| 9번째 줄: | 20번째 줄: | ||
* 〈[https://kr.norton.com/security_response/glossary/define.jsp?letter=p&word=primary-node Primary node : 주 노드]〉, 《Norton》 | * 〈[https://kr.norton.com/security_response/glossary/define.jsp?letter=p&word=primary-node Primary node : 주 노드]〉, 《Norton》 | ||
* 〈[http://qsupport.quantum.com/kb/flare/Content/stornext/SN5_DocSite/Guide_Users/Topics/Primary_Node.htm Primary Node]〉, 《StorNext 5》 | * 〈[http://qsupport.quantum.com/kb/flare/Content/stornext/SN5_DocSite/Guide_Users/Topics/Primary_Node.htm Primary Node]〉, 《StorNext 5》 | ||
| + | * 코딩초보 여성게, 〈[https://coding-start.tistory.com/m/274?category=815805 DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)]〉, 《티스토리》, 2019-09-12 | ||
==같이 보기== | ==같이 보기== | ||
| + | * [[몽고디비]] | ||
| + | * [[컨센서스 알고리즘]] | ||
| + | * [[보조 노드]] | ||
{{블록체인 기술|검토 필요}} | {{블록체인 기술|검토 필요}} | ||
2019년 10월 17일 (목) 14:59 판
프라이머리 노드(Primary Node)는 응용 프로그램이 실행되는 노드이며, 여기서 보조 노드로 데이터가 복제된다. 기본 노드, 주 노드로 불리기도 한다.
개요
프라이머리 노드는 기본 서버의 구성 중 하나이다. 시스템 장애로 인해 다른 서버로 전환해야 할 때까지 이 서버에서 처리가 수행된다. 로컬 노드라고도 불린다. 프라이머리 상태는 일시적이고 동적이므로, 특정 머신에 고정되어 있지 않다.[1]
몽고디비
몽고디비(MongoDB)에서는 마스터-슬레이브 복제와 레플리카 셋 복제라고 하는 두 가지 방식의 복제를 지원한다. 마스터-슬레이브 복제는 몽고디비가 만들어졌던 초기에 사용하던 복제 방식으로, 몽고디비3.2 버전에서는 권장하지 않는 방식이다. 또한 마스터-슬레이브 복제 방식은 마스터의 장애에 대한 페일오버를 관리자가 수동으로 처리해야 하며, 최근 버전의 몽고디비에서는 거의 기능이 개선되거나 보완되지 않고 있다. 그에 반해서 레플리카 셋 복제는 안정되고 많은 부분 자동화되어 처리될 수 있게 개발됐다.
- 복제
- 복제는 여러 서버가 서로의 데이터를 동기화하는 것을 의미하는데, 서로 주고받는 데이터에 따라서 논리 복제와 물리 복제로 나눌 수 있다. DRBD(Distributed Replicated Block Device)와 같이 리눅스 서버가 데이터의 내부를 전혀 모르는 상태에서 디스크의 블록만 복제하는 형태를 물리적 복제라고 한다. 그리고 MySQL 서버나 MongoDB 서버와 같이 데이터베이스 서버가 직접 서버간의 데이터를 동기화하는 방식을 논리적 복제라고 한다. 물리적 복제는 데이터베이스가 전혀 관여하지 않으므로 운영체제 차원에서 응용 프로그램에 투명하게 복제를 처리할 수 있지만, 응용 프로그램의 캐시나 내부 처리 로직에서 변경된 데이터를 사용하지 못하는 문제점도 있다. 몽고디비는 MySQL 서버의 복제와 아주 비슷하게 논리적 복제 수단을 가지고 있으며, 더불어 프라이머리 노드의 선출과 네트워크 단절로 인한 스플릿 브레인(Split-Brain) 현상을 막을 수 있는 기능까지 내장하고 있다.
복제의 가장 큰 목적은 동일한 데이터를 이중 삼중으로 유지함으로써 레플리카 셋의 특정 멤버에서 데이터 손실이 발생하더라도 다른 멤버의 데이터로 대체할 수 있도록 하기 위함이다. 즉 고가용성(High-Availability)을 위해서 중복된 데이터 셋을 준비하는 것이다. 고가용성을 위해서 몽고디비 레플리카 셋의 각 멤버는 서로 다른 멤버가 살아있는지 계속 확인하는 하트비트 메시지를 주고 받는다. 만약 프라이머리 노드와 통신되지 않으면 새로운 프라이머리 노드를 선출해 서비스가 계속 지속되도록 한다. 복제의 또 다른 목적으로는 데이터조회 쿼리의 로드 분산을 생각할 수 있다. 몽고디비에서 데이터의 변경은 프라이머리 노드에서 시작되지만, 각 세컨드리 노드는 데이터변경은 하지 못하지만 조회쿼리의 요청은 받을 수 있다. 즉, 읽기 성능을 높히기 위해 세컨드리 노드를 확장해서 사용하기도 한다.
- 컨센서스 알고리즘(Consensus Algorithm)
- 켄센서스 알고리즘은 크게 Paxos와 Raft 컨센서스 알고리즘이 있다. Raft 켄센서스 알고리즘의 가장 큰 특징은 리더 기반의 복제와 각 멤버 노드가 상태를 가진다는 것이다. 하나의 레플리카 셋에는 반드시 하나의 리더만 존재할 수 있고, 리더는 사용자의 모든 데이터 변경 요청을 처리한다. 그리고 리더는 사용자의 요청 내용(데이터 변경)을 로그에 기록하고, 모든 팔로워는 리더의 로그를 가져와서 동기화를 수행한다. Raft 켄센서스 알고리즘의 리더를 몽고디비에서는 프라이머리 노드라고 하고 팔로워는 세컨드리 노드라고 한다. 그리고 로그를 몽고디비에서는 OpLog(Operation Log)라고 한다.[2]
각주
- ↑ 〈Primary Node〉, 《StorNext 5》
- ↑ 코딩초보 여성게, 〈DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)〉, 《티스토리》, 2019-09-12
참고자료
- 〈Primary node : 주 노드〉, 《Norton》
- 〈Primary Node〉, 《StorNext 5》
- 코딩초보 여성게, 〈DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)〉, 《티스토리》, 2019-09-12
같이 보기
