Cơ chế giải quyết xung đột (Conflict Resolution) trong LiteFS
LiteFS sử dụng cơ chế "Last Write Wins" (LWW) dựa trên timestamp để giải quyết xung đột khi nhiều node ghi cùng một record.
Khi hai node Edge khác nhau ghi dữ liệu vào cùng một hàng trong cùng một bảng, LiteFS so sánh timestamp của transaction. Transaction có timestamp lớn hơn sẽ ghi đè lên transaction cũ hơn.
Để đảm bảo cơ chế này hoạt động chính xác, đồng hồ hệ thống trên tất cả các node phải được đồng bộ hóa tuyệt đối thông qua NTP hoặc Chrony.
Bước 1: Đồng bộ hóa thời gian hệ thống
Thiết lập Chrony trên tất cả các node (Primary và Edge) để đảm bảo clock skew (sai lệch đồng hồ) dưới 1ms.
Chạy lệnh sau trên từng node để cài đặt và cấu hình Chrony:
sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
Kiểm tra trạng thái đồng bộ hóa:
chronyc tracking
Kết quả mong đợi: Dòng "Stratum" hiển thị số 2-3 và "Ref ID" không còn là "00000000", đồng thời "RMS error" (sai số) nằm dưới 0.001 giây.
Bước 2: Kiểm tra và xử lý xung đột thực tế
Tạo kịch bản xung đột bằng cách ghi dữ liệu vào cùng một bảng trên hai node khác nhau gần như cùng một thời điểm.
Trên Node A (Primary), thực hiện ghi dữ liệu:
sqlite3 /var/lib/litefs/data.db "INSERT INTO users (id, name, updated_at) VALUES (1, 'User_A', datetime('now'));"
Trên Node B (Edge), thực hiện ghi dữ liệu cho cùng id=1 nhưng với tên khác sau 2 giây:
sleep 2 && sqlite3 /var/lib/litefs/data.db "INSERT OR REPLACE INTO users (id, name, updated_at) VALUES (1, 'User_B', datetime('now'));"
Đợi LiteFS đồng bộ hóa (thường mất dưới 1 giây nếu mạng ổn định) rồi kiểm tra trên Node A:
sqlite3 /var/lib/litefs/data.db "SELECT * FROM users WHERE id=1;"
Kết quả mong đợi: Dòng dữ liệu trên Node A sẽ hiển thị "User_B" vì timestamp của Node B lớn hơn, chứng tỏ cơ chế Last Write Wins đã hoạt động.
Cấu hình chính sách đồng bộ hóa cho Multi-Primary
Trong kiến trúc Edge, chúng ta có thể thiết lập nhiều Primary (Multi-Primary) để phân tán điểm ghi (Write) cho các khu vực địa lý khác nhau.
LiteFS hỗ trợ chế độ này thông qua cơ chế "Peer-to-Peer" (P2P) replication, nơi mỗi Primary có thể đồng bộ với các Primary khác.
Tuy nhiên, Multi-Primary làm tăng nguy cơ xung đột. Chúng ta cần cấu hình chính sách "Quorum" hoặc "Conflict Detection" để giảm thiểu rủi ro mất dữ liệu không mong muốn.
Bước 1: Cấu hình kết nối giữa các Primary
Giả sử bạn có 2 Primary: Primary-1 (IP 192.168.1.10) và Primary-2 (IP 192.168.1.11). Cấu hình để Primary-1 đồng bộ với Primary-2 và ngược lại.
Trên Primary-1, chỉnh sửa file cấu hình để thêm peer là Primary-2:
cat > /etc/litefs/litefs.yml
Khởi động lại dịch vụ LiteFS trên Primary-1:
sudo systemctl restart litefs
Thực hiện tương tự trên Primary-2 với file cấu hình `/etc/litefs/litefs.yml` nhưng trỏ về IP của Primary-1:
cat > /etc/litefs/litefs.yml
Kết quả mong đợi: Cả hai Primary đều hiển thị trạng thái "connected" trong log và có thể ghi dữ liệu độc lập.
Bước 2: Kiểm tra trạng thái Multi-Primary
Truy cập API LiteFS để kiểm tra trạng thái đồng bộ hóa giữa các Peer.
curl -s http://192.168.1.10:8080/v1/db/status | jq .
Kết quả mong đợi: JSON trả về sẽ có trường "peers" chứa thông tin của primary-2 với trạng thái "online" và "last_index" tăng dần.
Cân bằng tải đọc với HAProxy
Để tận dụng lợi thế của kiến trúc Edge, chúng ta phân tách lưu lượng: Ghi (Write) đi về Primary gần nhất, Đọc (Read) được phân tải đến bất kỳ node nào (Primary hoặc Edge) có dữ liệu mới nhất.
HAProxy sẽ đóng vai trò Load Balancer để định tuyến các request SQL hoặc HTTP đến các node LiteFS.
Bước 1: Cài đặt và cấu hình HAProxy
Cài đặt HAProxy trên một máy chủ Gateway hoặc trên từng node Edge nếu chạy local balancing.
sudo apt install -y haproxy
sudo systemctl enable --now haproxy
Tạo file cấu hình HAProxy để cân bằng tải cho các node LiteFS. Cấu hình này sử dụng thuật toán "leastconn" (ít kết nối nhất) cho traffic đọc.
cat > /etc/haproxy/haproxy.cfg
Khởi động lại HAProxy và kiểm tra cú pháp:
sudo haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl restart haproxy
Kết quả mong đợi: Lệnh check trả về "Configuration file is valid" và HAProxy bắt đầu lắng nghe cổng 80 (Read) và 8081 (Write).
Bước 2: Kiểm tra phân phối lưu lượng
Sử dụng curl để gọi API LiteFS qua HAProxy và quan sát việc phân phối request.
for i in {1..10}; do curl -s http://192.168.1.10:80/stats | grep -o "primary-[0-9]" | head -n1; done
Lưu ý: Để kiểm tra chính xác hơn, hãy xem dashboard thống kê của HAProxy:
curl http://192.168.1.10:80/stats
Kết quả mong đợi: Cột "Srv Weight" và "Req" trong file stats cho thấy lưu lượng được phân bổ đều cho các node backend đã cấu hình.
Giám sát trạng thái đồng bộ hóa và hiệu suất mạng
Việc giám sát (Monitoring) là bắt buộc trong môi trường Edge để phát hiện mất đồng bộ (lag) hoặc xung đột dữ liệu.
Chúng ta sẽ sử dụng các endpoint HTTP của LiteFS để thu thập metric và thiết lập cảnh báo.
Bước 1: Thu thập metric từ LiteFS
LiteFS cung cấp endpoint `/v1/db/status` để xem trạng thái hiện tại của database và replication.
curl -s http://192.168.1.10:8080/v1/db/status | jq '.peers[] | {name: .name, state: .state, last_index: .last_index}'
Kết quả mong đợi: Danh sách các peer với trạng thái "online" và giá trị "last_index" của chúng phải xấp xỉ nhau (chênh lệch không quá vài đơn vị).
Bước 2: Tạo script giám sát tự động
Viết script shell đơn giản để kiểm tra độ trễ đồng bộ (replication lag) và in cảnh báo nếu lag quá lớn.
cat > /usr/local/bin/check-litefs-lag.sh
Chạy script để kiểm tra ngay lập tức:
/usr/local/bin/check-litefs-lag.sh
Kết quả mong đợi: Script in ra trạng thái "OK" cho tất cả các peer nếu mạng ổn định. Nếu có node bị mất kết nối, script sẽ in "[CRITICAL]" và trả về exit code 1.
Bước 3: Tích hợp với Prometheus (Tùy chọn)
Nếu bạn đã có Prometheus, thêm job scrape vào `prometheus.yml` để thu thập metric từ LiteFS.
cat >> /etc/prometheus/prometheus.yml
Kiểm tra target trong Prometheus UI (thường ở port 9090), trạng thái phải chuyển sang "UP".
Điều hướng series:
Mục lục: Series: Triển khai Database Edge với LiteFS và Ubuntu 24.04
« Phần 5: Tích hợp LiteFS với ứng dụng và Docker Compose
Phần 7: Troubleshooting, bảo mật và tối ưu hóa hiệu năng »