Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production

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

Phần 3 của series "Evaluating MySQL Parallel Replication" (Jean-François Gagné); phần trước: Booking.com 2015 (cơ chế, intermediate master) → Booking.com 2015; phần tiếp: Booking.com 2016. Các annex "Under the Hood" không ingest. Sheet trỏ tới annex của phần 4. Đọc qua trình duyệt (Medium chặn crawler); ghi chú bằng lời của wiki.

Bối cảnh

• Replication của MySQL lúc đó đơn luồng trên slave: muốn không có replication lag, master chỉ được ghi bằng khoảng một core, dù máy có 12 core trở lên. Đây là trần ghi của mỗi cụm.
• Parallel replication có trong MariaDB 10.0 và MySQL 5.7; benchmark đã công bố hứa 10 lần (MariaDB) và 3 đến 6 lần (MySQL). Booking muốn biết con số trên workload thật.
• Kỳ vọng của Booking: dùng được khoảng 25% số core cho ghi, tức tăng tốc 3 lần là tốt (12 core), về sau cần 6 đến 10 lần (24 và 40 core).

Thay đổi chính (cách đo)

• Slave muốn chạy song song cần thông tin "transaction nào chạy song song được" từ master, mà master của Booking vẫn là MySQL 5.6. Mẹo: dùng slave group commit trên một intermediate master MariaDB: chạy tuần tự nhưng hoãn commit, transaction kế tiếp bắt đầu trong lúc chờ; nếu hai cái commit cùng nhóm thì chúng không xung đột. Nhóm thu được thường từ 5, phần lớn trên 10, có lúc 15–20.
• Bốn môi trường production (E1–E4), mỗi môi trường một master, vài intermediate master, một slave lá. Bài test: khôi phục backup, chạy slave ít nhất 12 giờ, rồi đo thời gian đuổi kịp 24 giờ transaction thật.
• Thay đổi cấu hình binlog (intermediate master có log-slave-updates; slave có binlog; slave không binlog), độ bền (cao: sync_binlog=1, innodb_flush_log_at_trx_commit=1; thấp: 0 và 2), và số luồng slave_parallel_threads.

Kết quả (theo Booking)

• Không liên quan song song: tắt binlog trên slave gần như không nhanh hơn, nên nên giữ binlog trên slave (để truy transaction lạc và để slave đủ điều kiện được promote). log-slave-updates thì có giá rõ, nên thay intermediate master bằng Binlog Server.
• Giảm độ bền là thắng lớn với workload CPU-bound (E1, E2), ít tác dụng với workload IO-bound (E4).
• Parallel replication: tốt nhất khoảng 2,10 lần (E2, độ bền cao), E1 khoảng 1,56; E4 (IO-bound) khoảng 1,29. Với độ bền thấp, song song gần như không thêm gì (dưới 1,10). Với E1 và E2, đơn luồng + giảm độ bền còn nhanh hơn song song + độ bền cao.
• Kết luận của Booking: thất vọng. Ghi thêm 25% (hay 110% tuỳ môi trường) không đủ dài hạn; parallel replication không phải lời giải (ít nhất không phải lời giải duy nhất) để tránh sharding.
• Giả thuyết: transaction dài làm tắc pipeline song song (cả nhóm phải chờ cái chậm nhất). Nhiều thiết kế của Booking có từ trước MySQL 5.6, khi commit đắt nên gom nhiều thay đổi vào một transaction; tối ưu đó nay hại cho parallel replication. Muốn nhanh hơn thì các transaction nên cỡ ngang nhau, cắt nhỏ cái lớn.

Bài học cho SWE

• Replication lag đặt trần cho tốc độ ghi của cả cụm master–replica, không chỉ cho độ tươi của replica (Failover, replica và dự phòng dữ liệu).
• Benchmark của nhà phát triển phần mềm không thay được workload thật; Booking dựng được test bằng dữ liệu production dù master còn ở bản cũ.
• Tính năng mới không cứu được workload có hình dạng sai (transaction lớn không đều); tối ưu hợp với thời trước (ít commit) có thể thành vật cản ở thời sau.
• Khi tối ưu ở một máy không đủ xa, sharding vẫn là đường dài hạn (Sharding và tách database).

Liên quan

• Booking.com 2015 · Booking.com 2015
• Phần tiếp: Booking.com 2016 · cùng công ty: Booking.com 2014
• Failover, replica và dự phòng dữ liệu · Sharding và tách database · Scale dọc trước khi scale ngang