Cấu hình Prometheus và Grafana để giám sát metric YugabyteDB
Cài đặt Prometheus trên một node riêng biệt hoặc node master để thu thập metric từ các node YugabyteDB thông qua endpoint t-metrics.
YugabyteDB tự động phơi bày metric dưới dạng Prometheus format tại cổng 9060 (mặc định) của tserver và master. Chúng ta cần cấu hình Prometheus để scrape các endpoint này.
Tạo file cấu hình /etc/prometheus/prometheus.yml để định nghĩa target scraping cho toàn bộ cluster.
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'yugabytedb-masters'
static_configs:
- targets: ['master-node-1:9060', 'master-node-2:9060', 'master-node-3:9060']
- job_name: 'yugabytedb-tservers'
static_configs:
- targets: ['tserver-node-1:9060', 'tserver-node-2:9060', 'tserver-node-3:9060']
Kết quả mong đợi: Prometheus có thể kết nối và thu thập metric thành công từ tất cả các node. Kiểm tra tab "Targets" trên UI Prometheus (port 9090) thấy trạng thái "UP".
Tích hợp Grafana để trực quan hóa dữ liệu
Deploy Grafana để hiển thị các dashboard chuyên biệt cho YugabyteDB, tập trung vào độ trễ giao dịch (latency) và thông lượng (throughput) của HTAP.
Cài đặt Grafana qua apt và import dashboard mẫu chính thức của YugabyteDB (ID: 12547) hoặc cấu hình datasource Prometheus.
sudo apt update
sudo apt install grafana -y
sudo systemctl enable grafana-server
sudo systemctl start grafana-server
Kết quả mong đợi: Dịch vụ Grafana chạy và lắng nghe cổng 3000. Truy cập http://ip-server:3000 để vào giao diện quản lý.
Cấu hình Datasource trong Grafana bằng cách tạo file /etc/grafana/provisioning/datasources/ds.yml.
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://localhost:9090
isDefault: true
editable: false
Kết quả mong đợi: Khởi động lại Grafana (sudo systemctl restart grafana-server), vào phần "Configuration -> Data Sources", thấy Prometheus đã được cấu hình sẵn.
Verify kết quả giám sát
Thực hiện lệnh query trực tiếp trên Prometheus để kiểm tra metric quan trọng.
curl 'http://localhost:9090/api/v1/query?query=yb_tserver_tablet_count'
Kết quả mong đợi: Trả về JSON chứa số lượng tablet hiện tại trên các tserver. Nếu thấy số liệu tăng/giảm theo thời gian thực, hệ thống giám sát đã hoạt động.
Phân tích log để phát hiện deadlock và slow query trong môi trường HTAP
Xác định vị trí và cấu trúc log
Trong môi trường HTAP, các log của YugabyteDB được lưu tại thư mục /var/log/yugabyte (khi cài đặt qua package) hoặc ~/yugabyte-2.11.0.0/log (khi cài đặt qua tarball). Log quan trọng nhất nằm trong thư mục log/tserver.log và log/master.log.
Phát hiện Deadlock (Chết nghẽn)
Deadlock xảy ra khi hai hoặc nhiều giao dịch khóa tài nguyên chờ nhau vòng tròn. YugabyteDB tự động phát hiện và hủy một trong các giao dịch đó để giải phóng khóa.
Sử dụng grep để tìm các dòng log báo lỗi deadlock trong file tserver.log.
grep -i "deadlock detected" /var/log/yugabyte/log/tserver.log | tail -n 20
Kết quả mong đợi: Xuất hiện các dòng log chứa thông tin về transaction ID bị hủy và lý do "Deadlock detected". Cần kiểm tra ứng dụng phía client để tối ưu thứ tự khóa (locking order).
Phân tích Slow Query (Truy vấn chậm)
Trong mô hình HTAP, các truy vấn phân tích (Analytics) có thể làm chậm các giao dịch (Transactions). Cần bật tính năng Slow Query Log trong YSQL để bắt các query vượt ngưỡng thời gian.
Cấu hình tham số log_min_duration_statement trong file postgresql.conf của YugabyteDB (thường nằm trong /var/lib/yugabyte/data/master hoặc ~/.yugabyte/data/master tùy cài đặt, nhưng tốt nhất là set runtime).
yb-admin alter_node --node= --property=postgres_config.log_min_duration_statement=1000ms
Kết quả mong đợi: YugabyteDB bắt đầu ghi log các câu lệnh SQL chạy lâu hơn 1000ms vào file log.
Trích xuất các slow query từ log để phân tích.
grep "duration" /var/log/yugabyte/log/tserver.log | awk -F'duration=' '{print $2}' | awk -F'ms' '{if($1 > 1000) print}'
Kết quả mong đợi: Danh sách các query có thời gian thực thi lớn hơn 1000ms kèm theo thời gian cụ thể. Điều này giúp xác định các query phân tích đang ảnh hưởng đến hiệu năng giao dịch.
Verify kết quả phân tích log
Chạy một query test có độ trễ nhân tạo để kiểm tra log có ghi nhận không.
psql -h -U yugabyte -d test_db -c "SELECT pg_sleep(2);"
Kết quả mong đợi: Sau khi lệnh chạy xong, file log xuất hiện dòng mới ghi nhận duration khoảng 2000ms.
Xử lý các lỗi thường gặp về mạng và đồng bộ hóa dữ liệu
Khắc phục lỗi mạng (Network Partition)
Lỗi mạng thường xảy ra khi gói tin giữa các node bị mất hoặc độ trễ quá cao, dẫn đến việc leader election bị treo hoặc tablet không thể đồng bộ.
YugabyteDB có cơ chế tự động phát hiện node chết (dead node detection). Tuy nhiên, cần kiểm tra log để xác định nguyên nhân.
Tìm kiếm các lỗi liên quan đến "heartbeat" hoặc "connection timeout" trong log.
grep -E "heartbeat|connection.*timeout|RPC.*failed" /var/log/yugabyte/log/master.log | tail -n 30
Kết quả mong đợi: Nếu thấy lỗi này, kiểm tra firewall (iptables/nftables) hoặc cấu hình MTU. Đảm bảo các cổng 7000 (RPC) và 9042 (HTTP) mở giữa các node.
Xử lý lỗi đồng bộ hóa (Replication Lag)
Khi một node tserver bị lỗi hoặc mạng chập chờn, các replica của tablet có thể bị trễ so với leader (replication lag).
Sử dụng lệnh yb-admin để kiểm tra trạng thái đồng bộ hóa của toàn cluster.
yb-admin inspect_leader --table= --table_id=
Kết quả mong đợi: Lệnh trả về thông tin về leader hiện tại và trạng thái của các follower. Nếu follower bị "stale", YugabyteDB sẽ tự động trigger quá trình recovery.
Reset node bị lỗi (Recovery)
Nếu một node bị lỗi nặng (ví dụ: mất disk, data corruption) và không thể tự phục hồi, cần thực hiện xóa dữ liệu cũ và kích hoạt lại node để nó tải lại data từ các replica khác.
Dừng dịch vụ YugabyteDB trên node bị lỗi.
sudo systemctl stop yugabytedb
Xóa thư mục dữ liệu của node đó (CẢNH BÁO: Dữ liệu sẽ được tải lại từ replica, không mất data toàn cluster nếu có đủ replica).
rm -rf /var/lib/yugabyte/data
Khởi động lại dịch vụ để YugabyteDB tự động thực hiện recovery (rebuild từ các node còn lại).
sudo systemctl start yugabytedb
Kết quả mong đợi: Node bị lỗi sẽ xuất hiện lại trong danh sách node của cluster với trạng thái "RECOVERING" rồi chuyển sang "NORMAL". Log sẽ hiện các dòng "Starting recovery".
Verify kết quả xử lý sự cố
Kiểm tra lại trạng thái tổng quát của cluster.
yb-admin cluster_status
Kết quả mong đợi: Tất cả các node đều ở trạng thái "NORMAL" và số lượng tablet được phân bổ đầy đủ (không có tablet nào bị "unavailable").
Chiến lược backup và restore cho cụm HTAP sử dụng yb-backup
Cấu hình kho chứa Backup (S3 hoặc Local)
Sử dụng công cụ yb-backup để thực hiện backup toàn bộ cluster. Cần xác định đường dẫn đích (destination) trên hệ thống tệp hoặc S3.
Trong ví dụ này, chúng ta sử dụng đường dẫn local trên một node riêng biệt hoặc NFS share.
Thực hiện Backup
Tạo backup point cho toàn bộ database hoặc một table cụ thể. Backup HTAP yêu cầu đảm bảo tính nhất quán (consistency) giữa các giao dịch đang chạy.
Lệnh backup toàn bộ database test_db vào thư mục /backup/yugabyte.
yb-backup create --master_addresses=master-node-1:7100,master-node-2:7100,master-node-3:7100 --backup_dir=/backup/yugabyte --db_name=test_db
Kết quả mong đợi: Lệnh trả về ID của backup và thời gian bắt đầu. File backup sẽ được tạo trong thư mục đích với cấu trúc /backup/yugabyte//....
Thực hiện Restore (Khôi phục)
Khôi phục dữ liệu từ backup đã tạo. Có thể restore vào cùng database cũ hoặc tạo database mới.
Lệnh restore database từ backup ID đã tạo.
yb-restore create --master_addresses=master-node-1:7100,master-node-2:7100,master-node-3:7100 --backup_id= --restore_dir=/backup/yugabyte --db_name=test_db_restore
Kết quả mong đợi: YugabyteDB tạo một database mới test_db_restore chứa toàn bộ dữ liệu tại thời điểm backup. Các transaction đang chạy trước điểm backup sẽ không bị ảnh hưởng (nếu restore vào DB mới).
Verify kết quả Backup/Restore
Kiểm tra số lượng record trong database gốc và database đã restore.
psql -h master-node-1 -U yugabyte -d test_db -c "SELECT count(*) FROM users;"
psql -h master-node-1 -U yugabyte -d test_db_restore -c "SELECT count(*) FROM users;"
Kết quả mong đợi: Số lượng record (count) giữa hai lệnh phải giống hệt nhau.
Mẹo nâng cao: Điều chỉnh tham số tablet split và merge tự động
Hiểu về cơ chế Tablet Split/Merge
YugabyteDB tự động chia nhỏ (split) tablet khi kích thước vượt quá ngưỡng mặc định (1GB) và gộp (merge) khi kích thước quá nhỏ (<128MB). Trong môi trường HTAP, việc split quá nhiều có thể gây overhead, trong khi merge quá chậm có thể làm mất cân bằng tải.
Điều chỉnh ngưỡng Split tự động
Để kiểm soát số lượng tablet, bạn có thể thay đổi ngưỡng kích thước tối đa trước khi split. Tăng ngưỡng này giúp giảm số lượng tablet, giảm overhead quản lý (metadata), nhưng có thể làm chậm quá trình balance dữ liệu.
Sử dụng yb-admin để thay đổi tham số tablet_split_size_bytes cho một table cụ thể.
yb-admin alter_table --table= --table_id= --property=tablet_split_size_bytes=2147483648
Kết quả mong đợi: Tablet sẽ chỉ được split khi đạt kích thước 2GB (thay vì 1GB). Cần áp dụng cho các table chứa dữ liệu phân tích lớn (large analytical tables).
Điều chỉnh ngưỡng Merge tự động
Ngược lại, để khuyến khích hệ thống gộp các tablet nhỏ (thường gặp sau khi xóa nhiều dữ liệu), hãy giảm ngưỡng merge.
Thay đổi tham số tablet_merge_size_bytes (thường là 1/8 của split size).
yb-admin alter_table --table= --table_id= --property=tablet_merge_size_bytes=256000000
Kết quả mong đợi: Hệ thống sẽ bắt đầu gộp các tablet có kích thước dưới 256MB, giúp giảm tổng số tablet và cải thiện hiệu năng query trên các tập dữ liệu đã bị thưa thớt.
Kiểm soát Split/Merge bằng Manual Trigger
Trong các tình huống cần tối ưu hóa ngay lập tức (ví dụ: sau khi load dữ liệu bulk), có thể buộc hệ thống thực hiện split hoặc merge thủ công.
Lệnh kích hoạt split thủ công cho một tablet cụ thể.
yb-admin split_tablet --tablet_id= --split_key=
Kết quả mong đợi: Tablet được chia thành 2 tablet mới ngay lập tức tại vị trí key chỉ định. Cần cân nhắc kỹ vị trí split để đảm bảo phân phối dữ liệu đồng đều.
Verify kết quả điều chỉnh
Kiểm tra kích thước và trạng thái của các tablet trong table đã cấu hình.
yb-admin inspect_tablet --table= --tablet_id=
Kết quả mong đợi: Thông tin hiển thị kích thước (size) của tablet và trạng thái (active/splitting/merging). Nếu cấu hình đúng, tablet sẽ tuân thủ các ngưỡng kích thước mới.
Điều hướng series:
Mục lục: Series: Triển khai Database HTAP với YugabyteDB và Linux Kernel Tuning trên Ubuntu 24.04
« Phần 6: Tối ưu hóa hiệu năng với YSQL và YCQL trong môi trường thực tế