Cấu hình tài nguyên Memory và CPU cho các Node RisingWave
Việc phân bổ tài nguyên không đồng đều giữa Frontend, Compute, và Storage là nguyên nhân chính gây nghẽn cổ chai (bottleneck) hoặc OOM (Out of Memory).
Trong RisingWave, Compute Node cần nhiều CPU để xử lý toán tử stream, trong khi Meta Service và Frontend cần bộ nhớ ổn định để quản lý metadata.
Điều chỉnh Docker Compose cho từng loại Node
Chỉnh sửa file cấu hình /opt/risingwave/docker-compose.yml để phân bổ tài nguyên cụ thể cho từng container.
Tham số mem_limit giới hạn RAM, cpus giới hạn lõi CPU. Đảm bảo tổng tài nguyên không vượt quá 80% tài nguyên vật lý của host Ubuntu.
version: "3.8"
services:
# Frontend & Meta Service (Cần RAM ổn định, CPU ít)
frontend:
image: risingwavelabs/risingwave:latest
command: ["frontend", "--frontend-address", "0.0.0.0:4566"]
mem_limit: "2g"
cpus: "1.0"
networks:
- risingwave
ports:
- "4566:4566"
depends_on:
- meta
meta:
image: risingwavelabs/risingwave:latest
command: ["meta-node", "--meta-address", "0.0.0.0:5690", "--store", "hummock://127.0.0.1:5690"]
mem_limit: "2g"
cpus: "1.0"
networks:
- risingwave
ports:
- "5690:5690"
depends_on:
- etcd
etcd:
image: quay.io/coreos/etcd:v3.5.9
command:
- etcd
- --advertise-client-urls=http://0.0.0.0:2379
- --listen-client-urls=http://0.0.0.0:2379
mem_limit: "1g"
cpus: "0.5"
networks:
- risingwave
ports:
- "2379:2379"
# Compute Node (Cần CPU cao, RAM lớn cho State Store)
compute:
image: risingwavelabs/risingwave:latest
command: ["compute-node", "--compute-address", "0.0.0.0:5688", "--meta-addr", "http://meta:5690"]
mem_limit: "8g"
cpus: "4.0"
networks:
- risingwave
ports:
- "5688:5688"
depends_on:
- meta
- etcd
# Compactor (Cần I/O cao, RAM trung bình)
compactor:
image: risingwavelabs/risingwave:latest
command: ["compactor", "--compactor-address", "0.0.0.0:5691", "--meta-addr", "http://meta:5690"]
mem_limit: "4g"
cpus: "2.0"
networks:
- risingwave
ports:
- "5691:5691"
depends_on:
- meta
# Hummock Object Store (MinIO hoặc Local File)
hummock:
image: minio/minio:latest
command: ["server", "/data"]
mem_limit: "4g"
cpus: "2.0"
volumes:
- hummock_data:/data
networks:
- risingwave
ports:
- "9000:9000"
networks:
risingwave:
volumes:
hummock_data:
Kết quả mong đợi: Các container sẽ khởi động và bị giới hạn tài nguyên theo đúng con số đã cấu hình, tránh việc một node chiếm hết RAM máy chủ.
Verify: Chạy lệnh docker stats để kiểm tra xem CPU và Memory usage của từng container có nằm trong giới hạn đã đặt hay không.
Phân tích và xử lý các lỗi phổ biến
Log của RisingWave được ghi vào stdout của Docker. Việc đọc log cần tập trung vào các từ khóa lỗi cụ thể để định hướng xử lý.
Xử lý lỗi OOM (Out of Memory)
Lỗi này xảy ra khi Compute Node hoặc Compactor cố gắng xử lý dữ liệu lớn hơn giới hạn RAM, khiến Linux OOM Killer giết chết container.
Triệu chứng: Container bị restart liên tục, log hiện dòng Out of memory hoặc Killed mà không có stack trace rõ ràng.
docker logs risingwave-compute-1 --tail 100 | grep -i "oom\|killed\|memory"
Kết quả mong đợi: Bạn sẽ thấy dòng log xác nhận việc thiếu bộ nhớ, ví dụ: Out of memory: Killed process 1234 (compute-node).
Giải pháp: Tăng tham số mem_limit trong file docker-compose.yml cho service compute và compactor, sau đó chạy lại docker-compose up -d.
Xử lý lỗi kết nối Meta Service
Lỗi này thường xảy ra khi Compute Node mất kết nối với Meta Service (do mạng hoặc Meta Service bị crash), dẫn đến việc các job bị treo hoặc lỗi Connection refused.
docker logs risingwave-meta-1 --tail 50 | grep -i "connection\|failed\|timeout"
Kết quả mong đợi: Log hiển thị thông báo lỗi kết nối TCP hoặc lỗi giao thức gRPC giữa Compute và Meta.
Giải pháp: Kiểm tra xem container meta và etcd có đang running không bằng lệnh docker-compose ps. Nếu etcd bị crash, cần khởi động lại toàn bộ cụm vì etcd giữ trạng thái metadata.
Xử lý lỗi Compactor không chạy
Compactor chịu trách nhiệm gom gọn các file snapshot. Nếu compactor bị lỗi, storage sẽ đầy nhanh chóng và hiệu năng truy vấn giảm.
docker logs risingwave-compactor-1 --tail 50 | grep -i "error\|panic\|compaction"
Kết quả mong đợi: Thông báo lỗi về định dạng file hoặc lỗi I/O từ Object Store (MinIO).
Giải pháp: Đảm bảo quyền truy cập vào volume hummock_data và cấu hình đúng endpoint của MinIO trong biến môi trường nếu cần.
Bảo trì, Scale-up và Xử lý mất dữ liệu
Trong môi trường Serverless hoặc Cloud, việc mở rộng quy mô (Scale-up) và khôi phục dữ liệu là các thao tác bảo trì bắt buộc.
Scale-up cụm bằng cách thêm Compute Node
Để tăng khả năng xử lý (throughput), bạn cần thêm nhiều Compute Node hơn. RisingWave tự động cân bằng tải (load balancing) khi có nhiều node.
Không cần chỉnh sửa code ứng dụng, chỉ cần thay đổi deploy section trong Docker Compose.
version: "3.8"
services:
compute:
image: risingwavelabs/risingwave:latest
command: ["compute-node", "--compute-address", "0.0.0.0:5688", "--meta-addr", "http://meta:5690"]
mem_limit: "8g"
cpus: "4.0"
deploy:
replicas: 3
networks:
- risingwave
ports:
- "5688-5690:5688"
depends_on:
- meta
Kết quả mong đợi: Docker Compose sẽ tạo ra 3 container compute song song (compute-1, compute-2, compute-3). Meta Service tự động nhận diện và phân phối task cho cả 3 node.
Verify: Chạy docker-compose ps để thấy số lượng container tăng lên và dùng docker stats để thấy CPU được chia đều cho 3 node.
Khắc phục sự cố mất dữ liệu (Data Loss)
Trong RisingWave, dữ liệu stream được lưu trữ trong Hummock (Snapshot Store). Nếu bạn xóa volume hummock_data, dữ liệu lịch sử sẽ mất vĩnh viễn.
Để khôi phục, bạn cần có bản backup của volume này. Dưới đây là quy trình backup và restore volume Docker.
Bước 1: Backup volume Hummock khi hệ thống đang chạy hoặc dừng.
docker run --rm -v risingwave_hummock_data:/data -v $(pwd):/backup alpine tar czf /backup/hummock_backup.tar.gz /data
Kết quả mong đợi: File hummock_backup.tar.gz được tạo trong thư mục hiện hành.
Bước 2: Khi cần khôi phục (sau khi mất dữ liệu), xóa volume cũ và restore từ backup.
docker volume rm risingwave_hummock_data
docker run --rm -v risingwave_hummock_data:/data -v $(pwd):/backup alpine tar xzf /backup/hummock_backup.tar.gz -C /
Kết quả mong đợi: Volume hummock_data được tạo lại với dữ liệu từ thời điểm backup. Khi khởi động lại RisingWave, hệ thống sẽ đọc lại snapshot từ volume này.
Giám sát hiệu năng liên tục
Để phát hiện sớm các vấn đề hiệu năng, hãy sử dụng Prometheus và Grafana (nếu đã deploy) hoặc kiểm tra log định kỳ.
docker logs risingwave-meta-1 | grep "compaction" | tail -n 20
Kết quả mong đợi: Xem được trạng thái compaction gần đây. Nếu log hiện nhiều dòng compaction failed hoặc compaction latency high, cần tăng RAM cho Compactor hoặc giảm tải dữ liệu đầu vào.
Điều hướng series:
Mục lục: Series: Triển khai Database Serverless với RisingWave trên Ubuntu 24.04
« Phần 5: Xây dựng luồng dữ liệu thời gian thực với Source và Sink