Cấu hình tối ưu bộ nhớ đệm (Cache) trong InfluxDB.conf
Điều chỉnh tham số cache trong file cấu hình giúp cân bằng giữa tốc độ đọc (read throughput) và mức tiêu thụ RAM. InfluxDB sử dụng TSM (Time Series Merge) engine, nơi cache đóng vai trò lưu trữ dữ liệu gần đây để truy vấn nhanh hơn.
Mục tiêu là tăng kích thước cache lên mức phù hợp với RAM của server, thường là 50-75% RAM còn trống sau khi trừ đi bộ đệm cho OS và các ứng dụng khác. Đồng thời, tăng số lượng cache engine để giảm xung đột (lock contention) khi có nhiều luồng truy vấn.
Sửa file cấu hình chính tại đường dẫn /etc/influxdb2/influxdb2.conf. Nếu file này chưa tồn tại hoặc đang dùng cấu hình mặc định, hãy tạo mới hoặc bổ sung phần [storage].
cat > /etc/influxdb2/influxdb2.conf
Kết quả mong đợi: File cấu hình đã được ghi nhận. Bạn cần khởi động lại dịch vụ InfluxDB để áp dụng thay đổi này.
Thực hiện khởi động lại dịch vụ và kiểm tra trạng thái:
systemctl restart influxdb2
systemctl status influxdb2
Kiểm tra xem cấu hình đã được tải thành công bằng lệnh xem log hoặc kiểm tra tham số runtime (nếu có tool hỗ trợ), nhưng cách đơn giản nhất là đảm bảo dịch vụ đang chạy mà không báo lỗi về bộ nhớ.
journalctl -u influxdb2 -n 50 --no-pager | grep -i "cache\|storage"
Không có lỗi "out of memory" hay "failed to start" trong log liên quan đến storage.
Tối ưu hóa chính sách Shard Duration (Nén dữ liệu)
Shard duration là khoảng thời gian mà dữ liệu được lưu trữ trong một file dữ liệu vật lý (shard) trước khi InfluxDB đóng file đó lại và tạo file mới. Việc chọn đúng shard duration ảnh hưởng trực tiếp đến hiệu năng ghi (write performance) và số lượng file trên hệ thống.
Nguyên tắc chung: Nếu tần suất ghi dữ liệu (write rate) cao, hãy chọn shard duration ngắn hơn để giảm kích thước file TSM, giúp truy vấn nhanh hơn. Nếu write rate thấp, shard duration dài hơn giúp giảm số lượng file mở.
Trong InfluxDB 2.x, Shard Duration được cấu hình tại cấp độ Bucket (Dữ liệu). Chúng ta sẽ sử dụng CLI để cập nhật chính sách này cho bucket đang sử dụng.
Trước tiên, xác định ID của bucket cần tối ưu. Giả sử bucket có tên là "telegraf_metrics".
influx bucket list
Kết quả mong đợi: Danh sách các bucket hiện có, bao gồm cột "ID" và "Name". Ghi nhận ID tương ứng với bucket mục tiêu.
Thiết lập Shard Duration. Các giá trị phổ biến: "1h", "1d", "7d", "30d". Đối với dữ liệu hệ thống (CPU, RAM, Network) được thu thập mỗi 10-30 giây, giá trị "1h" hoặc "1d" thường là tối ưu.
Giả sử ID bucket là abc123456789 và ta muốn thiết lập duration là 1 ngày.
influx bucket update --id abc123456789 --shard-duration "1d"
Kết quả mong đợi: Thông báo xác nhận bucket đã được cập nhật. Không có lỗi trả về.
Verify kết quả bằng cách hiển thị chi tiết bucket:
influx bucket inspect --id abc123456789
Trong đầu ra, tìm dòng "Shard duration" hoặc tương đương. Nó phải hiển thị "1d". Lưu ý: Thay đổi này chỉ áp dụng cho dữ liệu mới được ghi vào sau thời điểm cấu hình. Dữ liệu cũ vẫn giữ nguyên shard duration cũ cho đến khi nó bị xóa theo Retention Policy hoặc được compact lại.
Tạo bản sao lưu toàn bộ với lệnh influx backup
Lệnh influx backup tạo ra một snapshot của toàn bộ dữ liệu InfluxDB (bao gồm metadata và dữ liệu TSM) vào một thư mục đích. Đây là phương pháp sao lưu chính thức cho InfluxDB 1.x và 2.x (chạy trên TSM engine).
Quan trọng: Để đảm bảo tính nhất quán (consistency) của dữ liệu khi sao lưu, bạn cần đặt tham số --retention để chỉ định giữ lại dữ liệu bao lâu, hoặc sao lưu toàn bộ. InfluxDB 2.x thường yêu cầu chỉ định bucket ID hoặc sao lưu toàn bộ instance.
Tạo thư mục đích để lưu file backup trước khi chạy lệnh.
mkdir -p /var/backups/influxdb
chmod 750 /var/backups/influxdb
Thực hiện lệnh backup. Tham số -d chỉ định đường dẫn đích. Tham số --retention (tùy chọn) giúp lọc dữ liệu cũ không cần thiết để giảm dung lượng backup, nhưng để an toàn toàn bộ, ta sẽ bỏ qua tham số này hoặc đặt giá trị lớn.
Chạy lệnh backup cho toàn bộ instance:
influx backup -d /var/backups/influxdb/backup-$(date +%F)
Kết quả mong đợi: InfluxDB sẽ in ra các thông báo về quá trình sao lưu (backup buckets, backup shards...). Quá trình này có thể mất vài giây đến vài phút tùy vào lượng dữ liệu.
Verify kết quả bằng cách liệt kê nội dung thư mục backup:
ls -lh /var/backups/influxdb/
Thư mục mới backup-YYYY-MM-DD được tạo và chứa các file như meta (metadata) và các file shard_* (dữ liệu thực tế).
Kiểm tra dung lượng và số lượng file trong thư mục backup:
du -sh /var/backups/influxdb/backup-$(date +%F)
Hiển thị dung lượng tổng của bản sao lưu. Đảm bảo dung lượng này không bằng 0 và có các file dữ liệu thực tế.
Kịch bản khôi phục (Restore) dữ liệu từ file backup
Khôi phục dữ liệu là quá trình đảo ngược của backup. Lưu ý quan trọng: Bạn không thể khôi phục trực tiếp vào một instance đang chạy có dữ liệu khác mà không gây xung đột ID. Quy trình chuẩn là: Dừng dịch vụ -> Xóa dữ liệu cũ (nếu cần restore toàn bộ mới) -> Chạy restore -> Khởi động lại.
Trước khi thực hiện, đảm bảo bạn có file backup đã tạo ở phần trước. Nếu muốn khôi phục vào server khác hoặc reset server hiện tại, hãy thực hiện các bước sau.
Bước 1: Dừng dịch vụ InfluxDB để giải phóng các file dữ liệu và khóa (lock).
systemctl stop influxdb2
Kiểm tra trạng thái đảm bảo dịch vụ đã dừng:
systemctl status influxdb2 | grep -i "inactive"
Bước 2: Xóa dữ liệu hiện có trong thư mục data của InfluxDB để tránh xung đột ID shard. Đối với InfluxDB 2.x mặc định, đường dẫn data thường là /var/lib/influxdb2.
Cảnh báo: Lệnh sau sẽ xóa toàn bộ dữ liệu hiện tại. Chỉ thực hiện nếu bạn chắc chắn muốn khôi phục từ backup.
rm -rf /var/lib/influxdb2/*
Bước 3: Thực hiện lệnh restore. Chỉ định đường dẫn thư mục backup đã tạo.
influx restore -d /var/backups/influxdb/backup-$(date +%F)
Kết quả mong đợi: Lệnh sẽ bắt đầu quá trình khôi phục metadata và dữ liệu shard. Bạn sẽ thấy log hiển thị tiến độ khôi phục từng bucket và shard.
Bước 4: Khởi động lại dịch vụ InfluxDB.
systemctl start influxdb2
systemctl status influxdb2
Verify kết quả khôi phục bằng cách kiểm tra xem các bucket và dữ liệu đã quay lại chưa.
influx bucket list
Danh sách bucket hiện ra phải khớp với trạng thái trước khi backup.
Thực hiện một truy vấn Flux đơn giản để kiểm tra dữ liệu đã được khôi phục:
influx query --bucket "telegraf_metrics" --query "from(bucket: \"telegraf_metrics\") |> range(start: -1h) |> count()"
Kết quả trả về số lượng điểm dữ liệu (count) trong 1 giờ qua. Nếu con số này lớn hơn 0 và khớp với dữ liệu bạn ghi trước đó, quá trình khôi phục thành công.
Điều hướng series:
Mục lục: Series: Triển khai Database Time-Series với InfluxDB trên Ubuntu 24.04
« Phần 8: Cấu hình cảnh báo (Alerting) và tự động hóa
Phần 10: Xử lý sự cố (Troubleshooting) và mẹo nâng cao »