1. Xử lý lỗi phân mảnh dữ liệu (Sharding) và cân bằng lại (Rebalancing)
Trong môi trường Cluster, dữ liệu bị phân chia thành nhiều shard và phân phối qua các follower. Khi thêm node mới hoặc mất node cũ, dữ liệu có thể bị lệch, gây hiện tượng "hotspot" hoặc truy vấn chậm. Chúng ta cần kích hoạt cơ chế cân bằng tự động hoặc thực hiện thủ công.
1.1 Kiểm tra trạng thái cân bằng của Cluster
Trước khi can thiệp, hãy xác định xem cluster có đang ở trạng thái cân bằng (balanced) hay không bằng cách truy vấn vào hệ thống database.
Chạy lệnh sau trên bất kỳ node nào trong cluster (thường là node Coordinator hoặc Agent có quyền admin) để xem báo cáo trạng thái:
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Kết quả mong đợi: Nếu hàm db._isBalanced() trả về true, dữ liệu đã được phân phối đều. Nếu false, hệ thống đang trong quá trình rebalancing hoặc cần can thiệp.
1.2 Kích hoạt Rebalancing thủ công
Đôi khi cơ chế tự động bị dừng hoặc cần đẩy nhanh tốc độ di chuyển shard. Chúng ta sẽ cấu hình tham số cân bằng trong file cấu hình của Agent hoặc điều khiển trực tiếp qua API.
Chỉnh sửa file cấu hình /etc/arangodb3/arangod.conf trên tất cả các node Agent và Data Server. Thêm hoặc sửa các dòng sau vào phần [sharding]:
[sharding]
auto-sharding = true
rebalance-enabled = true
rebalance-rate = 100
Tham số rebalance-rate kiểm soát số lượng shard được di chuyển mỗi giây. Giá trị 100 là an toàn cho môi trường sản xuất. Giá trị quá cao có thể gây quá tải I/O.
Khởi động lại dịch vụ ArangoDB để áp dụng thay đổi:
sudo systemctl restart arangodb3-agent
sudo systemctl restart arangodb3-server
Kết quả mong đợi: Dịch vụ khởi động thành công, không có lỗi về cấu hình. Sau đó, kích hoạt quá trình cân bằng ngay lập tức bằng lệnh sau:
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Lệnh db._moveCollection buộc hệ thống tính toán lại vị trí của các shard trong collection "users".
1.3 Verify kết quả
Chờ khoảng 1-2 phút, sau đó kiểm tra lại trạng thái cân bằng:
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Kết quả mong đợi: true được in ra màn hình và số lượng document trong các shard được phân bổ tương đối đồng đều giữa các server.
2. Cấu hình TLS/SSL cho kết nối bảo mật giữa các nút Cluster
Mặc định ArangoDB Cluster giao tiếp nội bộ qua giao thức không mã hóa. Để bảo mật, chúng ta cần triển khai chứng chỉ tự ký (self-signed) hoặc từ CA để mã hóa lưu lượng giữa Agent, Coordinator và DB Server.
2.1 Tạo chứng chỉ tự ký (Self-Signed CA)
Chúng ta sẽ tạo một CA riêng và cấp chứng chỉ cho từng node. Thực hiện trên một máy chủ quản lý (có quyền SSH đến tất cả node).
Tạo thư mục chứa chứng chỉ và tạo CA private key:
mkdir -p /etc/arangodb3/ssl
cd /etc/arangodb3/ssl
openssl genrsa -out ca-key.pem 2048
Tạo chứng chỉ CA (hạn 10 năm):
openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem -subj "/CN=ArangoDB-CA"
Kết quả mong đợi: File ca-key.pem và ca-cert.pem được tạo thành công.
2.2 Tạo chứng chỉ cho từng Node
Giả sử ta có 3 node: coordinator1, dbserver1, dbserver2. Tạo chứng chỉ cho mỗi node. Thay node-name bằng tên thực tế của node.
Tạo private key cho node:
openssl genrsa -out node-name-key.pem 2048
Tạo Certificate Signing Request (CSR) với Subject Alternative Name (SAN) bao gồm IP và hostname để tránh lỗi hostname mismatch:
openssl req -new -key node-name-key.pem -out node-name.csr -subj "/CN=node-name" -addext "subjectAltName = DNS:node-name, IP:192.168.1.10"
Chứng thực (sign) CSR bằng CA để tạo chứng chỉ cuối cùng:
openssl x509 -req -days 365 -in node-name.csr -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out node-name-cert.pem
Lặp lại quy trình trên cho tất cả các node trong cluster, đảm bảo mỗi node có cặp key.pem và cert.pem riêng.
2.3 Cấu hình ArangoDB sử dụng TLS
Phân phối file ca-cert.pem (CA) đến thư mục /etc/arangodb3/ssl/ trên TẤT CẢ các node trong cluster.
Cập nhật file cấu hình /etc/arangodb3/arangod.conf trên từng node. Thêm phần [ssl] và cấu hình endpoint:
[ssl]
enabled = true
cert = /etc/arangodb3/ssl/node-name-cert.pem
key = /etc/arangodb3/ssl/node-name-key.pem
ca-cert = /etc/arangodb3/ssl/ca-cert.pem
auto-accept-ca = false
[server]
endpoint = ssl://0.0.0.0:8529
Thay node-name-cert.pem và node-name-key.pem bằng tên file thực tế của node đó. Tham số auto-accept-ca = false bắt buộc kiểm tra chứng chỉ, tăng cường bảo mật.
Khởi động lại dịch vụ trên tất cả các node:
sudo systemctl restart arangodb3-agent
sudo systemctl restart arangodb3-coordinator
sudo systemctl restart arangodb3-server
2.4 Verify kết quả
Thử kết nối đến cluster qua giao thức TLS thay vì TCP:
arangosh --server.endpoint ssl://127.0.0.1:8529 --javascript
Kết quả mong đợi: Kết nối thành công và trả về [1]. Nếu không cấu hình đúng, sẽ báo lỗi ssl handshake failed hoặc certificate verify failed.
3. Tối ưu hóa bộ nhớ cache và cấu hình RAM cho ArangoDB
ArangoDB lưu dữ liệu vào RocksDB (cho các collection lớn) và bộ nhớ RAM (WAL, cache). Cấu hình sai lệch sẽ dẫn đến tình trạng OOM (Out of Memory) hoặc hiệu năng thấp do I/O đĩa quá tải.
3.1 Điều chỉnh RocksDB Memory Budget
RocksDB sử dụng một phần RAM để cache dữ liệu. Mặc định, nó tự động tính toán dựa trên tổng RAM, nhưng ta nên đặt giá trị thủ công để ưu tiên cho ArangoDB.
Chỉnh sửa file /etc/arangodb3/arangod.conf trên các node DB Server. Thêm hoặc sửa phần [rocksdb]:
[rocksdb]
memory-budget = 2048M
block-cache-size = 1024M
write-buffer-size = 256M
max-write-buffer-number = 4
Giải thích: memory-budget là tổng RAM RocksDB được phép dùng (tính bằng MB). block-cache-size dùng để cache dữ liệu đọc, nên chiếm khoảng 50% của memory-budget. write-buffer-size tối ưu cho write-heavy workload.
Khởi động lại DB Server:
sudo systemctl restart arangodb3-server
Kết quả mong đợi: Service khởi động thành công, không có cảnh báo về giới hạn bộ nhớ.
3.2 Tối ưu hóa Cache của ArangoDB (Cache-Control)
ArangoDB có cơ chế cache query plan và cache document. Ta cần đảm bảo bộ nhớ này không bị thu nhỏ khi hệ thống tải cao.
Chỉnh sửa file /etc/arangodb3/arangod.conf trên node Coordinator và DB Server. Thêm phần [cache]:
[cache]
max-size = 4096M
max-size-usage = 0.5
Tham số max-size đặt giới hạn tuyệt đối (MB) cho cache. max-size-usage là tỷ lệ phần trăm RAM hệ thống mà cache được phép dùng (0.5 = 50%).
Khởi động lại dịch vụ:
sudo systemctl restart arangodb3-coordinator
sudo systemctl restart arangodb3-server
3.3 Verify kết quả
Truy cập vào ArangoDB Web Interface (ArangoUI) hoặc dùng API để kiểm tra thống kê bộ nhớ:
curl -H "Accept: application/json" -u root:your_password http://127.0.0.1:8529/_admin/cluster/myCluster
Kết quả mong đợi: Trong phần stats hoặc memory, bạn thấy các giá trị rocksdb.memory-budget và cache.max-size khớp với giá trị đã cấu hình.
4. Chiến lược nâng cấp phiên bản ArangoDB không gián đoạn dịch vụ
Nâng cấp Cluster ArangoDB đòi hỏi quy trình chặt chẽ để đảm bảo tính sẵn sàng cao (High Availability). Quy tắc vàng: Nâng cấp từng loại node (Agent -> Coordinator -> DB Server) và từng instance một.
4.1 Chuẩn bị và Backup
Trước khi nâng cấp, luôn thực hiện backup toàn bộ dữ liệu theo phương thức đã học ở Phần 6.
arangobackup create --collection users --output /var/lib/arangodb3-backup/pre-upgrade-backup
Kết quả mong đợi: Backup hoàn thành, file backup được tạo trong thư mục đích.
4.2 Dừng cân bằng lại (Disable Rebalancing)
Tránh để dữ liệu di chuyển trong quá trình nâng cấp gây xung đột phiên bản.
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Kết quả mong đợi: Hàm trả về true, quá trình rebalancing tạm dừng.
4.3 Nâng cấp Agent (Leader Node)
Agent quản lý trạng thái cluster. Phải nâng cấp Agent trước tiên.
Thực hiện trên tất cả các node Agent (thường là 3 node). Dừng service, cập nhật gói phần mềm, và khởi động lại.
sudo systemctl stop arangodb3-agent
sudo apt update
sudo apt install arangodb3-agent
sudo systemctl start arangodb3-agent
Kiểm tra trạng thái Agent:
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Kết quả mong đợi: Cluster vẫn hoạt động, db._isHealthy() trả về true.
4.4 Nâng cấp Coordinator
Sau khi Agent ổn định, nâng cấp các node Coordinator. Thực hiện lần lượt từng node một.
sudo systemctl stop arangodb3-coordinator
sudo apt install arangodb3-coordinator
sudo systemctl start arangodb3-coordinator
Chờ khoảng 30-60 giây để node Coordinator mới join lại cluster và đồng bộ trạng thái với Agent.
Kiểm tra số lượng Coordinator hoạt động:
curl -H "Accept: application/json" -u root:your_password http://127.0.0.1:8529/_admin/cluster/myCluster/health
Kết quả mong đợi: Tất cả các Coordinator đều có trạng thái "healthy" và phiên bản mới.
4.5 Nâng cấp DB Server (Data Node)
Đây là bước quan trọng nhất vì chứa dữ liệu. Nâng cấp từng DB Server một. Khi nâng cấp, DB Server sẽ tự động chuyển sang chế độ bảo trì (maintenance) và dữ liệu sẽ được cân bằng lại sang các node khác (vì ta đã disable rebalancing ở bước 4.2, nên ta cần enable lại từng phần hoặc để hệ thống tự xử lý khi node quay lại).
Thực hiện trên từng node DB Server:
sudo systemctl stop arangodb3-server
sudo apt install arangodb3-server
sudo systemctl start arangodb3-server
Khi DB Server khởi động lại với phiên bản mới, nó sẽ tự động sync dữ liệu từ các node còn lại nếu cần.
4.6 Kích hoạt lại Rebalancing
Khi tất cả các node đã được nâng cấp, kích hoạt lại cơ chế cân bằng để phân phối lại dữ liệu tối ưu cho phiên bản mới.
arangosh --server.endpoint tcp://127.0.0.1:8529 --javascript
Kết quả mong đợi: Hệ thống bắt đầu quá trình rebalancing nhẹ để tối ưu hóa shard placement.
4.7 Verify kết quả
Kiểm tra phiên bản ArangoDB của toàn bộ cluster:
curl -H "Accept: application/json" -u root:your_password http://127.0.0.1:8529/_admin/version
Kết quả mong đợi: Tất cả các role (Agent, Coordinator, DB Server) đều hiển thị cùng một phiên bản mới nhất, và cluster ở trạng thái "healthy".
Điều hướng series:
Mục lục: Series: Triển khai Database Multi-Model với ArangoDB trên Ubuntu 24.04
« Phần 6: Sao lưu, khôi phục và giám sát hiệu năng