# replica set

khim89

MySQL이나 oracle만 쓰다가 MongoDB로 백엔드를 만들어보면서 해당 환경을 구축하게 되었다. 처음에는 그냥 로컬용 디비는 docker로 하나만 올려서 사용하고 있었는데, 로직이 길어지면서 트랜잭션처리를 할 필요가 생겼는데 그 순간... 이런 에러메세지를 발견했다. 말그대로 트랜잭션을 쓰려면 레플리카 셋을 구현해야 해서 docker로 만들어 보았다. 1. 디비 생성 기존에 하나만 사용하던 디비를 우선 3개를 생성해 준다. 간편하게 생성하고 관리하기 위헤서 docker-compose를 사용하기로 한다 ` 위의 파일을 간단하게 살명하면 docker의 mongo이미지로 mongodb1, mongodb2, mongodb3 이렇게 3개의 몽고디비를 생성한다. 해당 파일을 실행시켜준다. 이렇게 실행하면 도커가 실행된다. 2. 레플리카 설정 실행된 도커인스턴스에 접근한다. docker ps > docker exec -it ${conta

this_summer

로컬에 Replica-set 을 구축하는 방법, Sharded Cluster 배포하는 방법을 알 수 있습니다. 구축 환경 Mac OS 설치 MongoDB Community Server Download MongoDB Shell Download 다운로드 이후, 작업할 디렉토리 생성 ~/mongodb-folder 로 압축을 풀어줍니다. mongodb 실행 Terminal 3개를 열어서 각각 실행합니다. > 각 mongodb server 는 port 27017, 27018, 27019 로 실행되며, 각 데이터베이스 데이터 저장 디렉토리는 data1, data2, data3 로 지정합니다.

naeson

Kubernetes 워크로드 리소스 (= 컨트롤러) 컨트롤러중 디플로이먼트와 스테이트풀셋은 추후 다룰 예정이고, 두개를 제외한 나머지 컨트롤러는 이번 장에서 다룰것이다. replication controller ReplicaSet을 구성하는 Deployment가 현재 권장하는 레플리케이션 설정 방법이다. ReplicaSet과 같은 기능을 가지고 있으며, rc는 조만간 사라질 기술이다. 레플리케이션컨트롤러는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다 = 선언형의 특징, 선언한 개수를 항상 유지한다 kubectl get rc # 생성한 레플리케이션 컨트롤러(=rc) 보기 kubectl explain rc # rc에 들어가는 항목 확인 kubectl get pods --sh

solsol38

구조 1. Primary 클라이언트에서 DB로 읽기 및 쓰기 작업을 한다. 2. Secondary 프라이머리로부터 데이터를 동기화 한다. 3. Arbiter 데이터를 동기화하지는 않으며 레플리카 셋의 복구를 돕는 역할을 한다. 동작 과정 Slave → Master: QueryOption_AwaitData 질의 요청 옵션으로 자신의 optime(마지막 oplog 수행시간)보다 큰 oplog를 달라고 요청(5초 주기) Master → Slave :쓰기 연산 발생 시, 즉시 데이터 응답/ 6초안에 미발생시 데이터 존재하지않는다는 응답 Slave: 요구한 Oplog의 데이터가 존재하면 자신의 Oplog에 데이터를 저장하고 다시 1번 과정

anjinwoong

Pod 컨테이너 애플리케이션의 기본 단위 1개 이상의 컨테이너로 구성된 컨테이너의 집합 같은 pod 내 컨테이너들은 네임스페이스를 공유한다. yml 파일을 통해 pod 생성, 삭제 등 가능 apiVersion : 오브젝트 API 버전 kind : 리소스 종류. pod 일 경우 Pod metadata : name 등 리소스 메타데이터 metadata.name 은 고유해야한다. spec : 리소스 생성을 위한 상세 정보 image (컨테이너 이미지), ports 등 Replica Set 일정 개수의 pod 를 유지하는 컨트롤러 정해진 수의 동일한 pod 가 항상 실행되도록 관리 노드에서 pod 사용 불가시 다른 노드에서 pod 다시 생성 노드를 직접 관리하는 대신 replica set을 통해 관리 kind 값이 `Replic

