카프카는 파티션 갯수를 늘리고 다시 줄일수 없다고 해서

토픽을 삭제 후 다시 생성하기 위해

kafka-topics.sh 를 통해(window에서 테스트를 해서 실제로는 .bat)

topic을 삭제 했습니다.

그런데. . kafka 브로커가 다운되더니.. 부팅되지 않는 문제가 발생하기 시작했습니다.

(부팅시 에러는 삭제한 토픽 파일을 읽는데 파일 권한에러..인데.. 전혀 접근 권한 문제 일으킬만한건 없습니다)

그래서 이런저런 글들을 살펴보며 겪은 부분들을 남깁니다...

먼저 delete.topic.enable=true

를 설정 하지 않아서 kafka-topics로 삭제했을때 마크만 된 상태였습니다.

그래서 위 설정을 해줬지만 마찬가지로 정상 부팅은 되지 않았습니다

(지금 생각해보니 설정을 하고 kafka-topics로 다시 삭제를 해볼껄 그랬나봅니다..)

(그런데.. 생각해보니 kafka-topics로 삭제할때 IP:PORT는 zookeeper쪽을 입력해줬는데.. 의미가 있나.. 싶네요)

두번째로 시도한건 recovery-point-offset-checkpoint, replication-offset-checkpoint 수정 입니다.

글을 보니 다른 브로커로 파티션 옮길때 수정하는 것으로 보이던데

이 방법을 시도해본 이유는 

"나는 토픽을 삭제했는데 왜 해당 토픽 관련 에러가 나는것인가?, 해당 토픽 내용들을 다 삭제해야 겠다"

였습니다.

파일 구조는 recovery~~~나 replication~~ 이나 거의 유사 했고

0
59
__consumer_offsets 22 0
__consumer_offsets 30 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 4 0
__consumer_offsets 27 0
__consumer_offsets 7 0
__consumer_offsets 9 0
__consumer_offsets 46 0
topic3 0 0
__consumer_offsets 25 0
__consumer_offsets 35 0
__consumer_offsets 41 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 49 0
topic2 0 0
__consumer_offsets 47 0
__consumer_offsets 16 0
__consumer_offsets 28 0
__consumer_offsets 31 0
__consumer_offsets 36 0
__consumer_offsets 42 28
__consumer_offsets 3 0
__consumer_offsets 18 0
__consumer_offsets 37 0
bars 0 0
__consumer_offsets 15 0

이런식이였습니다, 자세한 정보를 추가로 찾아봐야겠지만

두번째 줄에 59는

두줄을 빼고 데이터부가 59라인이 있다는것을 말합니다.

(결국 마지막 데이터 줄은 61라인)

그래서 삭제할 토픽의 데이터의 offsets 디렉토리 정보와 토픽 정보를 라인을 삭제하고 두번째 라인에서 값을 빼줬습니다.

그후, 부팅해보니 수정했던 replication-offset-checkpoint 가 다시 삭제했던 내용들을 복원해놓고 있었습니다

(대체 토픽정보를 어디서 복원을 하는거지.. 레플리카 구성한것도 아니고..)

마지막 세번째, 파일들은 대략 다 열어 봤고 마지막 의심가는건 zookeeper밖에 없었습니다

zookeeper 데이터를 찾아보니 /brokers/topics 에 삭제했던 topic 정보가 남아있었습니다

rmr /brokers/topics/대상토픽

으로 삭제하고 

replication-offset-checkpoint를 수정 후

broker를 띄우니 잘 뜨는것을 확인했습니다.

지금은 토픽을 그냥 삭제하는데 발생한 이슈였지만.. 운영중에 갑작이 이렇게 부팅이 안되는 문제가 발생하면.....;;;;

kafka를 사용하는 방법도 더 해봐야겠지만

내부 파일 구조 체계들을 알아둬야 이런 난감한 상황에 잘 대처 할 수 있을것 같습니다

Zookeeper는 Zookeeper 단독으로도 사용되지만, 하둡이나 카프카 등 여러 다른 시스템들과 함께 활용되고 있지만

저의 경우에는 Zookeeper 자체에서 어떤 기능들을 제공하는지 조차 모르고 사용하기도 했습니다.

그래서 조금씩 파악중이며 조금씩 수정해갈 예정입니다.

Zookeeper는 기본적으로

• 메타 저장소

• 데이터 변화 감시를 위한 Watcher

• 데이터 snyc 혹은 분산 어플리케이션을 위한 lock 제공

• 간단한 설정을 통한 클러스터 지원
  와 같은 기능들을 제공하며(이것 말고도 많겠지만)

  참고로 메타는 각 노드에 저장되며, 노드는 트리구조로 되어있고, 트리를 쉽게 접근할수 있도록 파일시스템과 같이 접근할 수 있습니다(/data/node1/info).

  그리고 노드도 여러가지 종류들을 제공합니다.

  • Ephemeral Nodes
    • 세션동안 유지되는 노드, 연결이 끊어지면 삭제
  • Sequence Nodes
    • 고유명을 위한 노드
  • Container Nodes
    • 락을 위한 노드(3.5.3에 추가됬다고 하는데 사용을 아직 못해봤네요)
  • TTL Nodes
    • 마찬가지로 3.5.3에 추가

분산 어플리케이션들은 보통 Zookeeper의 클라이언트가 되고, Connection을 지속적으로 유지하고 있습니다.

Zookeeper에서 데이터 변화 감지를 위해 Watcher를 제공하기 때문에 polling을 하며 감시 할 필요 없이
동작만 CallBack 코드만 작성해 두면 되기에 훨씬 간결해 질 수 있습니다.

Watcher의 경우 노드 하나 변화에 Wacher를 설정할 수 있고, 노드 하위에 변화에도 대해 설정 할 수 도 있습니다.

• 데이터 변화에 대한 Watcher
  • get -w /data
• 데이터 하위 생성에 대한 Watcher
  • ls -w /data

Zookeeper를 활용하여 할수 있는 것들은 많겠지만
일단 간단하게 구현 해본 부분은 "분산 어플리케이션에서 서로의 노드 추가 삭제 감지 에 따른 동작"
상위 Node를 하나 생성하고, 어플리케이션마다 하위에 ephemeral + sequence Node를 생성하고
서로 상위 Node를 Watcher 하게 하면
간단히 분산 어플리케이션에서 어플리케이션 변화를 감지 할 수 있고
Watcher 코드에 대응되는 동작을 넣는것으로 간단히 "분산 어플리케이션 상황에서 각 어플리케이션 감지 및 동작" 을 처리 할 수 있습니다.

해당 글은 Zookeeper를 살펴보거나 사용할 때 마다 기록을 위해 업데이트 할 예정입니다.