Cấu hình số lượng replica và phân vùng Region/Zone
Bước đầu tiên để đảm bảo High Availability (HA) là phân tán dữ liệu TiKV sang các vùng (Region) và Availability Zone (AZ) khác nhau. Điều này giúp cluster vẫn hoạt động ngay cả khi một cloud provider hoặc một datacenter gặp sự cố.
TiDB sử dụng PD (Placement Driver) để quyết định vị trí lưu trữ dữ liệu. Chúng ta cần cấu hình các label (nhãn) cho các node TiKV để PD nhận diện được vị trí vật lý của chúng (region, zone).
Trên node TiKV, ta cần đảm bảo các node có label khác nhau tương ứng với từng Region hoặc Zone. Dưới đây là ví dụ cấu hình file tikv.toml trên một node thuộc Region 1, Zone A.
Đường dẫn: /etc/tikv/tikv.toml (hoặc file cấu hình trong configmap nếu dùng Helm/Operator).
[label]
zone = "us-east-1a"
region = "us-east-1"
Tương tự, trên node thuộc Region 2 (ví dụ AWS us-west-2), nội dung file /etc/tikv/tikv.toml sẽ là:
[label]
zone = "us-west-2a"
region = "us-west-2"
Sau khi cập nhật file cấu hình, ta cần restart dịch vụ TiKV để áp dụng label mới.
systemctl restart tikv
Kết quả mong đợi: Khi chạy lệnh pd-ctl, các store mới sẽ hiện label đúng theo cấu hình.
Để xác nhận PD đã nhận diện đúng số lượng replica và phân bố chúng, ta cần cấu hình quy tắc phân tán (Placement Rules) trong PD. Mặc định TiDB giữ 3 replica. Để HA Cross-Region, ta cần đảm bảo mỗi replica nằm ở một zone khác nhau.
Truy cập vào PD (thường là port 2379) và chạy lệnh sau để tạo quy tắc mới cho dữ liệu phân tán:
curl -X POST http://pd-server:2379/pd/api/v1/config/placement-rules -H "Content-Type: application/json" -d '{
"id": "default",
"group_id": "default",
"index": 1,
"count": 3,
"rules": [
{
"id": "leader",
"group_id": "default",
"index": 1,
"count": 1,
"location_labels": ["region"]
},
{
"id": "follower-1",
"group_id": "default",
"index": 2,
"count": 1,
"location_labels": ["region", "zone"]
},
{
"id": "follower-2",
"group_id": "default",
"index": 3,
"count": 1,
"location_labels": ["region", "zone"]
}
]
}'
Lệnh này thiết lập một Leader và hai Followers, bắt buộc chúng phải nằm ở các Region hoặc Zone khác nhau. Nếu một Region bị mất, PD sẽ tự động di chuyển (rebalance) Leader sang Region còn lại.
Kiểm tra kết quả bằng lệnh sau để xem trạng thái của các store:
curl http://pd-server:2379/pd/api/v1/stores
Kết quả mong đợi: JSON trả về sẽ hiển thị các store có label "region" và "zone" khác nhau, và trạng thái "state_name" là "Up".
Thiết lập cơ chế tự động failover khi mất vùng đám mây
Khi một Region bị mất hoàn toàn (ví dụ mất cả AWS us-east-1), PD cần được cấu hình để tự động kích hoạt failover mà không cần can thiệp thủ công của Admin.
Chìa khóa của cơ chế này là tham số enable-replication-scheduler trong PD và các tham số liên quan đến "Region/Zone" trong cấu hình failover.
Cấu hình file pd.toml để bật tính năng tự động cân bằng và failover dựa trên Region.
Đường dẫn: /etc/pd/pd.toml
[replication]
enable-placement-rules = true
location-labels = ["region", "zone"]
[scheduler]
enable-replication-scheduler = true
Sau khi cập nhật file, restart dịch vụ PD:
systemctl restart pd
Tuy nhiên, để đảm bảo failover nhanh hơn, ta cần điều chỉnh tham số max-store-down-time và max-leader-down-time trong runtime của PD thông qua API. Điều này giúp PD nhanh chóng nhận diện một Region bị down và di chuyển Leader sang Region khác.
Chạy lệnh để giảm thời gian chờ nhận diện lỗi xuống 30 giây (mặc định thường là 10 phút):
curl -X POST http://pd-server:2379/pd/api/v1/config -H "Content-Type: application/json" -d '{
"max-store-down-time": "30s",
"max-leader-down-time": "30s"
}'
Kết quả mong đợi: Khi bạn tắt (shutdown) một node TiKV thuộc một Region cụ thể, PD sẽ tự động chọn Leader mới từ Region còn lại trong vòng 30-60 giây. Dữ liệu vẫn khả dụng (Read/Write) nhờ các replica ở Region khác.
Để kiểm tra cơ chế này, ta có thể mô phỏng sự cố bằng cách tắt một pod TiKV hoặc node máy chủ thuộc Region 1, sau đó quan sát log của PD.
journalctl -u pd -f | grep "transfer leader"
Kết quả mong đợi: Log sẽ hiển thị thông báo "transfer leader" hoặc "schedule leader" sang một store thuộc Region khác (ví dụ từ us-east-1 sang us-west-2).
Cấu hình Backup tự động và Restore Cross-Region
High Availability chỉ giải quyết sự cố phần cứng hoặc vùng dữ liệu tạm thời. Để Disaster Recovery (DR) hoàn chỉnh, ta cần sao lưu dữ liệu ra một nơi an toàn (thường là Object Storage như S3) và có khả năng khôi phục sang một Region mới nếu toàn bộ Cluster hiện tại bị mất.
Chúng ta sẽ sử dụng tidb-lightning và br (Backup & Restore) với chế độ full backup định kỳ lên AWS S3 hoặc MinIO.
Bước 1: Tạo một file cấu hình backup backup.toml để lưu trữ vào S3 Cross-Region.
Đường dẫn: /root/backup-config/backup.toml
[full]
backend = "s3"
[s3]
region = "us-east-1"
bucket = "tidb-disaster-recovery"
endpoint = "https://s3.us-east-1.amazonaws.com"
access_key = "YOUR_ACCESS_KEY"
secret_access_key = "YOUR_SECRET_ACCESS_KEY"
[check-requirements]
check-memory = false
check-disk = false
Để tự động hóa quá trình này, ta tạo một cron job chạy lệnh br mỗi ngày vào lúc 2 giờ sáng.
crontab -e
Thêm dòng sau vào file crontab:
0 2 * * * /usr/local/bin/br backup full --config /root/backup-config/backup.toml --pd http://pd-server:2379 >> /var/log/tidb-backup.log 2>&1
Lệnh này sẽ thực hiện backup toàn bộ cluster hiện tại (bao gồm cả metadata và data) vào bucket S3. Bucket này có thể đặt ở một Region khác để đảm bảo an toàn tuyệt đối.
Khi xảy ra sự cố nghiêm trọng cần khôi phục (Disaster Recovery), ta sẽ sử dụng file cấu hình restore để khôi phục dữ liệu vào một Cluster TiDB mới được khởi tạo ở Region khác.
Tạo file cấu hình restore restore.toml.
Đường dẫn: /root/restore-config/restore.toml
[full]
backend = "s3"
[s3]
region = "us-east-1"
bucket = "tidb-disaster-recovery"
endpoint = "https://s3.us-east-1.amazonaws.com"
access_key = "YOUR_ACCESS_KEY"
secret_access_key = "YOUR_SECRET_ACCESS_KEY"
[lightning]
check-requirements = false
Thực hiện lệnh restore trên Cluster mới (đã cài đặt sẵn TiDB, TiKV, PD) ở Region mới:
/usr/local/bin/br restore full --config /root/restore-config/restore.toml --pd http://new-pd-server:2379
Kết quả mong đợi: Lệnh br sẽ bắt đầu quá trình khôi phục, hiển thị tiến độ phần trăm. Sau khi hoàn tất, dữ liệu trong database mới sẽ giống hệt dữ liệu tại thời điểm backup.
Để verify kết quả restore, ta truy cập vào TiDB mới và kiểm tra số lượng bảng và dữ liệu:
mysql -h new-tidb-server -P 4000 -u root -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'tidb'); SELECT COUNT(*) FROM your_database.your_table LIMIT 1;"
Kết quả mong đợi: Số lượng bảng và dữ liệu mẫu khớp với thời điểm backup cuối cùng. Database đã sẵn sàng phục vụ traffic sau khi Disaster Recovery.
Điều hướng series:
Mục lục: Series: Triển khai Database Multi-Cloud với TiDB và Ubuntu 24.04
« Phần 4: Mở rộng TiDB sang Multi-Cloud: Cấu hình Cross-Region
Phần 6: Tối ưu hiệu năng và quản lý tài nguyên trong môi trường phân tán »