Evaluating MySQL Parallel Replication Part 4: More Benchmarks in Production

Booking.com · 2016 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Phần 4 của series; phần trước: Booking.com 2015. Annex "Under the Hood" không ingest riêng. Đọc qua trình duyệt (Medium chặn crawler); ghi chú bằng lời của wiki.

Bối cảnh

• Phần 3 đo parallel replication kiểu "bảo thủ" (MariaDB 10.0): master đánh dấu transaction nào song song được, slave chỉ chạy song song những cái đó. Kết quả chỉ 1,3 đến 2,1 lần.
• MariaDB 10.1 thêm kiểu optimistic: slave không cần master đánh dấu.

Thay đổi chính (cơ chế)

• Commit đúng thứ tự (in-order commit): MariaDB commit transaction trên slave theo đúng thứ tự trong binlog của master; MySQL mặc định commit khi xong, thứ tự binlog của slave có thể khác master.
• In-order commit có thể sinh deadlock mà storage engine không thấy: T2 giữ tài nguyên T1 cần (engine biết), còn T1 phải commit trước T2 (chỉ code replication biết). Applier phải phát hiện, kill T2, để T1 chạy, rồi chạy lại T2. Ở 10.0 việc này hiếm: một slave khoảng 2.500 transaction/giây chỉ có 3 lần thử lại trong 4 phút.
• Khi đã có phát hiện và giải deadlock, bước tiếp theo đơn giản: chạy mọi transaction song song, để in-order commit giữ dữ liệu nhất quán và rollback + chạy lại khi xung đột. Đó là optimistic parallel replication. Miễn ít xung đột (hay chi phí rollback nhỏ hơn lợi ích), nó nhanh hơn.
• Cùng bài test như phần 3 (đuổi kịp 24 giờ transaction), so kiểu bảo thủ với kiểu aggressive (biến thể optimistic dùng được qua intermediate master), số luồng tăng theo thang log.

Kết quả (theo Booking)

• Optimistic gần như luôn tốt hơn bảo thủ, kể cả khi độ bền thấp (chỗ bảo thủ gần như không giúp gì).
• Tăng tốc vẫn tăng khi số luồng vượt xa số core (máy 12 core, 24 luồng phần cứng): còn tăng sau 80 luồng, môi trường E3 đến 2.560 luồng. Giải thích của Booking: replication prefetching. Nhiều luồng khiến transaction cần dữ liệu ngoài cache đọc đĩa sớm hơn; luồng chờ IO không tốn CPU, và dù transaction bị rollback thì dữ liệu đã nằm trong cache cho lần chạy lại.
• Tăng tốc cao nhất 3,78 lần lại ở workload IO-bound (E4): lợi ích chính là gửi nhiều IO song song để lấy thêm IOPS từ đĩa từ. Workload thuần CPU (E2) có dấu hiệu tranh chấp khi quá nhiều luồng.
• Vẫn xa mức 6 đến 10 lần mong muốn. Một nghi phạm là DDL: DDL chặn pipeline (mọi transaction trước phải commit, sau phải chờ DDL xong). E1 có khoảng 197.000 CREATE TABLE trong lần chạy, trung bình 27 lần mỗi giây, phần lớn là CREATE TABLE IF NOT EXISTS; kiểm tra tồn tại trước có thể là thắng lớn.
• Mọi test dùng đĩa từ; chưa rõ hành vi trên SSD.

Bài học cho SWE

• Cách lạc quan (chạy hết, xung đột thì làm lại) thường thắng cách bảo thủ (chỉ chạy cái được chứng minh an toàn) khi xung đột hiếm, nhưng cần sẵn cơ chế phát hiện và làm lại (Failover, replica và dự phòng dữ liệu).
• Một kỹ thuật có thể thắng vì lý do khác với lý do thiết kế: ở đây song song thắng nhờ prefetch IO, không nhờ dùng thêm CPU.
• Thói quen của ứng dụng (DDL liên tục, CREATE TABLE IF NOT EXISTS mỗi lần) có thể là nút thắt của replication; đếm từ binlog để tìm.
• Công ty đóng góp ngược cho cộng đồng: Booking mở bug và yêu cầu tính năng (thống kê các lần pipeline bị tắc) từ kết quả đo.

Liên quan

• Phần trước: Booking.com 2015 · Booking.com 2014
• Failover, replica và dự phòng dữ liệu