[번역] elasticsearch 뇌 파열 시 JAVA 클 라 이언 트 의 행동

이 문장의 원문 주 소 는?http://blog.trifork.com/2013/10/31/java-clients-behavior-during-creating-a-split-brain-situation-in-elasticsearch/, 2013 년 10 월 발표
이전의 박문 은 elasticsearch 의 뇌 분열 문 제 를 어떻게 피 하 는 지 설 명 했 지만, 단지 그것 이 어떻게 발생 했 는 지 대충 말 했 을 뿐이다.이번 에는 뇌 파열 이 발생 했 을 때 색인 과 조회 요청 이 어떻게 되 는 지 자세히 말씀 드 리 겠 습 니 다.나 는 네가 이미 알 고 있다 고 생각한다. 이것 은 상황 에 달 려 있다!이것 은 당신 이 어떤 유형의 클 라 이언 트 를 사용 하 느 냐 에 달 려 있 습 니 다.자바 에 익숙 하기 때문에 저 는 elasticsearch 가 지원 하 는 자바 API 로 두 가지 유형의 클 라 이언 트 를 쓸 것 입 니 다. transport 클 라 이언 트 와 node 클 라 이언 트 입 니 다.
시 뮬 레이 션 뇌 분열 문제
우선 Oracle 의 Virtual Box 로 Ubuntu 13.10 을 달 리 는 가상 컴퓨터 두 개 를 시작 하 겠 습 니 다.네트워크 에 설 치 된 'Bridged Adapter' 모드 를 사용 하여 나 는 '가상' 의 elasticsearch 클 러 스 터 를 빠르게 시작 했다.
하나의 독립 적 인 블록 을 만 들 고 하나의 독립 적 으로 색인 을 복사 한 후에 나 는 두 개의 자바 애플 릿 을 써 서 두 개의 독립 된 스 레 드 (하나의 색인 하나의 조회) 로 문 서 를 계속 색인 하고 새로 생 성 된 색인 으로 조회 했다.
나 는 뇌 파열 을 모 의 하기 위해 iptables 에 rule 을 추가 하여 두 기계 간 의 통신 을 막 았 다.

iptables -A INPUT -s 192.168.0.1 -j DROP
iptables -A OUTPUT -d 192.168.0.1 -j DROP

