Better Parallel Replication for MySQL

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

Phần 1 của series "Evaluating MySQL Parallel Replication" (Jean-François Gagné); phần tiếp: Booking.com 2015 → Booking.com 2015 → Booking.com 2016. Đọc qua trình duyệt (Medium chặn crawler); ghi chú bằng lời của wiki.

Bối cảnh

• MySQL 5.5 và MariaDB 5.5 replicate đơn luồng: trên slave, transaction trước phải commit xong thì transaction sau mới chạy, trong khi master chạy nhiều transaction cùng lúc. Slave vì vậy ghi chậm hơn master, và master không được nhận nhiều ghi hơn mức slave theo kịp, nếu không slave sẽ lag.
• Máy ngày càng nhiều core, MySQL ngày càng dùng tốt nhiều core, nhưng không cải tiến nào giúp được luồng apply duy nhất trên slave.
• MySQL 5.6 chạy song song các transaction khác schema (coi như không xung đột). Còn transaction cùng schema thì chưa.

Cơ chế: lấy song song từ group commit

• MariaDB 10.0 và MySQL 5.7 dựa vào binary log group commit: các transaction commit cùng lúc được ghi vào binlog bằng một thao tác. Commit cùng lúc nghĩa là chúng không giữ khoá của nhau, nên chạy song song trên slave là an toàn.
• Master ghi thông tin nhóm commit vào binlog; slave đọc thông tin đó để chạy song song.

Vấn đề: intermediate master làm rơi mất song song

• Transaction cùng commit một lúc có thể bắt đầu ở các thời điểm khác nhau. Trên slave, chúng bắt đầu cùng lúc nhưng kết thúc lệch nhau, nên một nhóm 4 transaction của master có thể thành 2 nhóm 2 transaction.
• Với slave lá thì không sao. Nhưng nếu slave đó là intermediate master, nó ghi lại binlog với nhóm nhỏ hơn, và slave của nó chỉ chạy song song 2 thay vì 4, có rào chắn giữa các nhóm.
• Đo trên 4 môi trường thử nghiệm với workload production (MariaDB 10.0.16; MySQL 5.7 cho kết quả gần giống), theo dõi BINLOG_COMMITS và BINLOG_GROUP_COMMITS ở cả master lẫn slave: kích thước nhóm trung bình trên slave nhỏ hơn hẳn. Theo Booking, intermediate master chia độ song song cho slave phía sau ít nhất 2 lần, có khi gần 4 lần.

Lời giải theo Booking

• Cho mọi slave replicate thẳng từ master thì tăng tải master, và không thực tế giữa các site: mỗi site thường có 50, có khi hơn 100 slave, sẽ tốn băng thông WAN.
• Thay intermediate master bằng Binlog Server: nó gửi cho slave đúng binlog lấy từ master, nên mọi slave dù nối trực tiếp hay qua Binlog Server đều thấy cùng thông tin song song. Theo Booking, muốn tận dụng parallel replication thì intermediate master phải biến mất.

Vì sao

• Thông tin song song là dữ liệu suy ra lúc commit, không phải thuộc tính của transaction; mỗi tầng tính lại thì mỗi tầng làm mất thêm một phần.
• Booking đã có Binlog Server cho lý do khác (giảm tải, chuyển tiếp giữa site), nên lời giải là dùng lại một thành phần sẵn có.

Bài học cho SWE

• Trần ghi của cụm MySQL nhiều tầng nằm ở luồng apply của slave, và mỗi tầng relay có thể làm trần đó thấp thêm (Failover, replica và dự phòng dữ liệu).
• Một tầng chuyển tiếp nên chuyển nguyên văn thay vì xử lý lại rồi phát ra; xử lý lại làm rơi metadata tầng sau cần.
• Đo trên workload thật bằng chính counter của engine (số commit / số group commit) trước khi tin con số benchmark.

Liên quan

• Booking.com 2015 · Booking.com 2015 · Booking.com 2016
• Failover, replica và dự phòng dữ liệu