Phân tích và xử lý log lỗi trong YugabyteDB
Log là nguồn thông tin đầu tiên và quan trọng nhất khi hệ thống gặp sự cố. YugabyteDB ghi log chi tiết vào thư mục cài đặt, tập trung vào 2 thành phần chính: Master (quản lý metadata) và TServer (quản lý dữ liệu thực tế).
Xác định vị trí log file
Trong môi trường production, log thường được lưu tại `/var/log/yugabyte` hoặc thư mục `logs` trong đường dẫn cài đặt (`$YUGABYTE_INSTALL_DIR`).
Chúng ta cần kiểm tra các file log cụ thể: `yb-master.log` cho lỗi liên quan đến định dạng cluster, leader election, và `yb-tserver.log` cho lỗi liên quan đến disk I/O, replication, và tablets.
ls -lh /var/log/yugabyte/yb-master.log /var/log/yugabyte/yb-tserver.log
Kết quả mong đợi: Hiển thị danh sách file log với kích thước và thời gian cập nhật gần nhất. Nếu file quá lớn, hệ thống đã tự động rotate (xếp chồng) thành `.1`, `.2`.
Xử lý lỗi "Tablet unavailable" hoặc "Replication lag"
Lỗi này thường xảy ra khi một tablet không thể tìm thấy leader hoặc quá trình replication bị trễ. Nguyên nhân phổ biến là network partition hoặc node bị treo.
Truy cập vào `yb-tserver.log` để tìm các từ khóa cảnh báo.
grep -i "tablet.*unavailable\|replication.*lag\|leader.*election" /var/log/yugabyte/yb-tserver.log | tail -n 50
Kết quả mong đợi: Xuất hiện các dòng log chỉ rõ `tablet_id` bị lỗi, `tserver_id` bị mất kết nối, hoặc thông báo `REPLICATION_LAG_EXCEEDED_THRESHOLD`.
Xử lý lỗi "Master election failed"
Trong cụm YugabyteDB, nếu master không thể bầu leader, toàn bộ cluster sẽ rơi vào trạng thái read-only hoặc không thể tạo table mới. Kiểm tra `yb-master.log`.
grep -i "leader.*election\|master.*unavailable\|zookeeper.*connection" /var/log/yugabyte/yb-master.log | tail -n 50
Kết quả mong đợi: Tìm thấy thông báo về việc mất kết nối với Zookeeper (nếu dùng) hoặc không đủ quorum của master nodes.
Enable verbose logging để debug sâu
Để thu thập thông tin chi tiết hơn cho một vấn đề cụ thể, bạn có thể tăng mức độ log của một process cụ thể mà không cần restart toàn bộ cluster.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd set_log_level --level=DEBUG --component=tablet_server
Kết quả mong đợi: Command trả về "SUCCESS", log file bắt đầu ghi dữ liệu chi tiết hơn. Sau khi debug xong, nhớ quay lại mức INFO để tránh làm đầy disk.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd set_log_level --level=INFO --component=tablet_server
Cấu hình giám sát hiệu năng với Prometheus và Grafana
YugabyteDB có tích hợp sẵn endpoint metrics để Prometheus scrape. Chúng ta sẽ cấu hình để thu thập dữ liệu và hiển thị dashboard trực quan.
Cấu hình Prometheus để scrape YugabyteDB
YugabyteDB expose metrics tại port 9060 của mỗi node (Master và TServer). Bạn cần cấu hình `prometheus.yml` để target các node này.
Đường dẫn config: `/etc/prometheus/prometheus.yml` (hoặc vị trí tương đương trên server của bạn).
cat > /etc/prometheus/prometheus.yml
Kết quả mong đợi: File config được ghi thành công. Restart Prometheus để áp dụng: `systemctl restart prometheus`.
Verify kết quả scraping
Truy cập vào trang quản trị Prometheus (thường là port 9090) để kiểm tra xem các target đã chuyển sang trạng thái "UP" chưa.
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | select(.labels.job=="yugabyte-master") | {labels: .labels, health: .health}'
Kết quả mong đợi: JSON trả về danh sách các node YugabyteDB với trường `health` là `UP`.
Tải và cấu hình Dashboard Grafana
Sử dụng dashboard chính thức từ YugabyteDB để có các biểu đồ chuẩn. Dashboard ID trên Grafana.com thường là `13358` (YugabyteDB Cluster Overview).
Truy cập Grafana UI -> Dashboards -> Import -> Nhập ID.
# Không cần command, thao tác qua UI, nhưng để verify datasource:
curl -X GET http://localhost:3000/api/datasources
Kết quả mong đợi: Dashboard hiển thị các biểu đồ về QPS, Latency, Disk Usage, và Memory của cluster.
Xử lý sự cố phân mảnh (Split/Merge) và cân bằng tải (Rebalancing)
Khi dữ liệu tăng trưởng, các tablet sẽ bị split tự động. Ngược lại, khi xóa dữ liệu, tablet có thể trở nên quá nhỏ và cần merge. YugabyteDB tự động xử lý, nhưng đôi khi cần can thiệp thủ công để tối ưu.
Trigger Split Tablet thủ công
Trong một số trường hợp test hoặc khi một tablet quá lớn gây chậm, bạn có thể yêu cầu master split tablet đó.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd split_tablet --tablet_id="table_name:key_range" --partition_key="split_point"
Thay thế `table_name:key_range` bằng tablet_id thực tế (có thể lấy từ UI hoặc log). `split_point` là giá trị key để chia đôi tablet.
Kết quả mong đợi: Command trả về `SUCCESS` và tablet mới được tạo, tải được phân bổ lại.
Trigger Merge Tablet thủ công
Khi nhiều tablet quá nhỏ (fragmentation), hiệu năng đọc sẽ giảm. Bạn có thể merge chúng lại.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd merge_tablet --tablet_id="tablet_id_1" --merge_with="tablet_id_2"
Lưu ý: Merge chỉ thành công nếu hai tablet liền kề nhau và không có dữ liệu mới được ghi vào giữa quá trình.
Kết quả mong đợi: Command trả về `SUCCESS`, số lượng tablet giảm đi 1.
Quản lý Rebalancing (Cân bằng tải)
YugabyteDB tự động rebalance các tablet giữa các TServer để đảm bảo load đồng đều. Tuy nhiên, bạn có thể kiểm soát ngưỡng này.
Để xem trạng thái cân bằng hiện tại:
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd describe_tablet_server --tserver_addresses="192.168.1.10:7101"
Kết quả mong đợi: Xuất hiện thông tin về số lượng tablet trên mỗi node. Nếu chênh lệch quá lớn, cần kiểm tra log hoặc cấu hình `rebalance_mode`.
Tắt Rebalancing tạm thời
Trong các thao tác bảo trì, bạn có thể tắt rebalancing để tránh di chuyển dữ liệu không cần thiết.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd set_cluster_config --property=rebalance_mode --value=OFF
Kết quả mong đợi: Config được cập nhật, hệ thống ngừng di chuyển tablet. Bật lại sau khi bảo trì xong bằng cách set value là `ON`.
Best Practices vận hành YugabyteDB trong môi trường Production
Để đảm bảo hệ thống hoạt động ổn định, an toàn và hiệu quả, cần tuân thủ các nguyên tắc sau.
Cấu hình Disk và I/O
Luôn sử dụng SSD/NVMe cho YugabyteDB. Tách biệt disk cho data, log và WAL (Write-Ahead Log) để tránh contention I/O.
Trong file config `yb_conf.ini` (thường ở `/var/lib/yugabyte/conf/` hoặc `/opt/yugabyte/conf/`), cấu hình đường dẫn rõ ràng.
cat > /opt/yugabyte/conf/yb_conf.ini
Kết quả mong đợi: Các thành phần TServer và Master sẽ khởi động với đường dẫn disk được chỉ định riêng biệt.
Quản lý phiên bản và Patching
Không bao giờ upgrade tất cả node cùng một lúc. Sử dụng chiến lược Rolling Upgrade.
Tắt node (tserver) -> Upgrade binary -> Restart node -> Đợi node quay lại healthy -> Lặp lại với node tiếp theo.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd shutdown --tserver_addresses="192.168.1.10:7101" --graceful=true
Kết quả mong đợi: Node bị loại khỏi cluster một cách an toàn, tablet được di chuyển sang các node còn lại trước khi node đó tắt.
Cấu hình High Availability (HA) cho Master
Luôn chạy tối thiểu 3 master nodes. Cấu hình `replication_factor` cho master metadata là 3 để chịu được 1 lỗi node.
Khi khởi động master lần đầu, đảm bảo tham số `--cluster_name` và `--initial_master_addresses` được chỉ định chính xác cho cả 3 node.
yb-master --master_addresses=192.168.1.10:7100,192.168.1.11:7100,192.168.1.12:7100 --cluster_name=prod-cluster --use_fsync=true
Kết quả mong đợi: Cluster được khởi tạo với 3 master nodes hoạt động đồng bộ, tự động bầu leader.
Giới hạn tài nguyên (Resource Limits)
Tránh để YugabyteDB chiếm dụng 100% CPU hoặc RAM của host. Luôn để dư 10-20% cho OS và các process hệ thống khác.
Cấu hình trong `yb_conf.ini` hoặc khi start command:
cat >> /opt/yugabyte/conf/yb_conf.ini
Kết quả mong đợi: YugabyteDB tự động giới hạn tài nguyên sử dụng, tránh gây OOM (Out of Memory) crash cho toàn bộ server.
Verify kết quả Best Practices
Để đảm bảo các cấu hình đã được áp dụng đúng, kiểm tra trạng thái cluster và cấu hình runtime.
yb_admin_tool --master_addresses=192.168.1.10:7100 --cmd describe_cluster
Kết quả mong đợi: Thông tin cluster hiển thị đúng số lượng node, trạng thái `LIVE`, và các tham số cấu hình đã được cập nhật.
curl -s http://192.168.1.10:7101/status | grep -i "heap\|memory\|disk"
Kết quả mong đợi: Xem được thông số tài nguyên thực tế đang được sử dụng bởi TServer.
Điều hướng series:
Mục lục: Series: Triển khai Database ACID với YugabyteDB trên Ubuntu 24.04
« Phần 6: Backup, Restore và Recovery dữ liệu trong môi trường phân tán