샤딩을 사용하는 경우
- 사용 가능한 메모리를 늘릴 때
- 사용 가능한 디스크 공간을 늘리는 경우
- 서버 부하를 줄일 때
- 단일 mongod가 처리할 수 있는 것보다 더 많은 데이터를 읽거나 쓸 때
샤딩이 필요한 시기를 결정하려면 모니터링이 중요합니다. 무언가를 사용할 수 있게 하려면(전개) 복제본 세트를 전환하는 방법과 시기를 미리 계획하십시오.
전개
사용자의 필요에 따라 시스템 자원을 할당, 분배, 배분한 후 필요할 때 즉시 사용할 수 있도록 시스템을 준비하는 것을 말합니다.
서버 시작
클러스터를 생성하기 전에 필요한 모든 프로세스를 시작해야 합니다.
- 몽고, 샤드 구성
- 구성 서버: 클러스터 구성을 저장하는 일반 mongod 서버
- 클러스터 구성: 복제 세트 호스팅 샤드, 샤딩 컬렉션, 각 청크가 상주하는 샤드 등
MongoDB 3.2부터는 복제 세트를 구성 서버로 사용할 수 있습니다. 복제 세트는 구성 서버에서 사용하는 기존의 동기화 메커니즘을 대체합니다.
구성 서버
구성 서버는 클러스터의 두뇌이며 어떤 서버에 어떤 데이터가 있는지에 대한 모든 메타데이터를 보유합니다. 그래서 구성 서버 먼저 설정해야한다. 프로덕션 배포에서 구성 서버 복제 세트에는 3개 이상의 구성원이 있어야 합니다. 각 구성 서버는 지리적으로 분산된 별도의 물리적 컴퓨터에 상주해야 합니다.
mongos는 구성 서버에서 구성을 검색합니다.
1) 구성 서버는 mongos 프로세스 이전에 시작되어야 합니다.
$ mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.51
$ mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.52
$ mongod --configsvr --replSet configRS --bind_ip localhost,198.51.100.53
2) 구성 서버를 복제 세트로 시작하십시오. 복제 세트 구성원 중 하나에 mongo 쉘을 연결하십시오.
$ mongo --host <호스트명> --port <포트>
3) rs.initiate() 도우미를 사용합니다.
> rs.initiate(
{
id: "configRS"
configsvr: true,
members: (
{id : 0, host : "cfg1.example.net:27019"},
{id : 1, host : "cfg2.example.net:27019"},
{id : 2, host "cfg3.example.net:27019"}
)
}
)| 가능성 | 설명 |
| _ID | 복제 세트 이름(ConfigRS) |
| –configsvr | mongod를 구성 서버로 사용하는 방법 이 옵션으로 실행되는 서버에서 클라이언트(예: 다른 클러스터 구성 요소)는 config 및 admin 이외의 데이터베이스에 데이터를 쓸 수 없습니다. |
관리자 데이터 베이스
- 인증 및 권한 부여와 관련된 컬렉션과 내부 사용을 위한 기타 시스템.* 컬렉션을 포함합니다.
구성 데이터 베이스
- 샤딩 클러스터 메타데이터 모음을 포함합니다.
- 메타데이터가 변경되면 구성 데이터베이스에 데이터를 씁니다. B. 청크 마이그레이션/청크 후.
몽고 프로세스
3개의 구성 서버가 실행 중이면 애플리케이션이 연결할 mongos 프로세스를 시작합니다.
mongos 프로세스는 구성 서버가 있는 위치를 알아야 하므로 항상 –configdb 옵션을 사용하여 mongos 프로세스를 시작해야 합니다.
$ mongos --configdb \
configRS/cfg1.example.net:27019 \
cf92.example.net:27019,cfg3.example.net:27019 \
--bind_ip localhost,198.51.100.100 --logpath /var/log/mongos.log1) Mongos는 기본적으로 포트 27017에서 실행됩니다.
2) –logpath를 설정하여 로그를 안전하게 저장합니다.
샤딩을 복제 세트로 추가
이제 샤딩을 추가할 수 있습니다. 복제 세트가 이미 있는 경우와 처음부터 시작하는 경우가 있습니다.
레플리카 세트가 있는 경우
애플리케이션에 이미 복제 세트가 있는 경우 해당 세트가 존재합니다. 첫 번째 샤드레플리카 세트를 샤드로 바꾸려면 구성원의 구성을 약간 수정한 다음 샤드를 형성하기 위해 레플리카 세트를 찾는 방법을 mongos에 알려야 합니다.
예) svr1.example.net, svr2.example.net, svr3.example.net에 rs0이라는 레플리카 셋이 있다면 먼저 mongo shell을 사용하여 멤버 중 하나에 접속한다.
$ mongo srv1.example.net
다음 명령으로 which 구성원 주요한그리고 어느 멤버 중고등 학년작동하는지 확인할 수 있습니다
> rs.status()MongoDB 3.4부터는 샤드에 대해 Mongod 인스턴스가 있어야 합니다. –shardsvr 옵션sharding.clusterRole 구성 파일 설정 또는 –shardsvr 명령줄 옵션을 통해 Configure로 구성해야 합니다.
샤드로 변환할 때 복제 세트의 각 구성원에 대해 다음 작업을 수행해야 합니다.
1) 먼저 –shardsvr 옵션을 사용하여 각 보조 페이지를 한 번에 하나씩 다시 시작합니다.
2) 기본 레벨을 레벨별로 강등합니다. (> rs 스텝다운())
3) -shardsvr 옵션으로 재부팅
1) 보조를 닫고 다음과 같이 다시 시작합니다.
$ mongod --replSet "rs0" --shardsvr --port 27017
--bind_ip localhost,<멤버의 IP 주소>–bind_ip 매개변수에 각 보조 서버의 올바른 IP 주소를 사용해야 합니다.
2) mongo 쉘을 기본에 연결하십시오.
$ mongo m1.example.net
3) 그리고 프라이머리 강등.
> rs.stepDown()
4) 그런 다음 –shardsvr 옵션을 사용하여 이전 기본 데이터베이스를 다시 시작합니다.
$ mongod --replSet "rs0" --shardsvr --port 27017
--bind_ip localhost,<이전 프라이머리의 IP 주소>
이제 복제 세트를 샤드로 추가할 수 있습니다.
1) mongo 쉘을 mongos 관리 데이터베이스에 연결합니다.
$mongo mongos1.example.net:27017/admin
2) sh.addShard() 메서드를 사용하여 클러스터에 샤드를 추가합니다.
> sh.addShard(
"rs0/svr1.example.net:27017,svr2.example.net:27017,svr3.example.net:27017")
복제 세트의 모든 구성원을 지정하거나 지정하지 않을 수 있습니다. mongos는 시드 목록에 없는 구성원을 자동으로 인식합니다.
3) sh.status()가 실행되면 MongoDB는 즉시 샤드를 나열합니다.
rs0/svr1.example.net:27017,svr2.example.net:27017,svr3.example.net:27017복제 세트 이름 rs0은 이 샤드의 식별자가 됩니다. 샤드를 제거하거나 데이터를 샤드로 이동하려면 rs0을 사용하여 설명합니다. 레플리카 세트의 멤버십과 상태는 시간이 지남에 따라 변경될 수 있으므로 특정 서버(예: svr1.example.net)를 사용하는 것이 좋습니다.
복제본 세트를 샤드로 추가한 후 애플리케이션을 복제본 세트 대신 mongos에 연결할 수 있습니다. Mongos는 클라이언트 라이브러리와 마찬가지로 애플리케이션 장애 조치를 자동으로 처리하고 오류를 사용자에게 전달합니다.
용량 추가
용량을 추가하려면 샤드를 추가해야 합니다. 레플리카 세트를 생성하고 새로운 빈 샤드를 추가하고 기존 샤드와 다른 이름을 지정합니다. 복제본 세트가 초기화되고 기본 노드가 있으면 mongos에서 addShard 명령을 실행하여 클러스터에 추가하고 새 복제본 세트의 이름과 호스트를 시드로 지정합니다.
기존 비 샤드 복제본 세트가 여러 개 있는 경우 데이터베이스 이름이 겹치지 않는 한 새 샤드로 클러스터에 추가할 수 있습니다.
데이터 샤딩
MongoDB는 배포 방법을 알려줄 때까지 데이터를 자동으로 배포하지 않습니다. 배포할 데이터베이스 및 컬렉션을 명시적으로 지정해야 합니다.
“이름” 키에서 음악 데이터베이스의 아티스트 컬렉션을 공유하고 싶다고 가정합니다. 먼저 음악 데이터베이스의 샤딩을 활성화합니다.
> sh.enableSharding("music")
데이터베이스는 항상 데이터베이스 내 수집 전에 조각화되어야 합니다.
데이터베이스 수준 샤딩을 활성화한 후 sh.shardCollection을 실행하여 컬렉션을 조각화할 수 있습니다.
> sh.shardCollection("music.artists", {"name" : 1})이제 아티스트 컬렉션이 “이름” 키로 분할됩니다. 기존 모음을 공유하려면 이름 필드에 색인이 있어야 합니다. 그렇지 않으면 shardCollection을 호출하면 오류가 반환됩니다.
조각화할 컬렉션이 아직 존재하지 않는 경우 Mongos는 샤드 키 인덱스를 자동으로 생성합니다. shardCollection 명령은 컬렉션을 청크로 나눕니다.
조각
데이터 이동을 위해 MongoDB에서 사용하는 단위
성공적인 명령 실행 후 MongoDB는 컬렉션을 클러스터의 샤드 전체에 배포합니다.
MongoDB에서 클러스터 데이터를 추적하는 방법
모든 몽고는 샤드 키가 주어졌을 때 문서를 찾을 위치를 항상 알아야 합니다. MongoDB는 특정 샤드 키 범위 내에서 문서를 청크로 나누고 청크는 항상 샤드에 있으므로 MongoDB에는 샤드에 매핑된 작은 청크 테이블이 있습니다.
예
컬렉션의 샤드 키가 {“age”: 1}인 경우 청크는 “age” 필드가 3에서 17 사이인 모든 문서로 구성됩니다. mongos가 {“age” : 5} 쿼리 요청을 수신하면 쿼리를 블록 3과 17 사이의 샤드로 전달합니다.
청크가 특정 크기에 도달하면 MongoDB는 자동으로 청크를 두 개의 작은 청크로 분할합니다. 그리고 3-15 또는 12-17과 같이 범위가 겹치는 청크를 가질 수 없습니다.
문서는 항상 하나의 청크에만 속합니다. 따라서 배열 필드는 샤드 키로 사용할 수 없습니다. 이는 MongoDB가 배열에 여러 인덱스 항목을 생성하기 때문입니다.
청크 영역
각 청크는 둘러싸인 영역으로 설명됩니다. 재청크된 컬렉션은 단일 청크로 시작되며 모든 문서는 해당 청크에 배치됩니다. 청크 범위는 $minKey에서 $maxKey로 표시되며 값의 범위는 음의 무한대에서 양의 무한대까지입니다.
청크가 커지면 MongoDB는 자동으로 청크를 다음과 같이 정의된 두 개의 청크로 분할합니다.
예
“나이”로 나누었다고 가정해 보겠습니다. “Age”가 3에서 17 사이인 모든 문서는 하나의 청크에 포함되므로 3 <= "Age" < 17입니다. 이를 두 섹션으로 분할합니다. 한 부분은 3 <= "Age" < 12이고 다른 부분은 12 <입니다. = "나이" < 17. 이때 12를 구분점이라고 합니다.
청크 정보 config.chunks 컬렉션그 안에 저장된다
복합 샤드 키의 청크 범위
복합 샤드 키의 경우 샤드 범위는 두 개의 키로 정렬하는 것과 동일하게 작동합니다.
예
{“username”: 1, “age”: 1}에 샤드 키가 있다고 가정합니다.
1) 사용자 이름이 있는 사람이 있는 청크를 쉽게 찾을 수 있습니다.
2) 연령만 고려하면 몽고는 전체 또는 대부분의 청크를 검사해야 합니다.
- 나이에 맞는 청크를 쿼리하려면 {“age” : 1, “username” : 1} 과 같은 역 샤드 키를 사용해야 합니다.
조각 분할
각 샤드의 기본 mongod는 청크에 얼마나 많은 데이터가 들어왔는지 추적하고 특정 임계값에 도달하면 청크를 분할해야 하는지 여부를 확인합니다.
1) 청크 분할이 필요한 경우 Mongod는 구성 서버에 전역 청크 구성 값을 요청합니다.
2) 그런 다음 청킹을 수행합니다.
3) 구성 서버에서 메타데이터를 업데이트합니다.
4) 구성 서버에 새로운 청크 문서가 생성되고 이전 청크의 범위(“max”)가 변경됩니다.
5) 샤드의 최상위 청크인 경우 Mongod는 밸런서에게 청크를 다른 샤드로 이동하도록 요청합니다.
이는 단조롭게 증가하는 샤드 키를 사용할 때 샤드 과부하를 방지하기 위한 것입니다. 청크는 샤드 키 값이 변경되는 문서를 기준으로만 분할할 수 있습니다. 예를 들어 샤드 키가 “나이”인 경우 샤드 키(나이)가 변경되면 청크가 분할됩니다.
Mongod가 분기를 시도할 때 구성 서버 중 하나가 작동하지 않는 경우 Mongod는 메타데이터를 업데이트할 수 없습니다. 파티셔닝이 발생하려면 모든 구성 서버가 가동되고 연결 가능해야 합니다. Mongod가 청크에 대한 쓰기 요청을 계속 받으면 청크 공유를 계속 시도하고 실패합니다.
스플릿 스톰
Mongod가 청크 분할을 반복적으로 시도하고 실패하는 프로세스입니다.
파티션 광기를 방지하는 유일한 방법은 구성 서버를 가능한 한 오랫동안 활성 상태로 유지하는 것입니다.
평형 장치
밸런서는 데이터 이동을 담당합니다. 샤드 간 불균형이 있는지 주기적으로 확인하고 있으면 청크 이동을 시작합니다. MongoDB 3.4 이상에서 밸런서는 구성 서버 복제 세트의 기본 구성원입니다.
밸런서는 각 샤드의 청크 수를 모니터링하는 구성 서버의 기본 복제 세트에 대한 백그라운드 프로세스입니다. 샤드의 청크 수가 특정 마이그레이션 임계값에 도달한 경우에만 활성화됩니다.
Mongos 로그 오류: setShardVersion을 설정할 수 없습니다.
모든 읽기 및 쓰기는 데이터 이동이 완료될 때까지 이전 블록으로 전달됩니다. 메타데이터가 업데이트된 후 이전 위치의 데이터에 액세스하려는 모든 mongos 프로세스가 실패합니다. 이 시점에서 Mongos는 자동으로 오류를 처리하고 새 샤드에서 프로세스를 반복하므로 클라이언트에 오류가 표시되지 않습니다.
Mongos는 위와 같은 오류가 발생하면 구성 서버에서 데이터의 새 위치를 확인하고 청크 테이블을 업데이트한 다음 요청을 다시 시도합니다. 그리고 클라이언트에게 데이터를 반환합니다.