Couchbase Server 4.x에서는 고객이 인덱스의 고가용성 유지와 N1QL 쿼리의 부하 분산이라는 두 가지 요구 사항을 충족하기 위해 등가 인덱스를 만들곤 했습니다. 즉, 정확히 동일한 인덱스 정의를 사용하여 이름만 다른 인덱스를 생성하는 것이었습니다. 이름에 뭐가 있냐고 물으실지 모르겠지만... 장미는 장미입니다 ;)
|
1 2 3 |
create 색인 index1 on 버킷(field1); create 색인 index2 on 버킷(field1); |
N1QL 쿼리는 각 인덱스에서 보이는 로드에 따라 두 인덱스 중 하나에 도달할 수 있으며, 또한 인덱스 중 하나가 다운되면 다른 인덱스가 쿼리 트래픽을 계속 처리해야 합니다. 동등한 인덱스에는 몇 가지 문제가 있었습니다:
- 다른 이름으로 인덱스를 수동으로 생성해야 했습니다.
- 선택한 인덱스 노드에 인덱스를 배포하는 간소화된 방식이 없었습니다. 인덱스 노드를 추가하거나 제거할 때, 그러한 인덱스 복사본을 다시 생성하는 것은 수동 작업이었습니다.
- USE 인덱스 힌트 또는 준비된 문을 사용하는 쿼리는 인덱스 노드가 손실된 경우 인덱스 노드와의 긴밀한 친화성으로 인해 여러 인덱스 이름.
카우치베이스 서버 5.0에서는 등가 인덱스 사용에서 인덱스 복제본으로 전환할 수 있습니다. 인덱스 복제본을 사용하면 인덱스 정의를 한 번만 실행하고 원하는 복제본 수 또는 복제본을 배치해야 하는 노드를 지정하면 그 이후에는 쿼리 트래픽을 할당하고 노드가 추가되거나 제거될 때 적절하게 재조정하는 모든 작업을 Couchbase가 처리합니다. 시스템에 충분한 복제본이 남아 있는 경우(즉, 인덱스 복제본을 포함하는 모든 노드가 다운되지 않은 경우), 인덱스 서비스는 시스템 장애 시에도 인덱스가 온라인 상태를 유지하도록 보장합니다. 복제본 중 하나에서 인덱스 스캔이 실패하면 다른 복제본에서 스캔이 시도됩니다. 복제본이 생성되는 즉시 인덱스 서비스는 쿼리 트래픽을 전송하기 시작합니다.
|
1 |
create 색인 index1 on 버킷(field1) 와 함께 {"숫자_replica":2} |
인덱스를 생성하는 동안 num_replica 매개 변수를 사용하면 인덱스 서비스는 매개 변수에 언급된 대로 추가 복제본을 생성합니다. 따라서 num_replica가 2이면 인덱스의 복사본은 3(num_replica + 1) 개(즉, 추가 복사본 2개)가 됩니다. 참고하세요:
- 에 비해 노드 수가 적은 경우, 인덱서 노드 수가 지정한 복제본 수로 인덱스를 생성하기에 충분하지 않다는 읽기 가능한 메시지와 함께 create_index가 실패합니다. 따라서 인덱서 노드 수는 create index 문에 지정된 num_replica보다 큰 것이 좋습니다.
- 카우치베이스는 인덱스가 가장 적은 노드를 선택하며, 동일한 노드에 인덱스 복사본(즉, 복제본)을 두 개 이상 배치하지 않습니다.
- 인덱스 노드가 서버 그룹으로 분산되어 있는 경우(랙 영역 인식), 카우치베이스는 가능한 한 많은 서버 그룹에 복제본을 분산시킵니다. 복제본 수가 서버 그룹 수보다 많으면 일부 서버 그룹은 나머지 서버 그룹보다 더 많은 복제본을 보유하게 됩니다.
인덱스를 생성할 노드를 수동으로 지정하려면 num_replica 파라미터를 'nodes' 파라미터로 대체하면 됩니다.
|
1 |
create 색인 index1 on 버킷(field1) 와 함께 {"노드":["1.2.3.4:8091", "1.2.3.5:8091", "1.2.3.6:8091"]} |
이 구문은 'nodes' 매개 변수를 지정하여 여러 서버 그룹에 있는 노드를 선택하는 것이 좋습니다. 이 구문은 노드 선택의 유연성을 제공하지만, num_replica를 사용하는 구문과 달리 Couchbase Index Service는 사용자가 제공한 노드 설정을 재정의하지 않습니다.
즉, 인덱스 복제본에는 마스터-슬레이브라는 개념이 없고 모든 인덱스 복제본이 활성 상태로 유지되므로 모든 복제본이 쿼리 트래픽을 계속 수신합니다. 이는 로드 밸런싱에 도움이 됩니다.
인덱스 복제본 이동
인덱스가 (복제본과 함께) 노드에 분산되어 있는 경우 : "10.10.10.1:8091", "10.10.10.2:8091", "10.10.10.3:8091" 그리고 복제본(예: 10.10.10.2:8091)을 다른 노드로 수동으로 이동하려는 경우, 다음 REST 호출(인덱싱 노드 중 하나에서 실행될)을 통해 작업을 완료할 수 있습니다:
|
1 |
curl -u <em>사용자:비밀번호</em> 10.10.10.1:9102/moveIndex -d '{"index" : "def_city", "bucket" : "travel-sample", "nodes" : ["10.10.10.1:8091","10.10.10.4:8091","10.10.10.3:8091"]}' |
Couchbase는 "10.10.10.2:8091″의 복제본만 "10.10.10.4:8091″로 이동해야 하고 "10.10.10.1:8091″ 및 "10.10.10.3:8091″의 복제본은 건드리지 않으므로 복제본 하나만 이동합니다.
인덱스 이동은 복제본 수를 변경(증가 또는 감소)하지 않으며, 이 REST 호출의 'nodes' 매개변수에 언급할 노드 수는 복제본이 이미 분산되어 있는 노드 수와 일치해야 합니다.
드롭 지수
인덱스 삭제 문은 모든 복제본을 삭제합니다. 모든 복제본이 삭제될 때까지 인덱스는 온라인 상태로 유지됩니다.
동등한 인덱스에서 인덱스 복제본으로 전환/이동하는 방법은 무엇인가요? 자세히 보기 여기.
인덱스 복제본은 카우치베이스 서버 5.0에서 MOI와 GSI(플라즈마) 모두에 대해 지원됩니다. 앞서 동등한 인덱스에 대해 언급했던 문제들이 인덱스 복제본에는 존재하지 않습니다. 여기를 클릭하세요 를 클릭해 Couchbase Server 5.0을 다운로드하고 인덱스 복제본을 사용해 보세요. 다음 주소로 의견을 남겨 주세요. 포럼.
"인덱스 복제본은 카우치베이스 서버 5.0에서 MOI와 GSI(플라즈마) 모두에 대해 지원됩니다."
즉, GSI(ForestDB) 인덱스(즉, 커뮤니티 에디션 인덱스)는 지원되지 않나요?