Booking.com

Mạch tiến hoá

Booking.com scale đọc bằng hàng nghìn slave MySQL (2014). Crash-safe replication của MySQL 5.6 tải lại binlog từ master sau mỗi lần khởi động, đè lên card mạng của master; họ đặt Binlog Server cục bộ trên slave để phục hồi không chạm master Booking.com 2014. Năm 2017, khi bộ phận đã gần 2.000 người, Booking.com viết lại quy trình xử lý sự cố quanh nguyên tắc "escalations are cheap" Booking.com 2017. Năm 2019, với 50.000+ server, Booking.com mô tả cách chia việc vận hành giữa team reliability và team sản phẩm theo ba mức hỗ trợ, do lãnh đạo sản phẩm chọn theo độ quan trọng; developer luôn ở trong lịch trực Booking.com 2019. Năm 2015–2016, Booking đo parallel replication của MySQL/MariaDB trên chính workload production để xem có nâng được trần ghi của master hay không: kiểu bảo thủ chỉ 1,3–2,1 lần Booking.com 2015, kiểu lạc quan tới 3,78 lần nhưng vẫn xa mức mong muốn Booking.com 2016. Hai phần đầu của series (3/2015) giải thích cơ chế: độ song song lấy từ group commit của master bị intermediate master làm rơi mất, nên phải thay bằng Binlog Server Booking.com 2015; và group commit trên slave chia chi phí fsync cho intermediate master ở DC xa nằm trên đĩa dùng chung Booking.com 2015. Năm 2017, một lần truy vết lỗi trên load balancer cho thấy chính health check (gọi curl) làm phình cache của kernel tới mức khoá mọi CPU vài giây Booking.com 2017.

Timeline

Năm = năm sự kiện theo bài (có thể sớm hơn năm đăng bài).