Couchbase Server 4.0은 N1QL 쿼리 엔진을 지원하기 위해 글로벌 보조 인덱스(GSI)를 도입했습니다. 이제 Couchbase Server 5.0(4월 개발자 빌드 기준), 이러한 인덱스를 자동으로 복제하고 재조정하는 기능을 추가했습니다.
처음에는 GSI를 매우 수동으로 관리했습니다:
- 고가용성을 보장하기 위해 최종 사용자는 동일한 정의로 여러 인덱스를 수동으로 구성하고 클러스터의 어느 노드에 배포할지 지정했습니다. 한 노드에 장애가 발생하면 최종 사용자는 손실된 인덱스를 수동으로 다시 만들어야 했습니다.
- 스케일 아웃, 업그레이드 또는 장애 발생 후 노드를 추가 및 제거할 때 최종 사용자는 이동 및 이동하는 노드에서 인덱스를 수동으로 이동하고 다시 생성해야 했습니다.
이 두 가지 주요 운영 작업이 이제 Couchbase Server에 자동으로 내장되어 있다는 사실을 알려드리게 되어 매우 자랑스럽게 생각하며, 여기서 자세히 설명해드리겠습니다.
GSI 복제
4.0에서 GSI를 도입한 후 고객으로부터 가장 많이 받은 요청 중 하나는 복제 자동 관리에 대한 것이었습니다: "복제본이 몇 개나 되는지 알려주고 싶어요."
이제 가능합니다:
|
1 |
만들기 INDEX `IDX_에어포트명` 켜기 `여행-샘플`(`공항명`) WITH {"num_replica":1}; |
간단한 명령 한 번으로 카우치베이스가 작동합니다:
- 두 개의 동일한 인덱스 만들기
- 별도의 노드에 인덱스 배포 및 구축
- 랙 영역 인식 구성 준수
사용 가능한 노드가 충분하지 않으면 오류 메시지가 빠르게 표시됩니다:
|
1 2 3 4 5 6 7 |
[ { "code": 5000, "msg": "GSI CreateIndex() - 원인: 인덱스를 생성하지 못했습니다. 복제본 수가 2인 인덱스를 생성할 인덱서 노드가 충분하지 않습니다.", "쿼리_프롬_유저": "`travel-sample`(`에어포트명`)에 `idx_airportname` 인덱스 생성 {\"num_replica\":2};" } ] |
꽤 멋지지 않나요?
"num_replica"를 사용하는 경우, 클러스터 내에서 적절한 인덱스 레이아웃을 결정하기 위해 Couchbase에 의존하게 됩니다. 더욱 세밀하게 제어하려면 단일 인덱스를 복제할 정확한 노드를 지정하세요:
|
1 |
만들기 INDEX `IDX_에어포트명` 켜기 `여행-샘플`(`공항명`) WITH {"nodes":["ec2-35-167-251-49.us-west-2.compute.amazonaws.com:8091", "ec2-54-69-121-55.us-west-2.compute.amazonaws.com:8091"]}; |
짜잔!
이제 이러한 인덱스는 쿼리 엔진에 의해 자동으로 로드 밸런싱되며, 일치하는 인덱스가 하나 이상 남아 있는 한 장애가 발생하더라도 쿼리에는 아무런 중단이 발생하지 않습니다.
GSI 리밸런싱
자동 복제 기능만으로는 충분하지 않습니다. 생성리밸런싱 형태의 자동 관리 기능도 추가해야 했습니다.
다시 말씀드리지만, 4월 개발자 빌드부터 Couchbase Server 5.0의 인덱스 서비스는 이제 "재조정 인식" 기능을 지원합니다:
- 인덱스 노드가 클러스터에서 제거되면 해당 인덱스는 나머지 노드에 자동으로 재분배됩니다. 그러나 클러스터에 새 인덱스 노드를 추가해도 인덱스가 다시 배포되지는 않습니다. 이는 인덱스의 과도한 이동을 방지하고 관리자가 지정한 위치를 유지하기 위한 설계입니다. 이 재배포는 필요한 경우 이후 릴리스에서 추가될 수 있는 기능입니다.
- 인덱스 노드가 장애가 발생하여 교체되면 적절한 복제본이 다시 생성됩니다. 마찬가지로, 장애가 발생한 노드를 교체하지 않고 리밸런싱을 수행하면 클러스터의 나머지 노드에 해당 인덱스 복제본이 다시 생성됩니다.
이 모든 것을 시도해보고 "그냥 작동"하는 것을 확인하시기 바랍니다! Couchbase Server를 다운로드하려면 여기를 클릭하세요.
Q1:
WITH {"num_replica":1};이것은 이 인덱스에 하나의 복제본이 있다는 것을 의미합니까?Q2: 그리고 CB 클러스터에는 인덱스 서비스 노드가 2개 이상 있어야 하나요?
Q3: CB 클러스터에 인덱스 서비스 노드가 2개 이상 있는 경우 어떻게 하나요? 하나의 노드에 두 개 이상의 서비스(인덱스 서비스/데이터 서비스/쿼리 서비스)가 있는 경우 인덱스 서비스는 노드를 어떻게 선택하나요?
Q4: 이 2 인덱스는 마스터-슬레이브 또는 마스터-마스터 모드로 작동하나요?
Q5: 인덱스가 마스터-마스터 모드로 작동하는 경우 쿼리 서비스는 어떤 알고리즘으로 인덱스를 선택하나요? 임의 알고리즘인가요, 아니면 더 복잡한 알고리즘인가요?
Q6: 스케일 아웃을 위해 인덱스 복제본을 더 추가하려면 다른 인덱스로 인덱스를 다시 만들어야 하나요?
num_replica가치?안녕하세요 @atom992님, 좋은 질문입니다! 여기에 답변하고 메인 블로그에 다시 추가하는 것이 적절한지 살펴보겠습니다:
1 –
"num_replica"는 생성하려는 인덱스의 _추가_ 복사본 수를 나타냅니다(데이터 서비스 작동 방식과 유사). 따라서WITH {"num_replica":1};은 요청하는 인덱스의 복사본을 두 개 생성합니다.2 - 예, 클러스터에는 최소한 그 수만큼의 인덱스 서비스 노드가 있어야 합니다. 노드가 충분하지 않으면 명령이 즉시 오류를 반환합니다.
3 - 노드가 더 많으면 Couchbase는 인덱스와 그 복제본을 배치할 노드를 자동으로 선택합니다. 현재로서는 복제본이 다른 인덱스와 같은 노드에 있을 수 없다는 점만 고려하며, 인덱스와 그 복제본이 다른 그룹에 분산되어 있는지 확인하기 위해 노드의 랙 영역 인식 구성도 고려합니다. 인덱스가 배치되는 위치를 보다 구체적으로 지정하려면 관리자는 다음을 사용할 수 있습니다.
WITH {"nodes": [node1,node2]}4 - 모든 인덱스와 그 복제본은 마스터-마스터입니다.
5 - 복제본 간의 로드 밸런싱 알고리즘이 지속적으로 개선되고 있습니다. 첫 번째 릴리스에서는 라운드 로빈 방식이었지만 최근에는 지연 시간 휴리스틱을 추가하여 한 인덱스가 다른 인덱스보다 느리면 덜 사용되도록 했습니다. 앞으로도 계속 개선될 것이므로 현재 상태를 정확히 설명하기는 주저됩니다. 이 부분은 투명하게 공개하는 것이 이상적입니다.
6 - 예, 오늘은 더 높은 색인을 다시 만들어야 합니다.
num_replica를 클릭한 다음 이전 항목(DROP인덱스와 모든 복제본을 삭제하므로 수동으로 관리할 필요가 없습니다). 저희는ALTER_INDEX명령어를 사용할 수 있지만 5.0에서는 아직 준비되지 않았을 수 있으므로 여기서는 다루지 않았습니다.질문에 대한 답변이 도움이 되었기를 바라며, 더 자세한 정보를 원하시는 사항이 있으면 알려주시기 바랍니다.
카우치베이스 5.0의 출시일이 있나요?
안녕하세요, Greg! 현재 베타 버전을 개발 중이며, 보통 몇 달 후에 정식 출시할 수 있으므로 연말까지는 확실히 출시할 수 있을 것이며, 그 이전에도 출시할 수 있을 것입니다.
인덱스 생성 후 복제본 수를 조정할 수 있나요? 사용 사례는 추가 필드가 있는 큰 MOI를 확장하는 것입니다. 새 확장 인덱스와 기존 인덱스를 동시에 처리하기에는 인덱스 RAM이 너무 작을 수 있기 때문에 이러한 상황에서 이 워크플로우를 사용했습니다:
- 첫 번째 인덱스 노드에서 "수동" 인덱스 복제본을 삭제했습니다. 두 번째 복제본이 있는 다른 인덱스 노드는 여전히 인덱스 요청에 응답할 수 있습니다.
- 첫 번째 인덱스 노드에 새 인덱스를 구축합니다. 완료되면 이 노드는 이 인덱스에 대한 요청에 응답할 수 있습니다.
- 두 번째 노드에서 인덱스를 삭제하고 다시 빌드합니다.
복제본 수를 조정할 수 없다면 이러한 상황에서 다운타임을 감수하거나 실제로 필요하지 않은 많은 예비 RAM을 제공해야 합니다.
안녕하세요 클라우스님, 이 개선 사항의 첫 번째 반복에서는 인덱스 생성 후 수정이 허용되지 않습니다. 그러나 다음 릴리스에서는 이 작업을 수행할 수 있는 ALTER INDEX 문을 개발 중입니다.
이러한 종류의 유지 관리/확장을 수행할 때 일시적으로라도 인덱스를 훨씬 더 엄격하게 수동으로 제어할 수 있습니다.
복제본이 있는 인덱스가 하나 있고 이를 마이그레이션/변경하고 싶다고 가정해 보겠습니다. 복제본 없이 새 임시 인덱스를 만들고, 이전 인덱스를 삭제한 다음, 복제본으로 또 다른 새 인덱스를 만들고 임시 인덱스를 삭제할 수 "있습니다". 이 방법이 특별히 우아하지는 않지만 애플리케이션을 계속 가동하고 실행하면서 두 배의 RAM을 필요로 하지 않는다는 점은 인정합니다.
[...] Couchbase 5.0 베타를 사용하면 인덱스를 생성하여 쿼리 속도를 높이고 새로운 수준으로 확장할 수 있을 뿐만 아니라 인덱스 가용성 및 관리 편의성도 개선할 수 있습니다. 생성할 인덱스 복제본의 수를 지정하기만 하면 시스템이 여러 노드, 서버 그룹, 가용성 영역에 걸쳐 인덱스 복제본의 배치를 동적으로 관리합니다. 또한 Couchbase Server 5.0은 시스템 다운타임 없이 인덱스 리밸런싱을 지원합니다. 자세한 내용은 여기를 참조하세요. [...]