약 200 개의 문 서 를 색인 한 후에 나 는 이상 의 명령 을 집행 했다.같은 테스트 를 두 번 했 습 니 다. 한 번 은 transport 클 라 이언 트 를 사용 하고 한 번 은 node 클 라 이언 트 를 사용 합 니 다.모든 테스트 는 0.90.5 버 전의 elasticsearch 를 사용 합 니 다.
transport 클 라 이언 트 의 테스트
예상 치 못 하 게 (transport 클 라 이언 트 는 클 라 이언 트 에 대해 감지 되 지 않 음) 두 노드 간 의 통신 차단 을 색인 과 조회 에 오류 가 발생 하지 않 았 습 니 다.내 가 iptables exclusion 을 실행 한 후에 elasticsearch 는 거의 1 분 동안 상대방 이 응답 하지 않 았 다 는 것 을 결정 했다.그 동안 transport 클 라 이언 트 는 모든 정렬 과 조 회 를 중단 했다.코드 에 시간 을 초과 하지 않 았 기 때문에 모든 요청 은 elasticsearch 가 사용 가능 한 클 러 스 터 로 돌아 오 기 를 조용히 기다 리 고 있 습 니 다.예상대로 모든 노드 가 자신 을 위주 로 선 거 했 기 때문에 현재 모든 노드 는 색인 을 독립 적 으로 복사 하고 있다.
색인 과 조회 요청 은 모든 노드 에 무 작위 로 요청 합 니 다.실행 기간 동안 각 색인 요청 은 두 개의 색인 이 분리 되 었 다 는 것 을 보고 하지 않 았 다.실패 와 경 고 를 관찰 하지 못 했 습 니 다. - 클 라 이언 트 의 시각 으로 전체 테스트 기간 동안 모든 것 이 정상 입 니 다.
node 클 라 이언 트 테스트
node 클 라 이언 트 가 elasticsearch 클 라 이언 트 에서 노드 (node) 를 만 들 었 기 때문에 이번 테스트 는 transport 클 라 이언 트 의 결과 와 다 를 것 이 라 고 기대 합 니 다.iptables 명령 을 실행 한 후 색인 요청 이 완전히 중단 되 었 으 나 조회 요청 은 여전히 실행 되 고 있 으 며, round robin 형식 으로 두 노드 사이 에서 발생 합 니 다.다른 결 과 를 되 돌려 달라 고 요 청 했 습 니 다. 제 가 두 개의 분 편 간 의 통신 을 끊 었 을 때 분 편 과 메 인 분 편 을 복사 하여 동기 화 를 잃 었 습 니 다.
두 노드 가 상대방 이 이미 효력 을 잃 었 음 을 결정 할 때 node 클 라 이언 트 는 무 작위 로 그 중의 한 좌석 의 새로운 클 러 스 터 메 인 노드 를 선택 했다.그때 부터 모든 색인 과 조회 요청 은 이 새로운 메 인 노드 를 가 리 켰 다.마찬가지 로 테스트 기간 에 실 패 를 관측 하지 못 했 지만 node 클 라 이언 트 는 메 인 노드 (INFO 급 로그) 를 전환 했다 고 보고 했다.
node 클 라 이언 트 가 뇌 분열 이 발생 한 후에 한 노드 만 가리 키 기 때문에 두 인덱스 의 복사 본 은 분열 되 지 않 았 지만 그 중 하나만 최신 입 니 다.나 는 이것 이 node 클 라 이언 트 가 transport 클 라 이언 트 에 비해 장점 이 라 고 믿는다.
그럼 클 러 스 터 리 셋 은 요?
뇌 균열 이 발생 한 후 유일한 복구 방법 은 이 문 제 를 해결 하고 군집 을 재 개 하 는 것 이다.여 기 는 좀 복잡 하고 무섭다.elasticsearch 클 러 스 터 가 시 작 될 때 메 인 노드 를 선택 합 니 다.색인 의 두 부 복사 가 다 르 기 때문에 elasticsearch 는 선택 한 주 보존 필름 이 '주 복사' 라 고 생각 하고 이 복사 본 을 클 러 스 터 의 다른 노드 에 보 냅 니 다.심각 해.node 클 라 이언 트 를 사용 하고 한 노드 가 색인 에 있 는 정확 한 데 이 터 를 보존 하고 있다 고 생각해 봅 시다.그러나 다른 노드 가 먼저 시작 되 고 선택 되 는 것 을 위주 로 한다 면 만 료 된 색인 데 이 터 를 다른 노드 에 보 내 고 덮어 쓰 면 효과 적 인 데 이 터 를 잃 게 됩 니 다.
결론.
그래서 어떻게 뇌 파열 에서 회복 합 니까?첫 번 째 제안 은 모든 재 색인 데 이 터 를 백업 하 는 것 입 니 다.둘째, 뇌 파열 이 발생 하면 조심스럽게 군집 을 재 개 해 야 한다.모든 노드 를 멈 추고 어느 노드 가 첫 번 째 로 시작 할 지 결정 합 니 다.필요 하 다 면 각 노드 를 단독으로 시작 하고 저 장 된 데 이 터 를 분석 합 니 다.유효 하지 않 으 면 끄 고 데이터 디 렉 터 리 의 내용 을 삭제 합 니 다 (삭제 하기 전에 백업 을 합 니 다).데 이 터 를 저장 하고 싶 은 노드 를 찾 으 면 로 그 를 시작 하고 주 노드 로 선택 되 었 는 지 확인 하 십시오.그 후에 당신 은 클 러 스 터 의 다른 노드 를 안전하게 시작 할 수 있 습 니 다.
글 은 위 챗 플랫폼 '엿기름 빵' 에서 왔 습 니 다.만약 문장 이 재미있다 면, 위 챗 은 QR 코드 를 찍 어 나 를 주목 해라.