Trong bài Giới thiệu về MySQL Replication mình có giới thiệu một chức năng của hệ thống Replication đó là realtime backup. Nếu server master gặp sự cố như hư hỏng ổ cứng mà không thể phục hồi dữ liệu từ ổ cứng thì các bản backup offline định kì sẽ có độ trễ dữ liệu. Ví dụ nếu ta chỉ chạy offline backup dữ liệu 2 lần/ngày thì dữ liệu trong trường hợp xấu nhất sẽ bị mất trong vòng 12 tiếng. Nếu sử dụng MySQL replication thì việc mất dữ liệu sẽ vô cùng nhỏ, tối đa là khoảng vài giây.

Tuy nhiên trong việc vận hành hệ thống, luôn có những rủi ro về con người không thể lường trước được như xóa nhầm data, DROP TABLE, DROP DATABASE 🙀 -> 😨 -> 🙏

Nếu sử dụng replication thì data bị xóa sẽ replicate sang slave ngay lập tức (trong điều kiện lý tưởng độ trễ = 0). Lúc đó sử dụng replication cũng không thể cứu được những data xóa nhầm.

Từ tâm trạng của người đã vài lần từng làm những chuyện tương tự :trollface: thì mình xin khẳng định là chuyện này hoàn toàn … bình thường 🙈🙈, là con người thì cũng có lúc mệt mỏi và stress. Tất nhiên ở góc độ hệ thống và khách hàng thì những hành động này là không được phép xảy ra, và dù xảy ra thì bằng mọi giá cũng phải phục hồi lại dữ liệu cho khách hàng.

Từ MySQL 5.6 chúng ta có thể cấu hình để slave có độ trễ tối thiểu nào đó so với master. Cấu hình cực kì đơn giản nhưng lợi ích thì vô cùng lớn.

mysql> CHANGE MASTER TO MASTER_DELAY = N;

Với N là thời gian tối thiểu mà slave lag so với master, ví dụ:

mysql> CHANGE MASTER TO MASTER_DELAY = 3660;

Slave sẽ luôn trễ 1 giờ dữ liệu so với master, nếu có bất kỳ human error gì chúng ta cũng vẫn còn cơ hội để phục hồi lại data.

Ngoài ra, cấu hình độ trễ của slave so với master còn có thể ứng dụng trong việc test xem chuyện gì sẽ xảy ra khi độ lag tăng dần. Ví dụ khi ứng dụng heavy load, độ trễ tăng cao thì có phát sinh bug gì trong hệ thống hay không.

Trong hệ thống production, giả định những tình huống xấu nhất luôn là việc cần thiết để đảm bảo giảm thiểu tối đa rủi ro của hệ thống. Dù hệ thống có tốt, có những kỹ sư xuất sắc đến như thế nào cũng luôn có những tình huống thật không thể tin được như Gitlab, Travis-CI. Cẩn tắc vô áy náy, luôn cần chuẩn bị cho những tình huống như trên.