Cloud Native MySQL Sharding with Vitess and Kubernetes

Vitess (PlanetScale/CNCF) · 2015 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của engineer YouTube giới thiệu Vitess 2.0 (khi đó còn alpha) chạy trên Kubernetes, kèm walkthrough resharding. Phần về YouTube là theo Vitess; benchmark là sơ bộ.

Bối cảnh

• Vitess ra đời ở YouTube để scale MySQL (theo bài tháng 3/2015 cùng tác giả: metadata cho hàng tỉ lượt xem mỗi ngày, 300 giờ video mới mỗi phút), giấu độ phức tạp của sharding khỏi tầng ứng dụng. Con đường quen thuộc: thêm replica để đọc → shard để ghi → pool replica riêng cho batch và backup → nhân bản sang nhiều data center.
• Mục tiêu năm 2015: làm cho scale datastore có trạng thái trên Kubernetes đơn giản như scale app server stateless.
• Theo bài, sharding là "thuốc đắng" (dẫn Asana): làm phức tạp logic ứng dụng và nhân việc quản trị; nhưng trên cloud thì càng cần, vì một node chỉ lớn được tới mức nào đó.

Thay đổi chính

• Vitess 2.0 (alpha): API Kubernetes 1.0, client chính thức Java/Python/PHP/Go (gRPC), chạy trên MySQL 5.6 ngoài MariaDB, backup/restore tích hợp với blob store, reparent dựa trên GTID cho failover thường lệ đảo ngược được, đổi schema đơn giản hơn.
• Shard theo khoảng trên keyspace ID: mỗi khoá được băm thành một giá trị 8 byte phân bố đều (consistent hashing), mỗi shard nhận một khoảng giá trị; không cần bảng tra khoá → shard, và đổi số shard chỉ là chia lại khoảng.
• Resharding trong suốt, đang chạy:
  1. Dựng shard mới chạy song song, chưa nhận traffic.
  2. Chép schema và dữ liệu từ shard cũ; sau snapshot ban đầu, filtered replication tự chuyển các DML mới chỉ tới shard đích liên quan.
  3. Công cụ so sánh từng dòng giữa bản gốc và bản chép.
  4. Lệnh migrate: tắt ghi ở master cũ, chờ master mới nhận nốt sự kiện, bật ghi ở master mới; theo bài thường chỉ khoảng một giây không ghi được.
  5. Ứng dụng không cần biết từ một shard thành hai: Vitess tự định tuyến lại.
• Theo Vitess, trong năm trước đó YouTube đã reshard (ngang và dọc) gần như mọi database MySQL của họ theo cách này.
• Benchmark YCSB trên Google Container Engine: thông lượng ghi tăng gần tuyến tính theo số shard (ngưỡng: latency ghi trung bình trên 15 ms hoặc p99 trên 50 ms); thông lượng đọc tăng theo số replica.

Vì sao

• Đưa logic định tuyến shard và việc quản trị từng shard xuống một tầng chung, để team nhỏ quản một đội máy lớn và ứng dụng giữ đơn giản.

Bài học cho SWE

• Băm khoá vào một không gian lớn rồi chia khoảng cho shard làm resharding thành chia đôi khoảng, không phải băm lại mọi thứ (Sharding và tách database).
• Mẫu resharding online: snapshot → replication có lọc → kiểm tra → cutover ngắn bằng cách tắt ghi bên cũ và chờ bên mới bắt kịp; cùng khung với nhiều migration khác trong wiki (Migration không downtime).
• Tầng proxy định tuyến (vtgate) là thứ làm cho thay đổi topology trong suốt với ứng dụng.

Liên quan

• Cùng công ty: Vitess (PlanetScale/CNCF) 2022 · Vitess (PlanetScale/CNCF) 2022 · Vitess (PlanetScale/CNCF) 2026
• Slack 2020 (một khách hàng lớn chuyển sang Vitess)
• Sharding và tách database · Migration không downtime