[zookeeper] snapshot data(version-2) 정리 (update 240402)

총 8번의 테스트를 진행 했고(24.03.19) 중간에 형상과 버전을 바꿨다.

 - 앞에 4번은 kafka 3.6.1 + apache zookeeper 3.8.3 (별도)

 - 뒤에 4번은 kafka 3.7.1 + 해당 kafka에 있는 zookeeper(3.8.3) 사용

 

6번은 broker/zookeeper 서비스(이하 "서비스")를 내린 상태에서 데이터 삭제 후 기동

2번은 서비스를 기동한 상태에서 데이터 삭제 후 broker만 기동* 으로 진행 했다.

*data 디렉토리 날린 broker가 강제로 shutdown 되었음. zookeeper는 down 되는 상황 없었음.

 

결론은, 서비스가 죽지 않은 상태에서 topic 데이터 디렉토리가 날아갈 경우 파티션 데이터는 복제/복구가 된다.

(replica가 설정 되어있는 topic에 한해서)

문제가 발생되는건 zookeeper와 kafka broker가 전부 내려가있을 때 데이터 삭제가 됐을 경우인데,

이때는 zookeeper에서 파티션 형상을 복구만 해줄 뿐 데이터 내용까지 복구해주지 않는 것이다.

구분	#	테스트	결과	비고
서비스 내리고 나서 데이터 삭제 후 기동	1	3대 broker의 kaf_data 전부 삭제 후 기동	zookeeper snapshot data 로의 복구는 껍데기만 복구되며, 기존의 offset 값을 알 수 있는 파일이 없어 kafka data, consumer offset data 모두 baseoffset 0부터 시작함.
	2	2대 broker의 kaf_data 전부 삭제, 1대 broker kaf_data 유지 시킨 뒤 기동	전체 재기동의 문제였는지 위 테스트와 동일하게 3대 브로커에서 모두 초기화 되었음.
서비스 기동 상태에서 데이터 삭제 후 기동/재기동 조치	3	broker1 data 디렉토리 삭제 후 확인	데이터 삭제한 broker1 에서 kafka down 발생. (뒤늦게 확인) down 발생 내역을 모르고 데이터 produce, consume 진행. 기존 consume data가 broker1의 consume_offsets_20 에서 생성 되어서 consume data는 broker1, broker2에선 신규로 생성 되진 않았음. 이후 broker1 기동 후 consume_offsets_20에 파일 생성, offsets은 0부터 시작함. data 영역은 replication 되어 기존 데이터 유지됨을 확인.	offsets.topic.replication.factor=1 을 broker 수 만큼 바꾸면 consumer_offsets도 replication 된다.
	4	broker 1,2 data 디렉토리 삭제 후 확인	상동.  애초에 consumer_offsets 자체가 각 브로커별로 복제가 되는 형상이 아닌 각각 생성되는 부분임.

chatGPT에게 : zookeeper 의 snapshot 데이터로는 파티션 데이터 복구 안돼?   일반적으로 ZooKeeper의 스냅샷 데이터는 Kafka 파티션 데이터의 복구에 직접적으로 사용되지 않습니다. ZooKeeper는 Kafka 클러스터의 메타데이터와 상태를 관리하는 데 사용되며, 주로 브로커의 메타데이터, 토픽, 파티션 할당 등을 저장합니다. 이러한 메타데이터는 Kafka 클러스터를 구성하고, 클러스터 내의 브로커들이 서로 통신하고 조정하는 데 사용됩니다. 파티션 데이터의 복구는 주로 Kafka 브로커들 간의 데이터 복제와 리더-팔로워 관계를 통해 이루어집니다.  리더 브로커에 있는 파티션의 데이터가 손실되었거나 손상되었을 때, Kafka는 해당 파티션의 복제본 중 하나를 리더로 선정하여 데이터를 복구합니다.  이러한 과정에서 ZooKeeper의 역할은 주로 파티션의 리더 선출과 브로커의 동적 구성 변경을 조정하는 데에 있습니다. 따라서 ZooKeeper의 스냅샷은 주로 Kafka 클러스터의 구성 및 상태를 복원하는 데 사용되며,  파티션 데이터의 복구는 주로 Kafka 내부에서 데이터 복제 및 리더-팔로워 관계를 통해 이루어집니다.

 

 

[zookeeper snapshot 테스트]

 

 ** 중간에 35번글과 37번글을 나누는 바람에 

https://abbf.tistory.com/37

[zookeeper] zookeeper snapshot

https://abbf.tistory.com/35

[zookeeper] snapshot data(version-2) 관련 테스트 (1)

https://abbf.tistory.com/38

[zookeeper] snapshot data(version-2) 관련 테스트 (3)

 

https://abbf.tistory.com/39

[zookeeper] snapshot data(version-2) 관련 테스트 (3)

 

 

테스트 진행 시 복제 config값에 있어 전부 default인 1로 되어있어서,

브로커 갯수만큼 변경한 경우로도 재 테스트 해야 할 것 같다.

consumer_offset 파일이 각 broker별로 나눠서 생성되는데, 옵션 건드리면 통으로 다 생길것 같은 느낌이든다.

[관련 옵션 항목]

• offsets.topic.replication.factor=1:
  This option specifies the replication factor for the internal Kafka topic that stores consumer offset commits. Each Kafka topic can be replicated across multiple Kafka brokers for fault tolerance. Setting it to 1 means that only a single copy of the offset topic is maintained, which makes the system vulnerable to data loss if the broker holding that copy goes down. However, it can be acceptable in certain setups, such as development or single-node deployments, where high availability is not a primary concern.
• transaction.state.log.replication.factor=1:
  This option defines the replication factor for Kafka's transaction state log topic. Kafka uses transactional messaging to ensure that messages are either consumed or produced atomically. Similar to the offsets.topic.replication.factor, this configuration sets the replication factor for the internal topic that Kafka uses to manage transaction state. Again, setting it to 1 means there's only one copy of this topic, which can be risky in production environments where fault tolerance is crucial.
• transaction.state.log.min.isr=1:
  This option determines the minimum number of in-sync replicas (ISR) required for the transaction state log topic before a transaction is committed. In Kafka, when a message is produced, it is first written to the leader replica, and then replicated to follower replicas. Only when the message is successfully replicated to a certain number of in-sync replicas (as specified by this configuration) is the transaction considered committed. Setting it to 1 means that only one in-sync replica needs to acknowledge the write for the transaction to be considered committed. This can increase the risk of data loss in case of broker failures, but it may be acceptable in setups where high throughput is prioritized over durability. Increasing this value can enhance durability at the cost of potentially slower performance.

 

3개 옵션 중 transaction으로 시작하는 2개 옵션은 produce 에서 transaction api를 사용해야지 확인할 수 있는 것으로 파악되었다. 

그리고 offsets.topic.replication.factor는 확인해보니,

broker data dir에 __consumer_offsets 의 디렉토리 replication 값이었다.

이게 계속 1이어서 3개의 broker에 50개가 되는 consumer_offsets 디렉토리가 뿜빠이 되어 생성 되었는데,

저 옵션을 3으로 바꿔줬더니 3개의 브로커에 0~49번까지 전부 생성 및 복제 되었다.

이로써 consumer_offsets 값도 서비스가 살아있을 때 복제 되어 offsets값이 리셋되지 않는다.