Cấu hình Prometheus và Grafana để giám sát metric Vitess
Vitess tự động xuất các metric dưới dạng Prometheus format tại endpoint /metrics của vttablet và vtgate. Chúng ta cần cấu hình Prometheus để scrape các endpoint này và Grafana để hiển thị dashboard trực quan.
Cấu hình Prometheus để scrape Vitess
Tạo file cấu hình Prometheus để định nghĩa target scrape cho các dịch vụ Vitess trong cụm Geo-distributed. File này sẽ định nghĩa job cho vttablet, vtgate, và vtorc.
Đường dẫn file: /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'vttablet'
static_configs:
- targets:
- 'vttablet-0-0:15999'
- 'vttablet-0-1:15999'
- 'vttablet-1-0:15999'
metrics_path: /metrics
honor_labels: true
- job_name: 'vtgate'
static_configs:
- targets:
- 'vtgate-0-0:15999'
- 'vtgate-1-0:15999'
metrics_path: /metrics
honor_labels: true
- job_name: 'vtorc'
static_configs:
- targets:
- 'vtorc:15999'
metrics_path: /metrics
honor_labels: true
Kết quả mong đợi: Prometheus sẽ bắt đầu thu thập metric từ các tablet và gate. Chạy lệnh curl http://localhost:9090/api/v1/targets để thấy trạng thái UP cho tất cả các target.
Triển khai Grafana và Dashboard Vitess
Chúng ta cần cài đặt Grafana và import dashboard chính thức từ cộng đồng Vitess để có các biểu đồ về QPS, latency, replication lag, và connection pool.
Đầu tiên, cài đặt Grafana và cấu hình Prometheus làm data source.
apt update && apt install -y grafana
systemctl enable --now grafana
grafana-cli admin update-user admin password admin123
Khởi tạo data source Prometheus thông qua CLI của Grafana.
grafana-cli admin provisioning datasources add prometheus \
--type prometheus \
--url http://localhost:9090 \
--access proxy \
--editable
Tải dashboard Vitess (ID 14724 hoặc mới nhất từ cộng đồng) về file JSON.
mkdir -p /opt/grafana/dashboards
curl -s https://raw.githubusercontent.com/vitessio/vitess/main/examples/vitess-v2/dashboard.json \
-o /opt/grafana/dashboards/vitess-dashboard.json
Import dashboard vào Grafana.
grafana-cli dashboards import \
--datasource prometheus \
/opt/grafana/dashboards/vitess-dashboard.json
Kết quả mong đợi: Truy cập http://localhost:3000 với user admin, bạn sẽ thấy dashboard Vitess hiện diện trong danh sách và hiển thị dữ liệu real-time từ các tablet.
Xử lý các lỗi phổ biến trong vận hành
Trong môi trường Geo-distributed, các vấn đề về mạng và replication thường xảy ra. Dưới đây là các kịch bản xử lý sự cố thường gặp.
Tablet không lên (Tablet not in healthy state)
Khi tablet bị lỗi khởi động hoặc bị treo, trạng thái trong topo sẽ là NOT_RUNNING hoặc ERR. Nguyên nhân thường do MySQL không thể bind port hoặc disk full.
Để kiểm tra log của tablet, truy cập vào node và xem log file.
tail -n 100 /var/log/vitess/vttablet-0-0.log | grep -i "error\|panic\|failed"
Kiểm tra xem MySQL có đang chạy bên trong container/instance của tablet không.
systemctl status mysql
netstat -tlnp | grep 3306
Khởi động lại tablet nếu log chỉ ra lỗi tạm thời. Sử dụng command vttabletctl hoặc systemctl tùy theo cách deploy.
systemctl restart vttablet-0-0
Verify lại trạng thái bằng lệnh Vitess.
vtctldclient GetTablet -tablet_id 0-0
Kết quả mong đợi: Trạng thái TabletType trở về PRIMARY hoặc REPLICA và State là SERVING hoặc SERVING_NON_VOTING.
Xử lý Replication Lag cao
Replication lag xảy ra khi Replica không kịp áp dụng transactions từ Primary. Điều này thường do load write quá cao hoặc network latency giữa các Cell.
Kiểm tra độ trễ replication của một tablet cụ thể.
vtctldclient GetTabletStatus -tablet_id 0-1
Nếu thấy Seconds_Behind_Master > 0, cần tối ưu hóa. Bước 1: Tắt traffic write vào tablet đó để nó catch up.
vtctldclient TabletTypeChange -tablet_id 0-1 -tablet_type replica
vtctldclient ChangeTabletType -tablet_id 0-1 -tablet_type DRAINING
Bước 2: Nếu lag quá lớn, thực hiện re-stream data bằng cách reset replication và sync lại từ backup hoặc từ Primary mới.
vtctl RebuildTablet -tablet_id 0-1 -keyspace ks1 -shard 0
Kết quả mong đợi: Seconds_Behind_Master về 0. Tablet quay lại trạng thái SERVING.
Lỗi Connection Refused từ vtgate
Ứng dụng báo lỗi "Connection refused" khi gọi vào vtgate thường do vtgate chưa khởi động xong, hoặc port 15999 bị firewall chặn, hoặc tablet backend không phản hồi.
Kiểm tra log vtgate để tìm nguyên nhân.
grep "connection refused\|dial tcp" /var/log/vitess/vtgate-0-0.log
Verify xem vtgate có thể resolve DNS và connect đến tablet không.
nslookup vttablet-0-0
telnet vttablet-0-0 15999
Đảm bảo topo server (etcd/consul) đang hoạt động và tablet đã đăng ký đúng vào topo.
vtctl GetSrvVtgate -cell zone1 -keyspace ks1 -shard 0
Kết quả mong đợi: Telnet kết nối thành công và log không còn lỗi connection. Ứng dụng có thể thực hiện query.
Tối ưu hóa tham số MySQL trong vttablet
Vttablet chạy MySQL trong mode "embedded" hoặc "standalone" tùy cấu hình. Để tăng throughput cho workload đọc/ghi lớn, cần điều chỉnh các tham số MySQL cụ thể.
Cấu hình my.cnf cho workload Read-Heavy
Đối với các shard chủ yếu là đọc, cần tăng bộ nhớ cho query cache và read buffer.
Đường dẫn file cấu hình MySQL trong vttablet: /etc/vitess/my.cnf (hoặc file được chỉ định trong biến môi trường MY_CNF).
[mysqld]
# Tăng bộ nhớ cho query cache (chỉ hiệu quả nếu query pattern ít biến động)
query_cache_size = 256M
query_cache_type = 1
# Tăng buffer cho đọc
read_buffer_size = 2M
read_rnd_buffer_size = 4M
# Tối ưu hóa InnoDB cho đọc
innodb_buffer_pool_size = 8G
innodb_read_io_threads = 16
innodb_read_ahead_threshold = 1792
# Giới hạn connection để tránh overloading
max_connections = 500
Áp dụng cấu hình bằng cách khởi động lại vttablet.
systemctl restart vttablet-0-1
Kết quả mong đợi: Latency cho các query SELECT giảm xuống, CPU usage ổn định hơn dưới load cao.
Cấu hình my.cnf cho workload Write-Heavy
Đối với shard ghi nhiều, cần tập trung vào binlog và transaction log.
[mysqld]
# Tăng binlog cache size để xử lý transaction lớn
binlog_cache_size = 32M
max_binlog_cache_size = 1G
# Tối ưu InnoDB write
innodb_buffer_pool_size = 12G
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT
# Tăng commit frequency nếu chấp nhận rủi ro mất dữ liệu nhỏ (tùy trường hợp)
sync_binlog = 1
Verify hiệu năng sau khi thay đổi bằng cách chạy benchmark.
sysbench oltp_write_only --mysql-host=localhost --mysql-port=15306 --threads=16 --time=60 --report-interval=10 run
Kết quả mong đợi: TPS (Transactions Per Second) tăng lên đáng kể so với cấu hình mặc định.
Mẹo bảo trì: Backup, Upgrade và Failover
Vận hành cụm Geo-distributed đòi hỏi các quy trình bảo trì tự động và an toàn để đảm bảo uptime cao.
Thực hiện Backup dữ liệu với Vtbackup
Sử dụng công cụ vtbackup có sẵn trong Vitess để backup toàn bộ shard hoặc từng tablet.
Cấu hình backup storage (S3, GCS, hoặc NFS) trong file vttablet config. Ví dụ với NFS.
vttablet --backup_storage_type=nfs \
--backup_storage_root=/mnt/backup/vitess \
--tablet_id=0-0 \
--tablet_type=primary \
--keyspace=ks1 \
--shard=0 \
--port=15999 \
--grpc_port=15000
Chạy lệnh backup từ vtctl.
vtctl Backup -tablet_id 0-0
Verify backup file đã được tạo trong thư mục lưu trữ.
ls -lh /mnt/backup/vitess/ks1/0/0-0/
Kết quả mong đợi: File backup (thường là full hoặc incremental) xuất hiện và trạng thái backup trong log là success.
Upgrade phiên bản Vitess
Quy trình upgrade an toàn là thực hiện rolling upgrade: nâng cấp từng tablet một, bắt đầu từ Replica, sau đó đến Primary (thông qua failover).
Bước 1: Upgrade tất cả Replica trong shard.
for tablet in $(vtctl ListTablets ks1/0 | grep replica); do
vtctl TabletTypeChange $tablet replica
systemctl stop vttablet-$tablet
# Thay thế binary vttablet bằng phiên bản mới
systemctl start vttablet-$tablet
vtctl TabletTypeChange $tablet REPLICA
done
Bước 2: Thực hiện Planned Failover để chuyển Primary sang Replica mới đã upgrade.
vtctl PlannedFailoverShard -keyspace ks1 -shard 0 -new_primary_tablet_id 0-1
Bước 3: Upgrade tablet Primary cũ (nay là Replica) và các tablet còn lại.
vtctl TabletTypeChange 0-0 replica
systemctl stop vttablet-0-0
# Upgrade binary
systemctl start vttablet-0-0
Kết quả mong đợi: Tất cả tablet trong shard chạy phiên bản mới, dịch vụ không bị gián đoạn (downtime gần như bằng 0).
Xử lý Failover tự động với Vtorc
Vtorc tự động phát hiện Primary bị down và thực hiện failover. Để kiểm tra hoặc can thiệp thủ công khi Vtorc gặp sự cố.
Kiểm tra trạng thái failover trong Vtorc.
curl http://vtorc:8889/api/v1/replication_thread_state
Nếu Vtorc không tự động failover, thực hiện failover thủ công qua vtctl.
vtctl EmergencyReparentShard -keyspace ks1 -shard 0 -force
Lệnh này sẽ ép chọn một replica mới làm primary ngay lập tức, bỏ qua các kiểm tra phức tạp.
Verify lại cấu trúc shard sau failover.
vtctl GetShard -keyspace ks1 -shard 0
Kết quả mong đợi: Một tablet mới có trạng thái PRIMARY và các tablet khác chuyển thành REPLICA với master mới.
Điều hướng series:
Mục lục: Series: Triển khai Database Geo-distributed với Vitess trên Ubuntu 24.04
« Phần 6: Thực hiện các thao tác vận hành: Re-sharding và Data Migration