Chuẩn bị và Khởi tạo VReplication Workflow
Chúng ta sẽ sử dụng VReplication để di chuyển dữ liệu từ một shard cũ sang một shard mới mà không gây gián đoạn dịch vụ (zero-downtime). Cơ chế này dựa trên việc tạo một luồng replication từ source shard sang target shard, đồng bộ dữ liệu lịch sử và sau đó đồng bộ các thay đổi realtime.
Bước đầu tiên là xác định shard nguồn (source) và shard đích (target). Giả sử chúng ta đang làm việc với bảng orders hiện đang nằm trong shard -80 và cần di chuyển một phần dữ liệu (ví dụ: các đơn hàng có id > 50000) sang shard mới 80-120.
Tạo file định nghĩa workflow migration với cấu trúc JSON chi tiết tại đường dẫn /var/vt/vtdataroot/vtctl/streams/migration_workflows/orders_split.json:
{
"Cells": ["zone1"],
"Keyspace": "commerce",
"SourceShards": ["-80"],
"TargetShards": ["80-120"],
"TabletTypes": ["master"],
"Tables": ["orders"],
"CopyRows": true,
"MoveTables": true,
"VStreamFlags": {
"filter": "WHERE id > 50000"
},
"WorkflowName": "orders_split_workflow",
"WorkflowType": "MoveTables",
"EnableHeartbeat": true
}
Kết quả mong đợi: File JSON được tạo thành công, định nghĩa rõ ràng phạm vi dữ liệu cần di chuyển và các shard liên quan.
Khởi chạy Migration Workflow
Sử dụng lệnh vtctlclient để khởi tạo workflow dựa trên file cấu hình vừa tạo. Lệnh này sẽ kích hoạt các VReplication worker bắt đầu quá trình copy dữ liệu ban đầu (initial load) và thiết lập kênh replication realtime.
vtctlclient CreateStream --workflow=orders_split_workflow --source=commerce.-80 --target=commerce.80-120 --tables=orders --filter="WHERE id > 50000"
Hoặc sử dụng lệnh vtctld trực tiếp nếu cần cấu hình chi tiết hơn qua giao diện dòng lệnh tương tác:
vtctlclient StartVReplication --workflow=orders_split_workflow commerce.-80
Kết quả mong đợi: Hệ thống trả về thông báo Workflow started successfully và trạng thái của VReplication chuyển sang RUNNING. Dữ liệu bắt đầu được copy sang target shard.
Giám sát tiến trình Migration qua vtctld
Để theo dõi tiến độ, chúng ta truy cập giao diện web vtctld (thường chạy tại port 15000). Truy cập đường dẫn http://your-vtctld-host:15000/workflows và chọn keyspace commerce.
Trong bảng workflow, kiểm tra các chỉ số quan trọng:
- Position: Hiển thị vị trí binlog hiện tại (GTID) đã đồng bộ.
- Replication Lag: Khoảng trễ giữa source và target. Giá trị này phải giảm dần về 0.
- Tablet Status: Trạng thái của các tablet tham gia.
Kiểm tra trực tiếp qua CLI để xác nhận log chi tiết:
vtctlclient ShowVReplicationStatus commerce.-80
Kết quả mong đợi: Output hiển thị trạng thái State: running, GTID: [gtid_source] và Lag: 0s (hoặc rất nhỏ) khi quá trình bắt kịp dữ liệu realtime.
Thực hiện SplitTablet để Chia nhỏ Shard
Khi dữ liệu trong một shard tăng trưởng vượt quá ngưỡng tối ưu (ví dụ: > 100GB cho một bảng lớn), chúng ta cần chia nhỏ shard (split) để phân tán tải. Lệnh SplitTablet sẽ tự động chia một tablet thành hai hoặc nhiều tablet con dựa trên phạm vi key range (keyspace range).
Giả sử shard -80 đã quá tải, chúng ta sẽ chia nó thành hai phần: -60 và 60-80. Thao tác này yêu cầu xác định điểm chia (split point) dưới dạng hex string.
Thực thi lệnh chia tablet với điểm chia tại giá trị hex 60:
vtctlclient SplitTablet commerce.-80 60
Giải thích tham số:
commerce.-80: Tablet nguồn cần chia.60: Điểm chia (split point). Phạm vi mới sẽ là -60 và 60-80.
Kết quả mong đợi: Hệ thống tạo ra hai tablet mới commerce.-60 và commerce.60-80. Tablet gốc commerce.-80 sẽ bị vô hiệu hóa (shutdown) hoặc chuyển đổi trạng thái sau khi dữ liệu được phân chia xong.
Verify kết quả SplitTablet
Để xác nhận việc chia tablet thành công, liệt kê toàn bộ tablets trong keyspace và kiểm tra trạng thái cũng như key range của chúng.
vtctlclient ListShards commerce
Kết quả mong đợi: Output hiển thị 2 shard mới thay thế shard cũ, với các key range -60 và 60-80. Trạng thái của các tablet mới phải là MASTER (hoặc REPLICA tùy cấu hình ban đầu) và sẵn sàng nhận traffic.
Cấu hình Workflow Migration An toàn với Rollback
Trong môi trường production, việc di chuyển dữ liệu luôn tiềm ẩn rủi ro. Chúng ta cần cấu hình cơ chế Rollback tự động để nếu quá trình migration gặp sự cố (ví dụ: lag quá lớn, lỗi checksum), hệ thống tự động dừng và đảo ngược lại trạng thái ban đầu.
Tạo file cấu hình an toàn tại /var/vt/vtdataroot/vtctl/configs/migration_safety.json để định nghĩa các ngưỡng kích hoạt rollback:
{
"workflow": "orders_split_workflow",
"keys": "commerce",
"max_lag_seconds": 300,
"max_error_count": 5,
"auto_rollback": true,
"rollback_threshold_percent": 10,
"final_cutover_mode": "manual",
"verification_checksum": true
}
Áp dụng cấu hình này vào workflow đang chạy bằng lệnh UpdateVReplicationWorkflow (giả định extension API hoặc script tùy chỉnh, nếu dùng vanilla vtctlclient thì cấu hình thường nằm trong tham số khởi tạo, nhưng để minh họa quy trình an toàn, ta sử dụng lệnh điều chỉnh trạng thái):
vtctlclient UpdateWorkflow commerce orders_split_workflow --max-lag=300 --auto-rollback=true
Khi quá trình migration đang chạy, nếu lag vượt quá 300 giây, VReplication sẽ tự động chuyển trạng thái sang ERROR và kích hoạt rollback nếu cấu hình auto_rollback là true.
Kiểm tra xem cơ chế rollback đã được kích hoạt chưa:
vtctlclient ShowVReplicationStatus commerce.-80 | grep -i "rollback"
Kết quả mong đợi: Nếu có lỗi, output sẽ hiển thị thông báo Rollback initiated due to high lag hoặc trạng thái Rolling back.
Thực hiện Cutover và Rollback thủ công
Khi migration hoàn tất (100% dữ liệu đã đồng bộ và lag = 0), chúng ta thực hiện Cutover để chuyển traffic từ source sang target.
vtctlclient WorkflowCutover commerce orders_split_workflow
Ngược lại, nếu muốn hủy bỏ migration và quay lại trạng thái cũ (Rollback), thực thi:
vtctlclient WorkflowRollback commerce orders_split_workflow
Kết quả mong đợi:
- Sau
Cutover: Source shard bị khóa (readonly) hoặc xóa, target shard trở thành master chính thức. Traffic được chuyển hướng hoàn toàn.
- Sau
Rollback: Dữ liệu được đồng bộ ngược từ target về source (nếu cần), và source shard được khôi phục trạng thái master.
Giám sát Hiệu năng và Troubleshooting Migration
Trong quá trình migration, việc giám sát hiệu năng là bắt buộc để đảm bảo không ảnh hưởng đến dịch vụ production. Chúng ta tập trung vào các chỉ số: CPU của tablet, I/O disk, và Network throughput.
Truy cập vào vtctld -> Topology -> Chọn tablet -> Tab Metrics để xem biểu đồ realtime. Các chỉ số quan trọng cần theo dõi:
- Replication Lag: Phải duy trì ở mức thấp (< 1s).
- Bytes Sent/Received: Đảm bảo không bão hòa đường truyền mạng.
- Query Latency: Kiểm tra xem các query trên source shard có bị chậm do VReplication không.
Để kiểm tra log chi tiết của VReplication trên server, truy cập file log tại /var/log/vt/vttablet/vttablet.log:
tail -f /var/log/vt/vttablet/vttablet.log | grep -i "vreplication"
Nếu phát hiện lỗi Tablet is not in sync hoặc Checksum mismatch, thực hiện lệnh kiểm tra checksum để xác minh tính toàn vẹn dữ liệu:
vtctlclient RunVReplicationCheck commerce.-80
Kết quả mong đợi: Output hiển thị Checksum: OK nếu dữ liệu giữa source và target khớp nhau. Nếu có lỗi, log sẽ hiển thị chi tiết dòng dữ liệu bị sai lệch để kỹ sư có thể xử lý.
Verify toàn bộ quy trình
Sau khi hoàn tất migration và cutover, thực hiện một series kiểm tra cuối cùng để đảm bảo hệ thống hoạt động ổn định:
vtctlclient ListShards commerce
mysql -h -P -u -p -e "SELECT COUNT(*) FROM orders WHERE id > 50000;"
vtctlclient ShowVReplicationStatus commerce.-80
Kết quả mong đợi:
- Shard mới
80-120 hiện diện trong danh sách và đang ở trạng thái MASTER.
- Query đếm dữ liệu trên target shard trả về kết quả chính xác.
- Trạng thái VReplication chuyển sang
STOPPED hoặc COMPLETE sau khi cutover.
Đ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 5: Cấu hình cân bằng tải và chiến lược phân phối dữ liệu toàn cầu
Phần 7: Giám sát hiệu năng, Troubleshooting và các mẹo nâng cao »