Kudu 테이블은 파티션 규칙에 따라 여러 태블릿으로 쪼개진다. 태블릿 하나가 복제의 단위이며, 각 태블릿은 서로 다른 tablet server 에 놓인 복제본 집합(보통 3개)을 갖는다. 복제본 집합은 Raft 합의로 운영되어 하나가 리더, 나머지가 팔로워가 된다.
복제 계수는 테이블 단위로 정한다. Impala 에서는 다음 속성으로 지정한다.
CREATE TABLE db.tbl (
id BIGINT,
v STRING,
PRIMARY KEY (id)
)
PARTITION BY HASH (id) PARTITIONS 8
STORED AS KUDU
TBLPROPERTIES ('kudu.num_tablet_replicas' = '3');
REPLICAS 3 같은 구문은 존재하지 않는다. 복제 계수는 홀수여야 하며, 지정하지 않으면 --default_num_replicas(기본 3)를 따른다.
쓰기는 항상 리더 복제본으로 간다. 리더는 연산을 자신의 WAL 에 기록하고 동시에 팔로워에게 복제한다. 과반이 기록을 마치면 커밋으로 판정하고 클라이언트에 성공을 돌려준다. 3개 복제본이면 리더 포함 2개가 기록하면 성공이다. 나머지 하나가 늦어도 쓰기는 진행되며, 그 복제본은 이후 따라잡는다.
읽기는 기본적으로 리더에서 처리한다. 스캔 모드에 따라 팔로워에서 읽을 수도 있으나, 일관성 수준이 달라진다.
플래그 이름을 잘못 알고 있으면 적용해도 아무 일이 일어나지 않으므로, 반드시 실제 존재하는 이름인지 확인하고 쓴다.
kudu tserver get_flags <tserver>:7050 | grep -E "raft|consensus|follower"
| 플래그 | 기본값 | 의미 |
|---|---|---|
--raft_heartbeat_interval_ms |
500 | 리더가 팔로워에게 보내는 heartbeat 주기 |
--leader_failure_max_missed_heartbeat_periods |
3.0 | 이 배수만큼 heartbeat 를 놓치면 선거를 시작한다. 실질 선출 타임아웃은 주기 × 배수 |
--consensus_rpc_timeout_ms |
1000 | 합의용 RPC 의 기한 |
--follower_unavailable_considered_failed_sec |
300 | 팔로워를 실패로 판정하고 구성에서 제거하기까지의 시간 |
--consensus_max_batch_size_bytes |
1MiB 수준 | 리더가 한 번에 팔로워로 보내는 최대 크기 |
--raft_prepare_replacement_before_eviction |
true | 대체 복제본을 먼저 준비한 뒤 실패 복제본을 제거한다 |
raft_rpc_timeout_ms · raft_follower_unresponsive_timeout_ms · raft_commit_wait_time_ms 같은 이름은 Kudu 에 없다. 인터넷 문서에 자주 등장하지만 적용해도 무시된다.
heartbeat 주기를 늘리면 네트워크 트래픽은 줄지만 장애 감지가 그만큼 늦어진다. 기본값에서 벗어날 이유는 대체로 네트워크 지연이 크게 변동하는 환경 정도이고, 전 노드에 동일하게 적용해야 한다.
kudu cluster ksck <master-addresses>
kudu cluster ksck <master-addresses> --tables=<table>
curl -s http://<master>:8051/tablet-servers
ksck 가 보고하는 상태 중 주의해서 볼 것은 리더 없는 태블릿, 복제 부족(under-replicated), 따라잡지 못한 복제본이다. 셋 중 하나라도 지속되면 그 태블릿은 실질적으로 내구성이 낮아진 상태다.