Kudu 1.7 사용 할 수 없 는 태 블 릿 복제 복구
어제 Solr 설정 을 수 정 했 습 니 다. Solr 를 다시 시작 한 결과 두 대의 kudu server 가 떨 어 진 것 을 발 견 했 습 니 다. 로 그 를 보 니 파일 핸들 이 너무 많아 서 그런 것 같 습 니 다.그러나 쿠 두 의 데이터 가 너무 많 고 container 가 너무 많 으 며 full container 가 적 기 때문에 쿠 두 서버 를 다시 시작 하 는 것 이 매우 느 려 서 log 를 계속 합 니 다.block_manager, 이것 은 이미 알 고 있 는 bug 로 인 한 것 입 니 다.https://issues.apache.org/jira/browse/KUDU-2014이 jira 에 대해 서도 대처 하 는 방법 이 있 습 니 다. 바로 어느 노드 의 kudu server 재 부팅 이 느 리 면 30 분 동안 닫 고 다시 열 어서 log 를 기다 리 는 것 입 니 다.block_manager 가 끝 난 후에 webui 에 가서 이 노드 가 실행 중인 Tablet 이 없 는 것 을 본 후에 (즉, 모두 날 아 갔다) cloudera manager 에서 이 노드 를 삭제 하고 시스템 하 드 디스크 에 저 장 된 데 이 터 를 모두 제거 한 다음 에 이 노드 를 다시 추가 하고 REBALANCE 를 한 번 하면 나중에 이 노드 를 다시 시작 하면 빨 라 집 니 다.
다시 시작 해서 logblock_manager 가 너무 느 리 고 회복 시간 이 예측 할 수 없 기 때문에 다른 방식 을 사용 합 니 다. 즉, 이 두 노드 를 시작 하지 않 고 ksck 검 측 표 의 건강 상 태 를 먼저 확인 합 니 다.
sudo -u kudu kudu cluster ksck master1,master2,master3 -verbose > ./ksck.out 2>&1
56 :
==================
Errors:
==================
table consistency check error: 56 out of 183 table(s) are not healthy
:
ksck.out tablet :
The consensus matrix is:
Config source | Replicas | Current term | Config index | Committed?
---------------+--------------+--------------+--------------+------------
master | A B C* | | | Yes
A | A B C* | 1427 | 2450 | Yes
B | A B C* | 1427 | 2450 | Yes
C | A B C* | 1427 | 2450 | Yes
Tablet 3689e076ed354f94a0967d1eed4b7d16 of table 'impala::dl_zz_kudu.tm_scada_hdzysj_change' is unavailable: 2 replica(s) not RUNNING
868688d5077b4e02b14a8a0a57958668: TS unavailable
0b4f24052ed74405b5d58fecd83f33e7: TS unavailable
a59cf0d8d1ed45d8b1af094f4a28d686 (xxxxx:7050): RUNNING [LEADER]
0 replicas' active configs differ from the master's.
All the peers reported by the master and tablet servers are:
A = 0b4f24052ed74405b5d58fecd83f33e7
B = 868688d5077b4e02b14a8a0a57958668
C = a59cf0d8d1ed45d8b1af094f4a28d686
a59cf0d8d1ed45d8b1af094f4a28d686 replication , 。
:
sudo -u kudu kudu remote_replica unsafe_change_config xxxx:7050 3689e076ed354f94a0967d1eed4b7d16 a59cf0d8d1ed45d8b1af094f4a28d686
그리고 ksck. out 에 따라 문제 가 생 긴 tablet 을 모두 캡 처 하여 모두 이 복구 명령 으로 연결 하여 하나의 sh 에서 실행 하고 ksck 으로 검사 하면 됩 니 다.
마지막 으로 이 두 쿠 두 서버 의 데 이 터 를 모두 지우 고 다시 가입 하고 리 바 란 스 를 한 번 더 하면 됩 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
spark 의 2: 원리 소개Google Map/Reduce 를 바탕 으로 이 루어 진 Hadoop 은 개발 자 에 게 map, reduce 원 어 를 제공 하여 병렬 일괄 처리 프로그램 을 매우 간단 하고 아름 답 게 만 들 었 습 니 다.S...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.