Phân tích Log và Xử lý Lỗi Phổ biến trong Apache Doris
Trong quá trình vận hành, lỗi phổ biến nhất là Backend (BE) không thể tham gia vào cụm (Cluster) hoặc gặp tình trạng Full GC làm giảm hiệu năng nghiêm trọng. Nguyên nhân thường nằm ở cấu hình mạng hoặc thiếu bộ nhớ Java.
Đầu tiên, hãy xác định trạng thái của BE bằng cách truy cập vào Web UI của Frontend (FE) tại địa chỉ http://:8030. Nếu thấy trạng thái của BE là NOT RUNNING hoặc DISCONNECTED, bạn cần kiểm tra log ngay lập tức.
1. Xử lý lỗi BE không Join được Cluster
Lỗi này thường xảy ra khi BE không thể liên lạc với FE do firewall chặn port 9020, hoặc do thời gian chờ (heartbeat timeout) quá ngắn so với độ trễ mạng. Kiểm tra log của BE để tìm dòng lỗi cụ thể.
Thực hiện lệnh sau để xem log lỗi gần nhất của BE:
tail -n 200 /opt/apache-doris/be/log/be.log | grep -i "error\|failed\|join"
Kết quả mong đợi: Bạn sẽ thấy các dòng log ghi nhận lỗi kết nối như "Failed to connect to FE" hoặc "Heartbeat timeout". Nếu thấy lỗi "Connection refused", hãy kiểm tra firewall trên máy FE.
Để khắc phục lỗi kết nối do firewall, mở port 9020 (FE Port cho BE) và 8030 (Web UI) trên máy FE:
sudo ufw allow 9020/tcp && sudo ufw allow 8030/tcp
Trên máy BE, nếu lỗi là do BE không nhận diện đúng FE, hãy kiểm tra file cấu hình be.conf. Đảm bảo phần frontend_host trỏ đúng IP của FE.
Chỉnh sửa file cấu hình BE:
cat > /opt/apache-doris/be/conf/be.conf
Sau khi sửa, hãy restart BE để áp dụng:
systemctl restart doris-be
Kết quả mong đợi: Sau 1-2 phút, truy cập lại Web UI, trạng thái của BE sẽ chuyển từ NOT RUNNING sang RUNNING.
2. Xử lý lỗi Full GC quá nhiều
Full GC (Garbage Collection) xảy ra khi bộ nhớ Heap của BE bị đầy, buộc JVM phải dừng tất cả các luồng để dọn dẹp, gây treo hệ thống. Nguyên nhân là do cấu hình max_memory trong be.conf quá lớn so với RAM vật lý, hoặc do không cấu hình đúng tham số Java Heap.
Để kiểm tra, xem log GC của BE:
grep "Full GC" /opt/apache-doris/be/log/be.log | tail -n 10
Kết quả mong đợi: Nếu thấy dòng log xuất hiện liên tục với thời gian (time) lớn hơn 1-2 giây, hệ thống đang bị Full GC.
Giải pháp là giảm bộ nhớ dành cho BE và tăng bộ nhớ cho Page Cache (OS Cache). Giả sử máy có 32GB RAM, ta nên cấp 16GB cho BE và 16GB còn lại cho OS. Sửa file be.conf tại đường dẫn /opt/apache-doris/be/conf/be.conf:
cat > /opt/apache-doris/be/conf/be.conf
Khởi động lại BE để áp dụng thay đổi:
systemctl restart doris-be
Verify kết quả bằng cách kiểm tra lại log sau 30 phút:
grep "Full GC" /opt/apache-doris/be/log/be.log | tail -n 5
Kết quả mong đợi: Không xuất hiện dòng log mới nào chứa "Full GC" trong khoảng thời gian kiểm tra.
Tối ưu hóa Hiệu năng khi Scale-out và Cân bằng Tải
Khi mở rộng cụm (Scale-out) bằng cách thêm nhiều BE mới, dữ liệu sẽ không tự động phân bổ đều nếu không cấu hình đúng. Apache Doris sử dụng cơ chế Auto Balance để di chuyển Replica từ các BE quá tải sang các BE mới.
1. Cấu hình cân bằng tải tự động (Auto Balance)
Để kích hoạt tự động cân bằng tải, bạn cần đảm bảo cơ chế này đang bật trên FE. Mặc định nó đã bật, nhưng cần kiểm tra lại và điều chỉnh tham số để phù hợp với quy mô cụm lớn.
Truy cập vào MySQL Client để kiểm tra và cấu hình:
mysql -h 192.168.1.10 -P 9030 -u root -p
Trong shell của MySQL, thực hiện lệnh kiểm tra biến hệ thống enable_auto_balance:
SHOW GLOBAL VARIABLES LIKE "enable_auto_balance";
Kết quả mong đợi: Giá trị trả về là True. Nếu là False, thực hiện lệnh sau để bật:
SET GLOBAL enable_auto_balance = "true";
Để kiểm soát tốc độ di chuyển dữ liệu (tránh gây quá tải mạng khi scale-out), hãy giới hạn số lượng Replica di chuyển cùng lúc bằng tham số auto_balance_concurrent_tasks:
SET GLOBAL auto_balance_concurrent_tasks = "2";
Kết quả mong đợi: FE bắt đầu di chuyển Replica từ các BE cũ sang BE mới. Bạn có thể theo dõi quá trình này trong Web UI tại tab Backend -> Tablets.
2. Cân bằng tải thủ công khi cần thiết
Trong trường hợp tự động không hoạt động hoặc bạn muốn ép buộc di chuyển dữ liệu ngay lập tức (ví dụ: khi một BE bị lỗi và cần khôi phục), hãy sử dụng lệnh ADMIN SET REPLICA STATUS để đánh dấu một Replica là ABNORMAL, kích thích FE tạo Replica mới ở nơi khác.
Giả sử bạn muốn cân bằng lại dữ liệu cho Table my_columnar_table trong Database analytics_db:
ALTER TABLE analytics_db.my_columnar_table SET PROPERTIES ("auto_balance" = "true");
Lệnh này đảm bảo rằng table cụ thể này nằm trong phạm vi quản lý của Auto Balance. Sau đó, kiểm tra trạng thái cân bằng:
SHOW BACKENDS;
Kết quả mong đợi: Cột DataSize và TabletCount giữa các Backend sẽ dần đều nhau theo thời gian.
Quản lý và Tối ưu hóa Compact dữ liệu
Compact là quá trình gộp nhiều Version của dữ liệu (do các lần Update/Insert liên tiếp) thành một Version duy nhất để giảm số lượng file và tăng tốc độ đọc. Nếu Compact không chạy, hiệu năng truy vấn sẽ giảm dần theo thời gian.
1. Kiểm soát ngưỡng Compact (Compaction Threshold)
Mặc định, BE sẽ thực hiện Compact khi số lượng Version vượt quá một ngưỡng nhất định. Để tối ưu cho môi trường có nhiều Update (Upsert), bạn cần hạ thấp ngưỡng này để Compact chạy thường xuyên hơn.
Thực hiện lệnh trong MySQL Client để xem ngưỡng hiện tại:
SHOW GLOBAL VARIABLES LIKE "max_compaction_version";
Kết quả mong đợi: Giá trị mặc định thường là 16. Với dữ liệu thay đổi liên tục, hãy giảm xuống còn 8:
SET GLOBAL max_compaction_version = "8";
Để áp dụng cho toàn bộ cụm ngay lập tức, bạn cũng có thể set cho từng Table cụ thể nếu cần:
ALTER TABLE analytics_db.my_columnar_table SET PROPERTIES ("max_compaction_version" = "8");
Kết quả mong đợi: BE sẽ bắt đầu gộp các version cũ nhanh hơn, giảm số lượng file trên disk.
2. Ép buộc Compact dữ liệu (Manual Compaction)
Trong các tình huống khẩn cấp hoặc sau khi chạy các tác vụ ETL lớn, bạn có thể ép buộc BE thực hiện Compact toàn bộ dữ liệu của một Table hoặc một Partition.
Để ép buộc Compact toàn bộ Table my_columnar_table:
ADMIN SET TABLET COMPACT ANALYTICS_DB.MY_COLUMNAR_TABLE;
Lưu ý: Lệnh này là asynchronous (không đồng bộ), BE sẽ nhận lệnh và thực hiện trong nền. Để kiểm tra trạng thái:
SHOW BACKENDS;
Trong Web UI, chọn Backend -> Tab Tablets -> Tìm tên Table -> Cột Compaction sẽ hiển thị trạng thái RUNNING hoặc SUCCESS.
3. Xử lý lỗi Compact bị treo (Stuck Compaction)
Nếu quá trình Compact bị treo (status RUNNING quá lâu), nguyên nhân thường là do thiếu bộ nhớ hoặc lỗi disk I/O. Hãy kiểm tra log BE:
grep -i "compaction.*fail\|compaction.*timeout" /opt/apache-doris/be/log/be.log | tail -n 20
Kết quả mong đợi: Nếu thấy lỗi "OOM" (Out of Memory), hãy tăng tham số memory_limit_percent trong be.conf hoặc giảm max_compaction_version xuống thấp hơn nữa để giảm áp lực bộ nhớ cho mỗi lần compact.
Để restart lại quá trình compact bị treo, bạn có thể restart BE (cẩn thận vì sẽ làm gián đoạn dịch vụ tạm thời) hoặc đợi FE tự động retry sau 5 phút.
Verify Tổng thể và Kết thúc
Sau khi thực hiện tất cả các bước troubleshooting và tối ưu hóa, hãy thực hiện một lượt kiểm tra tổng thể để đảm bảo hệ thống ổn định.
1. Kiểm tra trạng thái Backend trong Web UI: Tất cả BE phải ở trạng thái RUNNING.
2. Chạy một truy vấn phân tích lớn để kiểm tra hiệu năng:
SELECT count(*), sum(revenue) FROM analytics_db.sales_table WHERE date > '2023-01-01';
Kết quả mong đợi: Thời gian thực thi (Execution Time) giảm so với trước khi tối ưu, không có cảnh báo về Full GC hoặc lỗi kết nối.
3. Kiểm tra log BE để đảm bảo không có lỗi mới:
tail -f /opt/apache-doris/be/log/be.log
Quá trình troubleshooting và tối ưu hóa Apache Doris đã hoàn tất. Hệ thống giờ đã sẵn sàng cho việc vận hành ở quy mô lớn với khả năng tự cân bằng và xử lý lỗi tốt hơn.
Điều hướng series:
Mục lục: Series: Triển khai Database Columnar với Apache Doris trên Ubuntu 24.04
« Phần 7: Quản lý dữ liệu: Backup, Restore và Data Lifecycle Management