Scaling Etsy Payments with Vitess: Part 3 – Reducing Cutover Risk

Phần 3/3. Phần 1: Etsy 2023 · Phần 2: Etsy 2023.

Etsy · 2023 · 4. Điều chỉnh · Độ khó: Nâng cao — bài gốc

Bối cảnh

• Tác giả ở đội Data Access Platform (giữ ORM nội bộ của Etsy; đã upstream hơn 30 patch vào Vitess và giữ một fork nội bộ). Vai trò: đảm bảo query do ORM sinh ra tương thích vindex và cấu hình Vitess giữ đúng đảm bảo dữ liệu mà ứng dụng cần.
• Vitess che sharding khá tốt, nhưng có những loại lỗi chỉ xuất hiện sau khi chuyển từ keyspace chưa shard sang đã shard.

Thay đổi chính

• Transaction mode: mặc định multi cho transaction xuyên shard nhưng có thể commit một phần (transaction lỗi mà vẫn còn ghi trên vài shard). twopc theo tài liệu Vitess là thử nghiệm, chậm. Etsy chọn single: giữ đảm bảo transaction quen thuộc, query nhiều shard trong transaction thì lỗi; có lối thoát SET transaction_mode theo kết nối. Trước cutover rà tay mọi chỗ dùng transaction (log SQL, xác định shard đích); không có lỗi transaction mode khi cutover.
• Reverse VReplication (đường lùi) từng hỏng ở môi trường dev vì unique key trong keyspace shard chỉ duy nhất trong từng shard; ghi ngược về DB chưa shard thì vi phạm. Có alert page khi hỏng và runbook sửa (xoá dòng hoặc bỏ qua vị trí trong _vt.vreplication); production không hỏng. Sau mới biết Vitess có cách ép unique toàn cục.
• Scatter query (quên khoá shard trong WHERE) nhân tải theo số shard và có thể làm sập cả keyspace. Dùng vtexplain/EXPLAIN FORMAT=vitess trước cutover. Theo đề nghị của Etsy, PlanetScale thêm cờ --no_scatter: mặc định chặn scatter, cho phép từng query bằng comment ALLOW_SCATTER; chỉ query scatter vô tình bị lỗi thay vì cả keyspace sập.
• Query không tương thích: ví dụ scatter + GROUP BY trên cột VARCHAR làm mất kết nối ở phiên bản Vitess lúc đó; né bằng CAST(... AS BINARY) (sau này Vitess đã sửa). Test toàn bộ query của ứng dụng ở dev trước cutover.

Vì sao

• Cutover thường đảo được nếu reverse replication còn sống, nhưng gián đoạn ngắn trên dữ liệu thanh toán vẫn đắt; giảm rủi ro bằng test trước rẻ hơn.

Bài học cho SWE

• Chọn ngữ nghĩa transaction dễ giải thích cho developer không chuyên DB (lỗi rõ ràng) hơn ngữ nghĩa linh hoạt mà bất ngờ (commit một phần).
• Ràng buộc toàn cục (unique key) đổi nghĩa khi shard; kiểm cả đường lùi chứ không chỉ đường tiến.
• Mặc định an toàn (chặn scatter) chuyển lỗi từ "sập hệ thống" sang "một query lỗi".

Liên quan

• Sharding và tách database · Migration không downtime · Giao dịch phân tán và nhất quán xuyên service
• Shard Vitess ở Cash App: Square 2018