Node 제거 후 kudu에서의 leader election 문제 및 해결

Kudu 0.9.1 버전을 사용하였다.

Kudu를 사용 중에 cluster의 노드를 6개에서 3개로 줄이게 되었다.

그 이후로 kudu가 정상동작하지 않아서 로그를 살펴보았더니 계속해서 leader를 선출하려고 시도하고 있었다. 그리고 제거한 다른 3개의 노드에 계속해서 접근 시도를 하였다.

Cloudera community에도 글을 올려서 문제점을 찾으려 노력하였다. (아래 url에서 확인할 수 있다.)

https://community.cloudera.com/t5/Beta-Releases-Apache-Kudu/Problem-with-kudu-flume-sink/m-p/44553#M265

kudu가 정상적으로 동작하지도 않고 서비스를 올려둔 상태로 두면 로그 파일 용량만 급격히 증가하여 문제가 발생하므로 한 동안 서비스를 중지해두었다. 

HBase 문제등 다른 사항들을 먼저 처리하면서 시간이 흘렀다.

우선순위가 높은 문제들을 처리한 뒤, 다시 kudu를 살펴보기 시작하였다. 문득, kudu에 생성한 테이블을 삭제하면 어떨까란 생각이 들었다. 왜냐하면 해당 테이블은 노드가 6개일 때 생성된 테이블이므로 cluster에서 제거된 노드의 정보를 가지고 있어서 문제가 될 수도 있겠구나란 생각이 들었기 때문이다.

테이블을 삭제하였다. (어차피 테스트 데이터라 상관없었음) 그랬더니 leader를 선출하는 시도를 더 이상 하지 않게 되었다.

이러한 내용을 cloudera community에 올리니 답변이 왔다. 답변은 kudu를 지속적으로 서비스하기 위해서는 단순하게 node를 제거해서는 안된다였다. 그냥 node를 제거하면 데이터를 잃거나 서비스가 비정상적으로 될 수 있다고 하였다.

안전하게 node를 제거하기 위해서는 제거하려는  node를 5분 간격으로 shut down하여 완전하게 kudu cluster에서 삭제되도록 하라는 것이었다. 이를 빨리 하려면 --follower_unavailable_considered_failed_sec 값을 master에서 2 또는 3 같은 작은 값으로 설정하여 process 속도를 빠르게 하라는 방법도 알려주었다.

아래 글은 해당 답변 원문이다.

‎08-30-2016 06:17 PM Hi Park, you cannot simply remove half of the nodes and expect Kudu to keep running. It's likely that you will lose data. Imagine you have the following scenario:  2 tablets (I, II), 6 tablet servers (A, B, C, D, E, F)  Imagine also you have 3 replicas each. Imagine that, by luck, you have the following replicas hosted on tablet servers:  tablet I (A, B, C) and tablet II (D, E, F)  Now, take tablet servers D, E, F offline. There are no copies of tablet II and Kudu will not be able to operate. That table cannot recover.  Kudu is even more strict than that. It can only operate if a majority of the replicas remain online. One replica is not enough to recover if the replication factor is higher than 1.  We still need to create safe decommission tools for Kudu. Right now, you will have to shut down one machine every 5 minutes (by default) to get the effect of removing nodes from the cluster permanently in a safe manner. To work around this, you could set --follower_unavailable_considered_failed_sec on the master to a shorter value, say 2 or 3 minutes or something, to speed up the process: http://kudu.apache.org/docs/configuration_reference.html#kudu-master_follower_unavailable_considered... Hope this helps, Mike

아직 kudu에서는 노드를 제거하는 부분에서의 처리가 미흡한 부분이 있는 것으로 보인다.