youngeui_hong

👯‍♀️ Replica Set이란? MongoDB의 Replica Set은 동일한 데이터셋을 가지고 있는 mongod 프로세스 그룹을 의미합니다. Replica Set은 Primary 노드와 Secondary 노드로 구성되는데, Secondary 노드는 Primary 노드 데이터의 복사본을 가지고 있습니다. 🤔 왜 Replica Set을 사용해야 할까? 🔻fault-tolerance한 시스템 구축을 위해 만약 하나의 노드에 문제가 발생하면 그 노드가 복구될 때까지 다른 노드가 작업을 수행하면 되므로 시스템 장애에 좀 더 유연하게 대처할 수 있습니다. 🔻Transaction 처리를 위해 MongoDB의 Transaction 작업은 Replica Se

squarebird

Replica Set과 Deployment 이전글에서 Kubernetes의 기본 오브젝트 4개에 대해서 정리했습니다. Kubernetes는 4개의 기본 오브젝트에 여러가지 기능을 추가하여 더 효율적으로 사용할 수 있는 오브젝트들을 추가했습니다. 오늘은 그 중에서 가장 많이 사용되는 오브젝트들인 Replica Set과 Deployment에 대해 알아보겠습니다. 쿠버네티스는 어떻게 Pod의 개수를 보장할까? Kubernetes 시리즈의 글을 처음 작성할 때, Kubernetes에 대해서 >"컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 시스템" 이라고 정의했습니다. 그럼 Kubernetes는 어떻게 배포할 Container를 선택하고, 갯수를 선택하고 Deploy와 Scaling까지 관리해 주는걸까요

ynsoo1225

❓레플리카셋을 사용하는 이유 마이크로서비스에서는 여러 개의 동일한 컨테이너를 생성한 뒤 외부 요청이 각 컨테이너에 적절해 분배될 수 있어야 한다. 쿠버네티스에서는 동일한 여러 개의 포드를 생성해 외부 요청을 각 포드에 분배하는 방식을 사용해야 한다. 그러나 여러 개의 포드를 직접 생성하는 방법은 매우 비효율적이며, 관리가 어렵다. 이러한 한계점을 해결해주기 위해 사용하는 것이 바로 레플리카셋이다. 레플리카셋의 역할 정해진 수의 동일한 포드가 항상 실행되도록 관리 노드 장애 등의 이유로 포드를 사용할 수 없다면 다른 노드에서 포드를 다시 생성 🦕 레플리카셋 사용하기 `replicaset-ngi

kineo2k

ReplicaSet은 MongoDB의 고가용성$$^{High\ availability}$$ 시스템으로 동일한 데이터를 갖는 mongod 프로세스들의 그룹으로 구성됩니다. 이는 1개의 Primary 멤버와 데이터 복사본을 갖는 다수의 Secondary 멤버들로 이루어집니다. 최근 공인 IP로 운영 중인 ReplicaSet을 사설 IP로 변경하는 업무를 진행했습니다. MongoDB를 Standalone하게 운영할 경우에는 문제가되지 않지만, ReplicaSet으로 운영할 경우에는 아래의 방법

rosewwross

현재 인턴중인 회사에서 mongodb에 접속할때, ip와 port주소가 두개 설정되어 있어서 그 이유를 techlead 에게 물어봤더니, db architecture에 관해서 자세하게 설명해 주셔서 그 내용을 정리해 본다. Standalone 서버가 오직 하나의 db와 연결되어 있는 구조 Replica Set 서버가 여러개의 replica db와 연결되어 있는 구조. replica는 복제라는 뜻이므로, primary db의 정보가 복제되어 secondary db에 저장되므로, 이들은 모두 같은 정보를 담고 있다. 이 구조를 사용하는 이유는 크게 두가지이다. 1) db 인스턴스의 프로세스가 down되는 상황을 고려하여 Single Point of Failure(SPOF)