라이언(Ryan)의 블로그

출처
​https://stackoverflow.com/questions/52970153/kafka-how-to-avoid-running-out-of-disk-storage

Kafka 디스크 저장공간의 부족을 피하는 방법

우리의 production cluster 중 하나는 다음과 같은 경우입니다.
우리는 HDP version 2.6.4로 ambari cluster가 있습니다.
Cluster는 3개의 Kafka 머신으로 각 Kafka 디스크는 5 T(테라바이트) 입니다.
우리가 확인한 것은 모든 kafka 디스크는 100% size였고, kafka disk는 가듣 찼고, 이는 모든 kafka broker가 실패하는 이유입니다.

df -h /kafka
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb         5T   5T   23M   100% /var/kafka

조사 후 우리는 log.retention.hours=7 days를 확인했습니다.

따라서 제거는 7일 이후에 하는 것으로 보이며 이것이 카프카 디스크 5 T(테라바이트)로 용량이 큰 경우에도 100% 가득찬 이유일 수 있다 봅니다.
우리가 하고 싶은 것은 앞으로 이러한 현상을 피하는 방법입니다.

그래서
우리는 Kafka 디스크의 전체를 사용하지 않도록 피하는 방법과
디스크 크기에 따라 Kafka 디스크를 제거하기 위해 Kafka config에서 설정해야 하는 것들을 알고 싶습니다.
그리고 디스크 크기 또는 기타에 따라 log.retention.hours의 올바른 값을 아는 방법은 무엇입니까?

2개의 답변 중 1개의 답변만 추려냄

Kafka에는 두 가지 유형의 로그 보존이 있습니다. 크기와 시간 보존. 전자는 log.retention.bytes에 의해 작동되고 후자는 log.retention.hours에 의해 작동됩니다.

경우에 따라 구성하기가 까다로울 수 있는 크기 보존에 주의해야 합니다. 삭제(delete) 정리 정책을 원한다고 가정하면 다음 매개 변수를 구성해야합니다.

log.cleaner.enable=true
log.cleanup.policy=delete

그런 다음 log.retention.bytes, log.segment.bytes 및 log.retention.check.interval.ms 의 구성에 대해 생각해야 합니다. 그렇게 하려면 다음 요소를 고려해야 합니다.

• log.retention.bytes는 한 topic의 단일 파티션에 대한 최소 보증입니다. 즉, log.retention.bytes를 512MB로 설정하면 디스크에 항상 파티션 당 512MB의 데이터가 있음을 의미합니다.
• 다시 한 번, log.retention.bytes를 512MB로 설정하고 log.retention.check.interval.ms를 5 분 (기본값)으로 설정하면 최소한 512MB의 데이터 + (보존 정책이 트리거되기 전에 ) 5 분 윈도우 시간동안 생산된 데이터 크기가 됩니다.
• 디스크의 topic 로그는 세그먼트로 구성됩니다. 세그먼트 크기는 log.segment.bytes 매개 변수에 따라 다릅니다. log.retention.bytes=1GB 및 log.segment.bytes=512MB 의 경우, 항상 디스크에 최대 3 개의 세그먼트 (보존에 도달하는 2 개의 세그먼트가 있고 세 번째 세그먼트는 현재 데이터가 기록되는 활성 세그먼트임)가 됩니다.

마지막으로, 계산을 수행하고 디스크의 특정 시간에 Kafka 로그에 예약 될 수있는 최대 크기를 계산하고 위에서 언급한 매개 변수를 적절히 조정해야 합니다. 물론 시간 보존 정책도 설정하고 그에 따라 log.retention.hours를 구성하는 것이 좋습니다. 2일 후에 더 이상 데이터가 필요하지 않으면 log.retention.hours=48 로 설정하십시오.

출처
​ https://stackoverflow.com/questions/48320672/what-is-difference-between-kafka-earliest-and-latest-offset-values

Kafka earliest와 latest offset 값의 차이점이 무엇입니까?

producer는 1, 2, 3, 4 메세지를 보냅니다.
consumer는 1, 2, 3, 4 메세지를 받습니다.
consumer는 충돌/접속을 끊었습니다.
producer는 5, 6, 7 메세지를 보냅니다.
consumer는 돌아와서 7 대신에 5부터 메세지를 받아야 합니다.
결과에 이러한 종류의 문제에 대해 어떤 제가 사용해야 할 offset값이 무엇이고 다른 변경사항/설정이 필요한 게 무엇이 있을까요?

1개의 답변 중 1개의 답변만 추려냄

consumer가 consumer group에 join(가입)할 때 그것은 마지막에 commit된 offset을 가져오므로 그 consumer는 충돌하기 전에 commit된 최근 offset(4 이므로) 5,6,7부터 읽을 것입니다. auto.offset.reset property의 earliest와 latest값은 지정한 partition에 commit된 offset이 없을 때 consumer가 시작할 때 사용됩니다. 이 경우에는 시작(earliest)부터 모든 메시지를 다시 읽거나 최근 것(latest) 이후에 모든 메시지를 읽을 것인지를 선택할 수 있습니다.