Cấu hình chiến lược Sharding Key và cân bằng tải nội bộ
Thiết lập Uniform Hash để phân bổ dữ liệu đồng đều
Để đảm bảo dữ liệu được phân tán đồng đều giữa các Shard, ta cần sử dụng chiến lược Uniform Hash. Chiến lược này sử dụng hàm băm SHA1 trên giá trị của Sharding Key (thường là user_id) và ánh xạ kết quả vào khoảng [0, MAX_UINT64] trước khi gán vào Shard.
Thao tác này được thực hiện thông qua vtorc và vreplication để đảm bảo tính nhất quán khi thực hiện Re-sharding trong tương lai, nhưng ở giai đoạn này, ta cần định nghĩa rõ ràng trong file cấu hình Vitess.
Truy cập vào file cấu hình của bảng (schema) hoặc file cấu hình của vtorc để xác định key range. Ta sẽ tạo file cấu hình cho bảng chính.
cat > /etc/vitess/vtgate/config/sharding_strategy.json
Kết quả mong đợi: File JSON được tạo thành công tại đường dẫn trên, định nghĩa rõ 4 shard với các khoảng giá trị băm cụ thể, đảm bảo dữ liệu được chia đều.
Thiết lập cân bằng tải (Load Balancing) giữa các Tablet
Vitess sử dụng cơ chế "Round Robin" mặc định để phân phối query đọc (SELECT) đến các Tablet có trạng thái REPLICA hoặc RDONLY trong cùng một Shard. Để tối ưu, ta cần cấu hình vtorc để nó ưu tiên các tablet có độ trễ thấp nhất hoặc tải thấp nhất.
Chỉnh sửa file cấu hình của Vitess Gateway (vtgate) để áp dụng chính sách cân bằng tải.
cat > /etc/vitess/vtgate/config/vtgate_config.json
Kết quả mong đợi: vtgate sẽ ưu tiên gửi request đọc đến tablet có ít kết nối đang hoạt động nhất, giảm tải cho các node bị quá tải.
Verify kết quả cân bằng tải
Thực hiện lệnh sau để kiểm tra số lượng kết nối và trạng thái của các tablet trong cùng một shard.
vtctl --keyspace=commerce --shard=0 GetTablets | jq '.Tablets[] | select(.TabletType == "REPLICA") | .Hostname'
Kết quả mong đợi: Danh sách các hostname của các tablet REPLICA được trả về. Sau khi chạy test load, ta kiểm tra lại thông qua Prometheus hoặc `vttablet -stats` để thấy số lượng query được phân bổ tương đối đều.
Cấu hình Cross-Cell Replication (Đồng bộ toàn cầu)
Thiết lập quan hệ Master-Slave giữa các Cell
Để dữ liệu được đồng bộ từ Cell gốc (Primary Region) sang các Cell phụ (Read-only Regions), ta cần cấu hình Cross-Cell Replication. Đây là bước quan trọng nhất để xây dựng kiến trúc Geo-distributed.
Trên Cell gốc (ví dụ: `us-east`), ta cần khai báo các Cell đích (ví dụ: `eu-west`, `ap-south`) trong file cấu hình vtorc hoặc trực tiếp qua `vtctl`.
cat > /etc/vitess/vtctl/config/cross_cell_replication.json
Kết quả mong đợi: File cấu hình được tạo, định nghĩa rõ Cell chủ và các Cell phụ cần nhận dữ liệu.
Khởi tạo luồng Replication giữa các Cell
Sử dụng `vtctl` để khởi tạo luồng replication. Lệnh này sẽ tạo một VReplication workflow để đồng bộ dữ liệu từ Primary Shard của Cell `us-east` sang các Shard tương ứng ở `eu-west` và `ap-south`.
Thao tác này cần thực hiện trên node `vtctl` của Cell gốc.
vtctl --cell=us-east InitShardPrimary commerce -80 us-east-0000000101
Đợi Primary được chọn, sau đó thực hiện lệnh khởi tạo replication stream cho từng Cell đích.
vtctl --cell=us-east UpdateReplicationPositions commerce -80 --cells=eu-west,ap-south --source=us-east-0000000101
Kết quả mong đợi: Vitess sẽ bắt đầu quá trình đồng bộ dữ liệu ban đầu (initial load) và sau đó theo dõi binlog để đồng bộ incremental changes. Bạn sẽ thấy trạng thái `VReplication` chuyển sang `RUNNING`.
Verify Cross-Cell Replication
Chạy lệnh sau trên Cell đích (ví dụ `eu-west`) để kiểm tra trạng thái đồng bộ.
vtctl --cell=eu-west Status commerce -80
Kết quả mong đợi: Thông báo trạng thái replication, hiển thị `Lag` (độ trễ) gần bằng 0 giây và `Status` là `Running` hoặc `Healthy`. Nếu có lỗi, thông báo sẽ hiển thị chi tiết nguyên nhân (ví dụ: network unreachable hoặc schema mismatch).
Tối ưu hóa Query Routing theo vị trí địa lý
Cấu hình Local Read Strategy
Mục tiêu là đảm bảo người dùng tại Châu Âu (EU) chỉ truy cập vào dữ liệu tại Cell `eu-west` thay vì phải đi qua Cell `us-east`. Ta sẽ cấu hình vtgate để ưu tiên đọc từ Cell địa phương nếu Cell đó có dữ liệu đồng bộ (Replica).
Sửa file cấu hình vtgate của Cell đích (`eu-west`) để kích hoạt chế độ "Local First".
cat > /etc/vitess/vtgate/config/vtgate_local_read.json
Kết quả mong đợi: vtgate tại Cell `eu-west` sẽ ưu tiên phân phối query SELECT đến các tablet local trước khi forward về `us-east`.
Định tuyến Write về Cell gốc (Primary)
Trong mô hình Geo-distributed, tất cả các thao tác ghi (INSERT, UPDATE, DELETE) phải được định tuyến về Cell gốc (Primary) để đảm bảo tính nhất quán (ACID), sau đó mới được đồng bộ về các Cell phụ.
Cấu hình vtgate của tất cả các Cell phụ để chặn write local và force về Primary.
cat > /etc/vitess/vtgate/config/vtgate_write_routing.json
Kết quả mong đợi: Khi client tại `eu-west` gửi lệnh INSERT, vtgate sẽ tự động forward request này về `us-east` thay vì thực thi tại chỗ, đảm bảo dữ liệu luôn được ghi vào Master.
Verify Query Routing và Latency
Thực hiện test query từ một client đặt tại vị trí địa lý khác nhau (hoặc giả lập bằng proxy) để đo độ trễ.
mysql -h vtgate-eu-west -u vt -pcommerce -e "SELECT SLEEP(0.1); EXPLAIN SELECT * FROM orders WHERE user_id = 123;"
Kết quả mong đợi: Query EXPLAIN sẽ hiển thị thông tin về việc query được định tuyến. Nếu cấu hình đúng, query đọc sẽ được thực thi tại `eu-west` (latency thấp), trong khi query viết sẽ hiển thị thông tin route về `us-east`.
Sử dụng công cụ `vtgate -stats` để xem số lượng request được xử lý local so với request được forward đi.
curl http://vtgate-eu-west:15999/stats
Kết quả mong đợi: Các metric như `LocalReads` tăng cao, trong khi `CrossCellReads` thấp, chứng tỏ chiến lược cân bằng tải theo vị trí đang hoạt động hiệu quả.
Đ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 4: Triển khai kiến trúc Geo-distributed với nhiều Cell và Region
Phần 6: Thực hiện các thao tác vận hành: Re-sharding và Data Migration »