자체 관리 복제본 세트에서 호스트 이름 변경하기
대부분의 복제본 세트 의 경우 members[n].host 필드 의 호스트 이름은 변경되지 않습니다. 그러나 조직의 요구 사항이 변경되면 호스팅하다 이름의 일부 또는 전부를 마이그레이션 해야 할 수도 있습니다.
참고
혼동과 복잡성을 피하려면 항상 복제본 세트 구성의 members[n].host 필드 값에 확인 가능한 호스트 이름을 사용하세요.
중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
개요
이 문서에서는 members[n].host 필드에서 호스트 이름을 변경하는 두 가지 절차를 별도로 설명합니다. 다음 방법 중 하나를 사용합니다.
가용성을 저하시키지 않고 호스트 이름을 변경할 수 있습니다. 이 접근 방식을 사용하면 애플리케이션에서 항상 데이터를 읽고 복제본 세트에 쓸 수 있습니다. 하지만 이 접근 방식은 시간이 오래 걸리고 애플리케이션 계층에서 가동 중단 시간이 발생할 수 있습니다.
첫 번째 절차를 사용하는 경우 이전 위치와 새 위치 모두에서 복제본 세트에 연결하도록 애플리케이션을 구성해야 하는데, 이 경우 애플리케이션 계층에서 다시 시작하고 재구성해야 하는 경우가 많으며 애플리케이션 가용성에 영향을 줄 수 있습니다. 애플리케이션을 재구성하는 것은 이 문서의 범위를 벗어납니다.
이전 호스트 이름에서 실행 중인 모든 멤버를 한 번에 중지시킵니다. 이 접근 방식은 유지 관리 기간이 더 짧지만, 작업 중에는 복제본 세트를 사용할 수 없습니다.
가정
복제본 세트의 멤버가 세 명인 경우:
database0.example.com:27017(프라이머리)database1.example.com:27017database2.example.com:27017
그리고 다음과 같은 rs.conf() 출력의 경우:
{ "_id" : "rs", "version" : 3, "members" : [ { "_id" : 0, "host" : "database0.example.com:27017" }, { "_id" : 1, "host" : "database1.example.com:27017" }, { "_id" : 2, "host" : "database2.example.com:27017" } ] }
다음 절차에 따라 멤버의 호스트 이름을 다음과 같이 변경할 수 있습니다.
mongodb0.example.net:27017(프라이머리)mongodb1.example.net:27017mongodb2.example.net:27017
배포에 가장 적합한 절차를 사용하세요.
복제본 세트 가용성을 유지하면서 호스트 이름 변경
이 절차에서는 위의 가정을 사용합니다.
복제본 세트의 각 세컨더리 복제본에 대해 다음의 작업 시퀀스를 수행합니다.
세컨더리를 중지합니다.
새 위치에서 세컨더리를 다시 시작합니다.
복제본 세트의 프라이머리에
mongosh를 연결합니다. 이 예시에서 프라이머리는 포트27017에서 실행되므로 다음 명령을 실행합니다.mongosh --port 27017 rs.reconfig()를 사용하여 새 호스트 이름으로 복제본 세트 구성 문서를 업데이트합니다.예를 들어, 다음 명령 시퀀스는 복제본 세트 구성 문서에서
members배열의 배열 인덱스1에 있는 세컨더리 호스트 이름을 업데이트합니다(예시:members[1]).cfg = rs.conf() cfg.members[1].host = "mongodb1.example.net:27017" rs.reconfig(cfg) 구성 문서 업데이트에 대한 자세한 내용은 예시를 참조하세요.
클라이언트 애플리케이션이 새 위치에서 세트에 액세스할 수 있도록 하고, 세컨더리가 세트의 다른 멤버와 수준을 맞추도록 하세요.
프라이머리가 아닌 각 세트 멤버에 대해 위의 단계를 반복하세요.
mongosh를 프라이머리에 연결하고rs.stepDown()메서드를 사용하여 프라이머리를 단계를 낮춥니다.rs.stepDown() 복제본 세트는 다른 멤버를 프라이머리로 선정합니다.
단계 강등이 성공하면 이전 프라이머리 계정을 종료합니다.
새 위치에서 신규 프라이머리가 될
mongod인스턴스를 시작합니다.방금 선정된 현재 프라이머리에 연결하고, 신규 프라이머리가 될 노드의 호스트 이름으로 복제본 세트 구성 문서를 업데이트합니다.
예를 들어, 이전 프라이머리가
0위치에 있고 신규 프라이머리의 호스트 이름이mongodb0.example.net:27017인 경우 다음을 실행합니다.cfg = rs.conf() cfg.members[0].host = "mongodb0.example.net:27017" rs.reconfig(cfg) mongosh를 새 프라이머리에 연결합니다.새 구성을 확인하려면
mongosh의rs.conf()를 호출합니다.출력은 다음과 같아야 합니다.
{ "_id" : "rs", "version" : 4, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017" }, { "_id" : 1, "host" : "mongodb1.example.net:27017" }, { "_id" : 2, "host" : "mongodb2.example.net:27017" } ] }
모든 호스트 이름을 동시에 변경
이 절차에서는 위의 가정을 사용합니다.
전제 조건
다음 절차는 local 데이터베이스의 system.replset 컬렉션을 읽고 업데이트합니다.
배포서버에서 액세스 제어를 실시하는 경우, 절차를 수행하는 사용자에게는 system.replset 컬렉션에 대한 find 및 update 권한 조치가 있어야 합니다.
필요한 권한을 제공하는 역할을 생성하려면 다음을 수행합니다.
userAdminAnyDatabase역할 이 있는 사용자와 같이 사용자 및 역할을 관리 수 있는 권한이 있는 사용자로 로그인합니다. 다음 절차에서는 자체 관리형 배포서버에서 액세스 제어 활성화에 생성된myUserAdmin를 사용합니다.mongosh --port 27017 -u myUserAdmin --authenticationDatabase 'admin' -p local데이터베이스의system.replset컬렉션에 필요한 권한을 제공하는 사용자 역할을 생성합니다.db.adminCommand( { createRole: "systemreplsetRole", privileges: [ { resource: { db: "local", collection: "system.replset" }, actions: ["find","update"] } ], roles: [] } ); 이름 변경 절차를 수행할 사용자에게 역할을 부여합니다. 예를 들어 다음에서는
admin데이터베이스에 기존 사용자"userPerformingRename"가 있다고 가정합니다.use admin db.grantRolesToUser( "userPerformingRename", [ { role: "systemreplsetRole", db: "admin" } ] );
절차
복제본 세트의 모든 멤버를 중지시킵니다.
--replSet런타임 옵션을 사용하지 않고 다른 포트에서 각 멤버를 다시 시작합니다. 유지 관리 중에 포트 번호를 변경하면 유지 관리를 수행하는 동안 클라이언트가 이 호스트에 연결할 수 없습니다. 멤버의 일반적인--dbpath를 사용합니다(이 예시에서는/data/db1). 다음과 유사한 명령을 사용합니다.경고
인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.
mongod --dbpath /data/db1/ --port 37017 --bind_ip localhost,<hostname(s)|ip address(es)> 중요
변경된 IP 주소로 인해 구성이 업데이트되는 것을 방지하려면 IP 주소 대신 DNS 호스트 이름을 사용하세요. 특히 복제본 세트 구성원 또는 샤딩된 클러스터 구성원을 구성할 때 IP 주소 대신 DNS 호스트 이름을 사용하는 것이 중요합니다.
IP 주소 대신 호스트 이름을 사용하여 스플릿 네트워크 호라이즌 전반에 걸쳐 클러스터를 구성하세요. MongoDB 5.0부터 IP 주소로만 구성된 노드는 스타트업 유효성 검사에 실패하며 시작되지 않습니다.
복제본 세트의 각 멤버에 대해 다음의 작업 시퀀스를 수행합니다.
새 임시 포트에서 실행 중인
mongod에mongosh를 연결합니다. 예를 들어 임시 포트37017에서 실행 중인 멤버의 경우 다음 명령을 실행합니다.mongosh --port 37017 액세스 제어와 함께 실행하는 경우 적절한 권한이 있는 사용자로 연결합니다. 전제 조건을 참조하세요.
mongosh --port 37017 -u userPerformingRename --authenticationDatabase=admin -p 복제본 세트 구성을 수동으로 편집합니다. 복제본 세트 구성은
local데이터베이스의system.replset컬렉션에 있는 유일한 문서입니다.호스트 이름을 변경하려면 복제본 세트 구성을 편집하여 복제본 세트의 모든 멤버에 대한 새 호스트 이름 및 포트를 제공합니다.
local데이터베이스로 전환하세요.use local 구성 문서에 대한 JavaScript 변수를 생성합니다.
_id필드의 값을 복제본 세트와 일치하도록 수정합니다.cfg = db.system.replset.findOne( { "_id": "rs0" } ) 복제본 세트의 각 멤버에 대해 새 호스트 이름과 포트를 제공합니다. 복제본 세트와 일치하도록 호스트 이름과 포트를 수정합니다.
cfg.members[0].host = "mongodb0.example.net:27017" cfg.members[1].host = "mongodb1.example.net:27017" cfg.members[2].host = "mongodb2.example.net:27017" system.replset컬렉션의 호스트 이름과 포트를 업데이트합니다.db.system.replset.updateOne( { "_id": "rs0" }, { $set: cfg } ) 변경 사항을 확인합니다.
db.system.replset.find( {}, { "members.host": 1 } )
멤버에 대한
mongod프로세스를 중지하세요.
세트의 모든 멤버를 다시 구성한 후 일반적인 방법으로 각
mongod인스턴스를 시작합니다(일반적인 포트 번호 및--replSet옵션 사용). 예시:경고
인스턴스를 공개적으로 접근 가능한 IP 주소에 바인딩하기 전에 무단 접근으로부터 클러스터를 보호해야 합니다. 보안 권장 사항의 전체 목록은 자체 관리 배포서버에 대한 보안 검사 목록을 참조하세요. 최소한 인증을 활성화하고 네트워크 인프라를 강화하는 것을 고려합니다.
mongod --dbpath /data/db1/ --port 27017 --replSet rs0 --bind_ip localhost,<hostname(s)|ip address(es)> mongosh를 사용하여mongod인스턴스 중 하나에 연결합니다. 예를 들면 다음과 같습니다.mongosh --port 27017 새 구성을 확인하려면
mongosh의rs.conf()를 호출합니다.출력은 다음과 같아야 합니다.
{ "_id" : "rs0", "version" : 4, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017" }, { "_id" : 1, "host" : "mongodb1.example.net:27017" }, { "_id" : 2, "host" : "mongodb2.example.net:27017" } ] }