이 게시물에서는 다음과 같이 카우치베이스 서버 멀티클러스터 인식(MCA) Java 클라이언트. 이 클라이언트는 Couchbase의 데이터 센터 간 복제(XDCR) 기능을 사용할 수 있습니다.
XDCR은 서로 다른 클러스터 간에 유연한 데이터 복제를 지원합니다. XDCR은 대규모 멀티 데이터 센터 배포에 중요한 기능입니다. 아래 참조에는 XDCR에 대한 몇 가지 내용이 포함되어 있습니다. MCA 클라이언트는 라이브러리 구성에 따라 이러한 개별 클러스터로 트래픽을 자동으로 리디렉션할 수 있으므로 애플리케이션 개발자는 이와 관련된 복잡한 관리의 대부분을 덜 수 있습니다.
이러한 기능 및 기타 기능을 통해 Couchbase 배포는 다양하고 강력한 고가용성 및 재해 복구 전략을 살펴보세요. 고객별 세부 사항을 자세히 알아보기 전에 다음 리소스를 살펴보고 자세히 알아보세요:
Couchbase HA/DR 소개 - 안녕하세요. 고가용성/재해 복구 문서
카우치베이스 XDCR - XDCR 문서
XDCR/MCA 웹 세미나(기술 데모 포함) - - HA/DR 웨비나
웹 세미나 튜토리얼 - XDCR로 클러스터를 단계별로 설정하기
XDCR에 대해 자세히 살펴보기 데이터 센터 간 복제(XDCR)에 대해 자세히 알아보기 by 데니스 로사
Docker를 사용하여 XDCR 설정하기 - 도움말 Couchbase XDCR을 사용하여 데이터센터 간 NoSQL 데이터 복제 by 닉 라보이
Docker를 사용한 XDCR 설정에 대한 짧은 동영상 - 참고하세요. XDCR을 사용하여 Couchbase Docker 컨테이너 간에 NoSQL 데이터 복제 - 비디오 자습서 by 닉 라보이
MCA 고객 세부 정보 요약
MCA Java SDK는 표준을 기반으로 구축됩니다. 카우치베이스 자바 SDK. 핵심 API는 대부분 표준 클라이언트의 API를 모방합니다.
- 클러스터 목록의 우선순위를 지정하는 기능입니다.
- 실패를 구성하는 요소에 대한 규칙을 제공하는 방법.
- API를 사용하여 클라이언트 인스턴스를 조정합니다.
- 관리 인터페이스.
코드 샘플을 사용하여 처음 두 가지에 대해 설명하겠습니다. 관리는 프로그래밍 방식으로 또는 JMX 인터페이스를 통해 이루어집니다. 이를 통해 관리자는 우선순위 목록에서 클러스터를 전환할 수 있습니다. 이는 이 글의 범위를 벗어납니다.
샘플 애플리케이션
MCA 클라이언트의 사용법을 설명하기 위해 간단한 샘플 애플리케이션을 준비했습니다. 이 앱은 구성 가능한 수의 스레드를 그룹으로 실행합니다. 한 그룹은 단순히 데이터베이스에서 읽고, 한 그룹은 새로운 임의의 레코드를 쓰고, 한 그룹은 문서를 읽고 수정한 다음 다시 쓰고, 한 그룹은 간단한 작업을 수행합니다. N1QL 쿼리. 이 아이디어는 클러스터에 적용할 다양한 부하를 제공하는 것입니다. In 이 웨비나에서 이 앱을 사용하여 몇 가지 간단한 클러스터 간 장애 조치 동작을 설명했습니다.
빌드 지침 및 기타 자료와 함께 전체 코드를 찾을 수 있습니다. 깃허브에서. 다음은 문서를 업데이트하는 10개의 스레드가 있는 두 개의 3노드 클러스터에 대해 실행되는 호출 예제입니다.
|
1 |
자바 -jar mca-1.0.jar -c 172.23.123.4,172.23.123.5,172.23.123.6:172.23.122.55,172.23.122.56,172.23.122.57 -b 내_버킷 -i 사용자 -p 비밀번호 -u 10 -l 통계 |
이제 코드의 주요 부분을 살펴보겠습니다.
코드 연습
이 경우 애플리케이션 코드는 하나의 메인 클래스와 몇 가지 간단한 헬퍼 클래스로 구성됩니다. MCA 클라이언트 인스턴스가 생성되면 일반 클라이언트와 거의 동일하게 사용됩니다. 그럼 이제 클라이언트 설정에 집중하겠습니다. 코드는 클러스터 기본 사항 클래스.
클러스터 노드 및 그룹화
클러스터는 명령줄에서 콜론으로 구분된 노드 그룹으로 지정됩니다(:). 각 그룹 내에서 노드 이름 또는 IP 주소는 쉼표로 구분됩니다. 암시적으로 클러스터는 우선순위에 따라 지정됩니다. 이 코드 블록은 이 간단한 형식을 세트로 나누고 각 클러스터에 대한 클러스터 사양을 생성합니다. (클러스터 사양에는 쉽게 참조할 수 있도록 ID를 포함할 수 있습니다. 여기서는 필요하지는 않지만 지적할 가치가 있습니다.)
|
1 2 3 4 5 6 7 8 |
문자열[] 클러스터 = 옵션.문자열 값("클러스터").분할(":"); 목록<클러스터 사양 사양 = new ArrayList<>(클러스터.길이); 에 대한 (문자열 클러스터: 클러스터) { 설정<String> 노드 = 배열.스트림(클러스터.분할(",")).수집(수집가.toSet()); 사양.추가(클러스터 사양.create(노드)); } |
카우치베이스 서비스 유형
조정 및 장애 모니터링에 대해서는 잠시 후에 설명하겠습니다. 서비스 유형별로 두 가지를 모두 조정할 수 있습니다. 이 예에서는 직접 키/값 검색(ServiceType.BINARY) 및 N1QL 쿼리(ServiceType.QUERY). 다음 두 줄은 나중에 사용할 서비스 유형 집합을 준비합니다.
|
1 2 |
서비스 유형.추가(서비스 유형.바이너리); 서비스 유형.추가(서비스 유형.쿼리); |
클라이언트 간 조정
다음으로 이 클라이언트의 실제 기능 차이를 살펴봅니다. 코디네이터 클라이언트 인스턴스 전반의 동작 오케스트레이션을 관리합니다. 현재는 격리된 코디네이터만 구현되어 있지만 이 경우에는 이 정도면 충분합니다. 향후에는 더 정교한 기능이 추가될 예정입니다. 하지만 모든 옵션을 살펴보면 격리된 코디네이터로도 상당한 제어가 가능하다는 것을 알 수 있습니다. 기본 옵션이 아닌 몇 가지 옵션으로 코디네이터를 만드는 방법은 다음과 같습니다.
|
1 2 3 4 5 6 7 8 |
코디네이터 코디네이터 = 코디네이터.격리(new 격리된 코디네이터.옵션() .클러스터 사양(사양) .활성 항목(사양.크기()) .failoverNumNodes(2) .은혜 기간(타임아웃) .토폴로지비헤이비어(토폴로지 비헤이비어.WRAP_AT_END) .서비스 유형(서비스 유형) ); |
코드 노트(줄 번호별):
- 만들기
격리된 코디네이터인스턴스를 구성합니다. - 이 토폴로지의 각 멤버에 대한 노드를 지정합니다.
- 활성으로 간주할 클러스터 수를 설정합니다.
- 전체 클러스터가 완전히 장애 조치되기 전에 개별 장애 노드 수를 설정합니다.
- 클러스터 전환 전 장애 발생 후 유예 기간
- 토폴로지의 끝에 도달했을 때의 동작을 선택합니다. 다른 대안으로는 끝 클러스터에 머무르거나 목록을 역순으로 진행하는 방법이 있습니다. 가장 좋은 옵션은 특정 시나리오에 따라 달라집니다.
- 관리 대상 서비스 지정
장애 감지
클라이언트는 작동하는 동안 상당히 많은 정보를 모니터링할 수 있습니다. 장애 감지기는 내부에서 발생하는 이러한 풍부한 인사이트를 활용합니다. 이를 통해 코디네이터에게 신호를 보냅니다. 그러면 코디네이터는 대응 방법을 결정할 수 있습니다.
A 트래픽 모니터링 장애 감지기 서버로 전송되는 요청을 감시합니다. 카운트할 오류(예외)의 종류, 예외의 임계값 수, 예외가 발생해야 하는 시간 간격 등을 구성할 수 있습니다. 저는 대부분 기본값을 사용하고 실패한 작업 수와 간격만 조정합니다.
또한 클라이언트는 노드와 클러스터에서 무슨 일이 일어나고 있는지 직접 파악할 수 있습니다. 이는 노드 상태 실패 감지기. 문서에 남겨두는 것이 가장 좋은 뉘앙스가 몇 가지 있습니다. 여기서는 기본값을 그대로 사용합니다.
마지막으로 다음을 사용하여 복잡한 조건 조합을 만들 수 있습니다. 연결 실패 감지기 그리고 분리실패감지기. 연결 감지기는 구성 감지기의 논리적인 "그리고"를 수행한다고 생각하면 됩니다. 연결 해제는 "또는"을 수행합니다. 어떤 장애가 발생하면 트리거하고 싶어서 트래픽 및 상태 모니터링을 분리실패감지기 를 호출하여 클라이언트에 전달할 최종 검출기 객체를 가져옵니다.
|
1 2 3 4 5 6 7 8 9 10 11 |
트래픽 모니터링 장애 감지기.옵션 트래픽 옵션 = 트래픽 모니터링 장애 감지기.옵션() .최대 실패한 작업(5) .실패 간격(60); 실패 감지기 공장<TrafficMonitoringFailureDetector> 트래픽 = 실패 감지기 공장.트래픽 모니터링(코디네이터, 트래픽 옵션); 노드 상태 실패 감지기.옵션 건강 옵션 = 노드 상태 실패 감지기.옵션(); 실패 감지기 공장<NodeHealthFailureDetector> 건강 = 실패 감지기 공장.nodeHealth(코디네이터, 건강 옵션); 분리실패감지기 공장 검출기 = 실패 감지기 공장.분리(트래픽, 건강); |
코드 노트(줄 번호별):
- 인스턴스화 및 구성
트래픽 모니터링 장애 감지기옵션 - 문제를 나타내는 데 필요한 실패한 작업 수 수정하기
- 실패를 보관할 시간 간격을 설정하세요.
- 만들기
트래픽 모니터링 장애 감지기팩토리 인스턴스에 대한 액세스 권한이 있는코디네이터를 트리거하고, 옵션 - 만들기
노드 상태 실패 감지기기본 옵션 사용 - 를 사용하여 최종 로직을 정의합니다.
분리실패감지기공장을 통해 다시
클라이언트 인스턴스화
마지막으로 클라이언트를 인스턴스화하고 이를 사용하여 버킷 인스턴스를 얻습니다. 카우치베이스에 익숙하지 않은 분들을 위해 설명하자면, 버킷은 높은 수준의 조직 추상화입니다. 테이블과 전체 데이터베이스 사이의 개념이라고 생각하시면 됩니다.
버킷 핸들은 클러스터에 대해 부하를 실행하는 데 필요한 모든 것입니다. 멀티클러스터 클라이언트 버킷을 사용하면 개별 작업에 대한 시간 제한을 지정할 수 있습니다. 간단하게 하기 위해 인터페이스를 파사드로 감싸서 모든 작업에 고정 시간 제한을 하나만 적용했습니다. 이렇게 하면 인터페이스가 표준 인터페이스와 동일해집니다.
|
1 2 3 4 |
멀티클러스터클라이언트 클라이언트 = new 멀티클러스터클라이언트(코디네이터, 검출기); 클라이언트.인증(옵션.문자열 값("id"), 옵션.문자열 값("비밀번호")); 버킷 = new 버킷 파사드(클라이언트.오픈버킷(버킷 이름, null), 타임아웃, 시간 단위.밀리세컨드); |
마무리
MCA 클라이언트를 시작하는 데 필요한 새로운 개념은 여기까지입니다. 나머지 코드는 옵션을 파싱하고 요청된 스레드를 설정한 다음 루프에서 실행하기만 하면 됩니다. 몇 가지 통계가 던져져 있습니다. 문서 작성 및 업데이트를 위한 임의의 데이터를 얻기 위해 호출을 수행하므로 이 코드는 부하를 유발하는 데 최적화되어 있지 않습니다. 하지만 Couchbase가 제공하는 성능에 대한 통찰력을 얻을 수 있습니다.
클러스터의 작동 방식과 함께 이 모든 것이 실제로 작동하는 모습을 보려면 후반부의 데모를 확인하세요. 이 웨비나.
MCA 클라이언트 버전 1.0이 최근 출시되었습니다. 이 글을 쓰는 시점에서는 현재 엔터프라이즈 에디션 전용 기능입니다. 자세한 내용을 알아보고 클라이언트에 액세스하려면 Couchbase 영업 담당자에게 문의하세요(sales@couchbase.com). 자세한 내용은 아래 설명된 대로 저에게 문의하실 수도 있습니다.
