Trong thiết lập sao chép lưu trữ MySQL, tham số Seconds_Behind_Master (SBM), như được hiển thị bởi lệnh SHOW SLAVE STATUS, thường được sử dụng như một dấu hiệu về độ trễ sao chép hiện tại của nô lệ . Trong bài đăng trên blog này, chúng tôi xem xét cách hiểu và diễn giải giá trị này trong các tình huống khác nhau.
Giá trị có thể có của giây sau bậc thầy
Giá trị của SBM, như được giải thích trong tài liệu MySQL, phụ thuộc vào trạng thái của MySQL slave nói chung và các trạng thái của MySQL slave SQL_THREAD và IO_THREAD nói riêng. Trong khi IO_THREAD kết nối với cái chính và đọc các bản cập nhật, SQL_THREAD áp dụng các bản cập nhật này trên phần tử. Hãy kiểm tra các giá trị có thể có của SBM trong các trạng thái khác nhau của MySQL Slave.
Khi Giá trị SBM bằng rỗng
- SBM luôn ở trạng thái NULL nếu máy chủ của bạn bị dừng hoặc Chuỗi SQL của bạn bị dừng (hoặc không chạy).
- SBM cũng sẽ là NULL nếu Chuỗi IO bị dừng, miễn là Chuỗi SQL đã xử lý tất cả các sự kiện từ nhật ký chuyển tiếp. Một đầu ra mẫu của TÌNH TRẠNG SÓNG CHẬM HIỂN THỊ (được cắt bớt để chỉ hiển thị các giá trị quan tâm) thể hiện điều này:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Không
Slave_SQL_Running:Có
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Slave đã đọc tất cả nhật ký chuyển tiếp; chờ cập nhật thêm
Đã truy xuất_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Khi Giá trị SBM bằng 0 hoặc dương
- SBM sẽ phản ánh một giá trị hợp lệ (> =0) khi Chuỗi SQL đang tích cực xử lý các sự kiện. Điều này đúng bất kể trạng thái IO Thread. Ví dụ:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Không
Slave_SQL_Running:Có
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Đang đợi nhân viên nô lệ xử lý hàng đợi của họ
Đã truy xuất_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Trong ví dụ trên, chúng ta có thể thấy rằng slave đứng sau master bằng cách so sánh Retrieved_GTID_Set và Executed_GTID_Set. Trong những trường hợp như vậy, Seconds_Behind_Master sẽ đại diện cho sự khác biệt giữa dấu thời gian của giao dịch mới nhất được xử lý bởi SQL Thread và dấu thời gian của cùng một giao dịch khi nó được xử lý trên chính. Dấu thời gian giao dịch này của cái chính được lưu giữ thông qua sao chép và do đó máy chủ sẽ có thể tính toán SBM cục bộ.
Ngoài ra, sau khi nô lệ bắt kịp hoàn toàn với tất cả nhật ký chuyển tiếp, (tức là GTID được thực thi sẽ trở thành 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213 /), Seconds_Behind_Master sẽ chuyển sang '0' nếu Luồng IO đang chạy hoặc thành 'NULL' nếu Luồng IO không chạy.
Hướng dẫn #MySQL - Hiểu được những giây đằng sau giá trị chínhNhấp để Tweet
Hiểu tốc độ thực thi của MySQL Slave
Giả sử rằng Luồng SQL và Luồng IO trên máy phụ đang ở trạng thái đang chạy, có thể hiểu tốc độ thực thi tương đối của máy chủ và máy phụ bằng cách theo dõi giá trị SBM. Giá trị ‘0’ nhất quán hoặc một giá trị không đổi chỉ ra rằng máy phụ đang thực thi ở cùng tốc độ với tốc độ chính. Mặt khác, độ dốc hướng lên trong Seconds_Behind_Master cho biết rằng máy phụ hoạt động chậm hơn máy chủ.
Bảng điều khiển Giám sát của ScaleGrid dành cho MySQL trên Azure vẽ biểu đồ các giá trị của SBM theo thời gian cho các nút phụ.
Giá trị bằng không hoặc không đổi của SBM
Trong ví dụ trên, quá trình nô lệ được khởi động khoảng 40 giờ sau khi bản gốc có hoạt động ghi. Sau khi bắt đầu, nô lệ bắt đầu sao chép dữ liệu đó và chúng ta thấy SBM khá bằng phẳng cho biết nô lệ được thực thi ở cùng tốc độ với tốc độ chính. Cũng lưu ý rằng việc SBM giảm xuống '0' là dốc, điều đó thực sự có nghĩa là mặc dù giao dịch cuối cùng mà máy chủ chạy đã được thực hiện khoảng 40 giờ trước trên giao diện chính, nhưng khi chúng tôi đã bắt kịp, sẽ có độ trễ '0'.
Tăng giá trị của SBM
Trong biểu đồ bên dưới, chúng ta có thể thấy rằng SBM đang không ngừng tăng lên, có nghĩa là tốc độ thực thi của thiết bị phụ kém hơn tốc độ của tốc độ chính. Đây thực sự là một trường hợp chúng tôi đang chạy 20 luồng thực hiện ghi liên tục trên chủ và một luồng phụ không thể theo kịp nó.
Cuối cùng, điều quan trọng cần lưu ý là trong các cuộc thảo luận của chúng tôi cho đến nay, chúng tôi chưa cho rằng có bất kỳ tắc nghẽn mạng nào. Trong trường hợp mạng chậm, bản thân IO Thread phụ sẽ bị tụt hậu so với chủ và nếu SQL Thread đủ nhanh, SBM sẽ dao động trong khoảng từ ‘0’ đến một số dương. Trong những trường hợp như vậy, SBM sẽ không phải là một tham số hữu ích để hiểu độ trễ thực sự với bản chính.
Nếu bạn thích bài đăng trên blog này, hãy xem các hướng dẫn quản lý cơ sở dữ liệu MySQL phổ biến khác của chúng tôi để tìm hiểu thêm về cách tối ưu hóa các triển khai của bạn:
- Tính kích thước vùng đệm InnoDB cho Máy chủ MySQL của bạn
- Hướng dẫn sử dụng MySQL - Định cấu hình và quản lý SSL trên máy chủ MySQL của bạn
- Giải thích về khung tính khả dụng cao của MySQL - Phần I:Giới thiệu
