지리적으로 중복된 자체 관리 복제본 세트 배포
개요
이 튜토리얼은 여러 위치에 멤버가 있는 복제본 세트를 배포하는 과정을 설명합니다. 이 튜토리얼에서는 세 멤버가 있는 복제본 세트와 다섯 멤버가 있는 복제본 세트에 대해 설명합니다. 복제 세트 멤버 수가 짝수인 경우 가능하면 다른 데이터 보유 멤버를 추가하여 투표 멤버 수를 홀수로 배포하세요. [1]
분산된 복제본 세트에 대한 자세한 내용은 둘 이상의 데이터 센터에 분산된 복제본 세트를 참조하세요. 복제본 세트 배포 아키텍처 및 자체 관리형 복제 참조를 확인하세요.
| [1] | (1, 2) 사정이 있어 다른 데이터 보유 멤버를 추가할 수 없고 투표권이 있는 멤버 수가 짝수인 경우 대신 중재자를 추가할 수 있습니다. 중재자를 사용할 때 고려해야 할 사항은 복제본 세트 중재자를 참조하세요. |
고려 사항
아키텍처
프로덕션 환경에서는 복제본 세트의 각 멤버를 자체 시스템에 배포합니다. 가능하면 MongoDB가 기본 포트인 27017에서 수신 대기하는지 확인하세요.
자세한 내용은 복제 세트 배포 아키텍처를참조하세요.
호스트 이름
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
IP 바인딩
--bind_ip 2} 옵션을 사용하여 MongoDB가 구성된 주소의 애플리케이션에서 연결을 수신 대기하도록 합니다.
경고
인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.
2} 및mongod MongoDB mongos 바이너리는 기본적으로 로컬 호스트에 바인딩됩니다. 바이너리에 대해 net.ipv6 구성 파일 설정 또는 --ipv6 명령줄 옵션이 설정되어 있으면 바이너리가 로컬 호스트 IPv6 주소에 추가적으로 바인딩됩니다.
기본적으로 localhost에 바인딩된 mongod 및 mongos는 동일한 컴퓨터에서 실행 중인 클라이언트의 연결만 허용합니다. 이 바인딩 동작에는 mongosh와 복제본 세트 또는 샤딩된 클러스터의 다른 노드가 포함됩니다. 원격 클라이언트는 localhost에만 바인딩된 바이너리에는 연결할 수 없습니다.
기본 바인딩을 재정의하고 다른 IP 주소에 바인딩하려면 net.bindIp 구성 파일 설정 또는 --bind_ip 명령줄 옵션을 사용하여 호스트 이름 또는 IP 주소 목록을 지정합니다.
경고
MongDB 부터 5.0 시작, 분할 수평 DNS IP 주소로만 구성된 노드는 시작 유효성 검사에 실패하고 오류를 보고합니다. disableSplitHorizonIPCheck 를 참조하세요.
예를 들어 다음 mongod 인스턴스는 로컬 호스트와 IP 주소 198.51.100.1 와 연결된 호스트명 My-Example-Associated-Hostname에 모두 바인딩됩니다.
mongod --bind_ip localhost,My-Example-Associated-Hostname
이 인스턴스에 연결하려면 원격 클라이언트가 호스트 이름 또는 관련 IP 주소 198.51.100.1를 지정해야 합니다.
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
연결성
네트워크 트래픽이 세트의 모든 구성원과 네트워크의 모든 클라이언트 간에 안전하게 전달될 수 있는지 확인하십시오.
다음 사항을 고려하세요:
가상 사설망을 설정합니다. 네트워크 토폴로지가 LAN을 통해 단일 사이트 내의 구성원 간 모든 트래픽을 라우팅하는지 확인하십시오.
알 수 없는 클라이언트에서 복제본 세트로의 연결을 방지하도록 액세스 제어를 구성합니다.
수신 및 발신 패킷이 기본 MongoDB 포트에서만 허용되고 배포 내에서만 허용되도록 네트워킹 및 방화벽 규칙을 구성합니다. IP 바인딩 고려 사항을 참조하세요.
복제본 세트의 각 구성원이 확인 가능한 DNS 또는 호스트 이름을 통해 액세스할 수 있는지 확인합니다. DNS 이름을 적절하게 구성하거나 시스템의 /etc/hosts 파일을 설정하여 이 구성을 반영해야 합니다.
각 멤버는 다른 모든 멤버와 연결할 수 있어야 합니다. 연결을 확인하는 방법에 대한 지침은 모든 구성원 간의 연결 테스트를 참조하십시오.
구성
MongoDB를 배포하기 전에 MongoDB가 데이터 파일을 저장하는 디렉터리를 만드세요.
5} 또는 관련 위치에 mongod 저장된 구성 파일에서 구성을 지정합니다./etc/mongod.conf
구성 옵션에 대한 자세한 내용은 자체 관리 구성 파일 옵션을 참조하세요.
회원 분포
가능하면 홀수 개의 데이터 센터를 사용하고, 데이터 센터가 손실되더라도 나머지 복제본 세트 멤버가 과반수를 구성하거나 최소한 데이터 사본을 제공할 수 있는 가능성을 극대화하는 멤버 분포를 선택합니다.
투표권이 있는 회원
투표권을 가진 멤버를 7개 이상 배포하지 않습니다.
전제 조건
이 튜토리얼의 모든 구성에 대해 각 복제본 세트 멤버를 별도의 시스템에 배포합니다. 단일 시스템에 둘 이상의 복제본 세트 멤버를 배포할 수 있지만 이 경우 복제본 세트의 중복성과 용량이 줄어듭니다. 이러한 배포는 일반적으로 테스트 목적으로 이루어집니다.
이 튜토리얼에서는 복제본 세트의 일부가 될 각 시스템에 MongoDB를 설치했다고 가정합니다. MongoDB를 아직 설치하지 않은 경우 설치 튜토리얼을 참조하세요.
절차
지리적으로 중복된 3개 멤버 복제본 세트 배포
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
지리적으로 중복된 3개 멤버 복제본 세트 배포의 경우 시스템 배포 방법을 결정해야 합니다. 세 멤버에 대한 몇 가지 가능한 분포는 다음과 같습니다:
세 데이터 센터에 분포: 각 사이트당 한 개의 멤버 배치.
두 데이터 센터에 분포: 2개 멤버를 A 데이터 센터에, 1개 멤버를 B 데이터 센터에 배치합니다. 복제본 세트의 구성원 중 한 개가 중재자([1])인 경우, 중재자를 데이터 보유 구성원과 함께 데이터 센터 A에 배포합니다.
참고
두 개의 데이터 센터에 복제본 세트 구성원을 분산하면 단일 데이터 센터에 비해 이점이 있습니다. 두 개의 데이터 센터로 분산된 경우,
데이터 센터 중 하나가 다운되더라도 단일 데이터 센터 배포판과 달리 데이터를 읽을 수 있습니다.
소수의 구성원이 있는 데이터 센터가 다운되더라도 복제본 세트는 읽기 작업뿐만 아니라 쓰기 작업도 계속 수행할 수 있습니다.
그러나 대다수의 구성원이 있는 데이터 센터가 다운되면 복제본 세트는 읽기 전용이 됩니다.
가능하다면 최소 3개 이상의 데이터 센터에 구성원을 배포하세요. 구성 서버 복제본 세트(CSRS)의 경우 가장 좋은 방법은 3개(또는 구성원 수에 따라 그 이상) 센터에 배포하는 것입니다. 세 번째 데이터 센터의 비용이 부담스러운 경우, 회사 정책이 허용하는 경우 데이터 보유 멤버를 두 데이터 센터에 균등하게 분산하고 나머지 멤버는 클라우드에 저장하는 것도 한 가지 방법입니다.
적절한 옵션을 사용하여 복제 세트의 각 구성원을 시작하십시오.
각 멤버에 대해 다음 설정을 사용하여 mongod 인스턴스를 시작합니다.
복제본 세트 이름에
replication.replSetName옵션을 설정합니다. 애플리케이션이 2개 이상의 복제본 세트에 연결된 경우 각 세트의 이름이 달라야 합니다.net.bindIp2} 옵션을 호스트 이름/IP 또는 쉼표로 구분된 호스트 이름/IP 목록으로 설정합니다.다른 설정은 배포에 맞게 적절하게 설정합니다.
이 자습서에서는 세 개의 mongod 인스턴스가 다음 호스트와 연결됩니다.
복제본 세트 멤버 | 호스트 이름 |
|---|---|
회원 0 | mongodb0.example.net |
회원 1 | mongodb1.example.net |
멤버 2 | mongodb2.example.net |
다음 예에서는 --replSet 및 --bind_ip 명령줄 옵션을 통해 복제본 세트 이름과 IP 바인딩을 지정합니다.
경고
인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
0}의 <hostname(s)|ip address(es)> 경우 원격 클라이언트(복제본 집합의 다른 구성원 포함)가 인스턴스에 연결하는 데 사용할 수 있는 인스턴스의 호스트 mongod 이름 및/또는 IP 주소를 지정합니다.
또는 구성 파일에서 replica set name ip addresses와 를 지정할 수도 있습니다.
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
구성 파일로 mongod을 시작하려면 --config 옵션으로 구성 파일의 경로를 지정합니다.
mongod --config <path-to-config>
프로덕션 배포에서는 이 프로세스를 관리하도록 초기화 스크립트를 구성할 수 있습니다. 초기화 스크립트는 이 문서의 범위를 벗어납니다.
복제본 세트를 시작합니다.
mongosh에서 복제본 세트 멤버 0에 대해 rs.initiate()를 실행합니다.
중요
rs.initiate()를 복제본 세트의 단일 mongod 인스턴스에서만 실행합니다.
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" } ] })
MongoDB는 기본 복제본 세트 구성을 사용하여 복제본 세트를 시작합니다.
복제본 세트 구성을 확인합니다.
rs.conf() 2}를 사용하여 복제본 세트 구성 객체를 표시합니다.
rs.conf()
복제본 세트 구성 객체는 다음과 유사합니다.
{ "_id" : "rs0", "version" : 1, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("585ab9df685f726db2c6a840") } }
선택 사항. 프라이머리가 되기 위한 멤버 자격을 구성합니다.
경우에 따라 한 데이터 센터의 노드가 다른 데이터 센터의 노드보다 먼저 프라이머리 노드로 선출되는 것을 선호할 수 있습니다. 한 데이터 센터의 멤버가 다른 데이터 센터의 멤버보다 더 높은 priority를 가지도록 멤버의 priority를 수정할 수 있습니다.
네트워킹 제한이 있거나 리소스가 제한된 구성원 등 복제본 세트의 일부 구성원은 장애 조치 시 기본 구성원이 될 수 없습니다. 기본이 되어서는 안 되는 구성원의 우선 순위가 0이 되도록 구성합니다.
예를 들어 사이트 중 하나에 있는 멤버의 상대적 자격을 낮추려면(이 예에서는 mongodb2.example.net) 멤버의 우선 순위를 0.5로 설정합니다.
복제본 세트 구성을 보고 멤버의
members배열 위치를 결정합니다. 배열 위치가_id와 다르다는 점에 유의하세요:rs.conf() 복제본 세트 구성 객체를 변수(아래 예에서는
cfg)에 복사합니다. 그런 다음 변수에서 멤버에 대한 올바른 우선순위를 설정합니다. 그런 다음 변수를rs.reconfig()에 전달하여 복제본 세트 구성을 업데이트합니다.예를 들어, 배열의 세 번째 멤버(즉, 위치 2의 멤버)의 우선순위를 설정하려면 다음 명령 시퀀스를 실행합니다.
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) 참고
rs.reconfig()셸 메서드를 사용하면 현재 프라이머리가 강제로 물러나고 투표가 시행됩니다. 프라이머리가 물러나면 모든 클라이언트의 연결이 끊어집니다. 이는 의도된 동작입니다. 새 프라이머리를 선택하는 데 걸리는 평균 시간은 일반적으로 12초를 넘지 않아야 하며, 복제본 구성 변경은 항상 예정된 유지 관리 기간 동안에 발생해야 합니다.
이러한 명령이 반환되면 지리적으로 중복된 3개 멤버 복제본 세트가 생성됩니다.
복제본 세트에 기본값이 있는지 확인합니다.
rs.status() 사용하여 복제본 세트에서 주 복제본을 식별합니다.
지리적으로 중복된 5개 구성원 복제본 세트 배포
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
지리적으로 중복된 5개 멤버 복제본 세트 배포의 경우 시스템 배포 방법을 결정해야 합니다. 다섯 멤버에 대한 몇 가지 가능한 분포는 다음과 같습니다:
3개 데이터 센터에 분포: 데이터 센터 A에 2개, 데이터 센터 B에 2개, 데이터 센터 C에 1개 멤버를 분포합니다.
4개 데이터 센터에 분포: 한 곳에 2개, 나머지 3곳에 각각 하나의 멤버를 분포합니다.
5개 데이터 센터에 분포: 각 데이터 센터에 하나의 멤버를 분포합니다.
2개 데이터 센터에 분포: 데이터 센터 A에 3개, B에 2개를 분포합니다. 가능하다면 구성 서버 복제본 세트를 2개의 데이터 센터에 분포하는 것을 피합니다.
참고
두 개의 데이터 센터에 복제본 세트 구성원을 분산하면 단일 데이터 센터에 비해 이점이 있습니다. 두 개의 데이터 센터로 분산된 경우,
데이터 센터 중 하나가 다운되더라도 단일 데이터 센터 배포판과 달리 데이터를 읽을 수 있습니다.
소수의 구성원이 있는 데이터 센터가 다운되더라도 복제본 세트는 읽기 작업뿐만 아니라 쓰기 작업도 계속 수행할 수 있습니다.
그러나 대다수의 구성원이 있는 데이터 센터가 다운되면 복제본 세트는 읽기 전용이 됩니다.
가능하다면 최소 3개 이상의 데이터 센터에 구성원을 배포하세요. 구성 서버 복제본 세트(CSRS)의 경우 가장 좋은 방법은 3개(또는 구성원 수에 따라 그 이상) 센터에 배포하는 것입니다. 세 번째 데이터 센터의 비용이 부담스러운 경우, 회사 정책이 허용하는 경우 데이터 보유 멤버를 두 데이터 센터에 균등하게 분산하고 나머지 멤버는 클라우드에 저장하는 것도 한 가지 방법입니다.
적절한 옵션을 사용하여 복제 세트의 각 구성원을 시작하십시오.
각 멤버에 대해 다음 설정을 사용하여 mongod 인스턴스를 시작합니다.
replication.replSetName옵션을 복제본 세트 이름으로 설정합니다.애플리케이션이 2개 이상의 복제본 세트에 연결된 경우 각 세트의 이름이 달라야 합니다. 일부 드라이버는 복제본 세트 이름으로 복제본 세트 연결을 그룹화합니다.
net.bindIp옵션을 호스트 이름/IP 주소 또는 쉼표로 구분된 호스트 이름/IP 주소 목록으로 설정합니다.다른 설정은 배포에 맞게 적절하게 설정합니다.
이 튜토리얼에서는 5개의 mongod 인스턴스가 다음 호스트와 연결됩니다.
복제본 세트 멤버 | 호스트 이름 |
|---|---|
회원 0 | mongodb0.example.net |
회원 1 | mongodb1.example.net |
멤버 2 | mongodb2.example.net |
멤버 3 | mongodb3.example.net |
멤버 4 | mongodb4.example.net |
다음 예에서는 --replSet 및 --bind_ip 명령줄 옵션을 통해 복제본 세트 이름과 IP 바인딩을 지정합니다.
경고
인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
0}의 <hostname(s)|ip address(es)> 경우 원격 클라이언트(복제본 집합의 다른 구성원 포함)가 인스턴스에 연결하는 데 사용할 수 있는 인스턴스의 호스트 mongod 이름 및/또는 IP 주소를 지정합니다.
또는 구성 파일에서 replica set name hostnames/ip
addresses와 를 지정할 수도 있습니다.
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
구성 파일로 mongod을 시작하려면 --config 옵션으로 구성 파일의 경로를 지정합니다.
mongod --config <path-to-config>
프로덕션 배포에서는 이 프로세스를 관리하도록 초기화 스크립트를 구성할 수 있습니다. 초기화 스크립트는 이 문서의 범위를 벗어납니다.
복제본 세트를 시작합니다.
mongosh에서 복제본 세트 멤버 0에 대해 rs.initiate()를 실행합니다.
중요
rs.initiate()를 복제본 세트의 단일 mongod 인스턴스에서만 실행합니다.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" }, { _id: 3, host: "mongodb3.example.net:27017" }, { _id: 4, host: "mongodb4.example.net:27017" } ] })
복제본 세트 구성을 확인합니다.
rs.conf() 2}를 사용하여 복제본 세트 구성 객체를 표시합니다.
rs.conf()
복제본 세트 구성 객체는 다음과 유사합니다.
{ "_id" : "rs0", "version" : 1, "protocolVersion" : NumberLong(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 3, "host" : "mongodb3.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 4, "host" : "mongodb4.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("5df2c9ccc21c478b838b98d6") } }
선택 사항. 프라이머리가 되기 위한 멤버 자격을 구성합니다.
경우에 따라 한 데이터 센터의 노드가 다른 데이터 센터의 노드보다 먼저 프라이머리 노드로 선출되는 것을 선호할 수 있습니다. 한 데이터 센터의 멤버가 다른 데이터 센터의 멤버보다 더 높은 priority를 가지도록 멤버의 priority를 수정할 수 있습니다.
네트워킹 제한이 있거나 리소스가 제한된 구성원 등 복제본 세트의 일부 구성원은 장애 조치 시 기본 구성원이 될 수 없습니다. 기본이 되어서는 안 되는 구성원의 우선 순위가 0이 되도록 구성합니다.
예를 들어 사이트 중 하나에 있는 멤버의 상대적 자격을 낮추려면(이 예에서는 mongodb2.example.net) 멤버의 우선 순위를 0.5로 설정합니다.
복제본 세트 구성을 보고 멤버의
members배열 위치를 결정합니다. 배열 위치가_id와 다르다는 점에 유의하세요:rs.conf() 복제본 세트 구성 객체를 변수(아래 예에서는
cfg)에 복사합니다. 그런 다음 변수에서 멤버에 대한 올바른 우선순위를 설정합니다. 그런 다음 변수를rs.reconfig()에 전달하여 복제본 세트 구성을 업데이트합니다.예를 들어, 배열의 세 번째 멤버(즉, 위치 2의 멤버)의 우선순위를 설정하려면 다음 명령 시퀀스를 실행합니다.
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) 참고
rs.reconfig()셸 메서드를 사용하면 현재 프라이머리가 강제로 물러나고 투표가 시행됩니다. 프라이머리가 물러나면 모든 클라이언트의 연결이 끊어집니다. 이는 의도된 동작입니다. 새 프라이머리를 선택하는 데 걸리는 평균 시간은 일반적으로 12초를 넘지 않아야 하며, 복제본 구성 변경은 항상 예정된 유지 관리 기간 동안에 발생해야 합니다.
이러한 명령이 반환되면 지리적으로 중복된 5개 구성원 복제본 세트가 생성됩니다.
복제본 세트에 기본값이 있는지 확인합니다.
rs.status() 사용하여 복제본 세트에서 주 복제본을 식별합니다.