Khi ứng dụng Kafka consumer khởi động, hệ thống liên tục ghi log lỗi liên quan đến việc không thể tham gia vào nhóm người tiêu thụ (consumer group). Nguyên nhân cốt lõi nằm ở trạng thái Group Coordinator — thành phần chịu trách nhiệm quản lý nhóm và phân bổ partition — bị báo cáo là "không khả dụng" hoặc "vô hiệu".

Phân tích dấu hiệu lỗi

Các thông báo log điển hình xuất hiện lặp lại:

Group coordinator 192.168.5.10:9092 (id: 2147483647 rack: null) is unavailable or invalid

Giá trị ID 2147483647 tương ứng với Integer.MAX_VALUE, một mã đặc biệt trong Kafka dùng để biểu thị coordinator chưa được xác định hợp lệ — nghĩa là quá trình bầu chọn coordinator thất bại hoặc metadata về nhóm bị hỏng.

Nguồn gốc tiềm ẩn

• Vấn đề về chủ đề __consumer_offsets: Chủ đề này lưu trữ metadata nhóm và offset. Nếu cấu hình replication.factor = 1 và toàn bộ partition đều có leader trên một broker duy nhất (ví dụ: broker ID = 0), thì khi broker đó gặp sự cố, coordinator sẽ không thể hoạt động.
• Thiếu cấu hình sao chép trong file server.properties: Các tham số như offsets.topic.replication.factor và transaction.state.log.replication.factor (nếu dùng transaction) nếu giữ giá trị mặc định 1, sẽ làm giảm độ tin cậy của cơ chế quản lý nhóm.
• Hạn chế hạ tầng: Broker chứa coordinator bị quá tải CPU/bộ nhớ, hoặc có độ trễ mạng cao khiến các yêu cầu heartbeat bị timeout.

Quy trình chẩn đoán

Thực hiện tuần tự các bước sau để xác định vị trí sự cố:

1. Kiểm tra kết nối cơ sở:

   telnet 192.168.5.10 9092<br>kafka-topics.sh --bootstrap-server 192.168.5.10:9092 --list

2. Đánh giá cấu trúc chủ đề hệ thống:

   kafka-topics.sh --bootstrap-server 192.168.5.10:9092 --describe --topic __consumer_offsets

3. Liệt kê chi tiết trạng thái nhóm:

   kafka-consumer-groups.sh --bootstrap-server 192.168.5.10:9092 --all-groups --describe

4. Xác minh kiểm soát truy cập (nếu bật ACL):

   kafka-acls.sh --bootstrap-server 192.168.5.10:9092 --list

Kết quả chẩn đoán thường cho thấy: kết nối mạng ổn định; không có consumer group nào đang hoạt động; chủ đề __consumer_offsets chỉ có một bản sao và phụ thuộc hoàn toàn vào broker 0; hệ thống không áp dụng ACL — loại trừ yếu tố phân quyền.

Giải pháp khắc phục

1. Khôi phục tạm thời bằng khởi động lại broker điều phối

Thực hiện theo trình tự an toàn:

1. Xác định broker ID tương ứng với địa chỉ IP:

   zookeeper-shell.sh localhost:2181 ls /brokers/ids

2. Dừng dịch vụ một cách graceful:

   systemctl stop kafka<br># hoặc<br>kafka-server-stop.sh

3. (Tùy chọn) Sao lưu và dọn dẹp metadata nghi ngờ bị lỗi:

   cp -r /opt/kafka/logs/__consumer_offsets-* /backup/coord_20250410/<br>mv /opt/kafka/logs/__consumer_offsets-* /tmp/

4. Khởi động lại broker:

   nohup kafka-server-start.sh /opt/kafka/config/server.properties &<br>tail -f /opt/kafka/logs/server.log | grep -E "(KafkaCoordinator|NetworkSocketServer)"

5. Khởi động lại ứng dụng consumer sau khi đảm bảo coordinator đã sẵn sàng.

2. Cải thiện vĩnh viễn bằng tăng độ bền cho chủ đề hệ thống

Chạy lệnh tái cấu hình __consumer_offsets với hệ số sao chép tối thiểu là 3 (đảm bảo phù hợp với số lượng broker đang hoạt động):

kafka-topics.sh \
  --bootstrap-server 192.168.5.10:9092 \
  --alter \
  --topic __consumer_offsets \
  --replication-factor 3 \
  --partitions 50

Đồng thời, cập nhật vĩnh viễn các tham số trong server.properties trên tất cả broker:

offsets.topic.replication.factor=3<br>transaction.state.log.replication.factor=3<br>offsets.topic.num.partitions=50

Sau khi thay đổi, khởi động lại toàn bộ cụm Kafka để đảm bảo cấu hình được áp dụng đồng bộ.