Trong blog trước của chúng tôi về bảng điều khiển SCUMM, chúng tôi đã xem xét bảng điều khiển tổng quan về MySQL. Phiên bản mới của ClusterControl (phiên bản 1.7) cung cấp một số biểu đồ có độ phân giải cao về các số liệu hữu ích và chúng tôi đã tìm hiểu ý nghĩa của từng số liệu và cách chúng giúp bạn khắc phục sự cố cơ sở dữ liệu của mình. Trong blog này, chúng ta sẽ xem xét bảng điều khiển MySQL Replication. Hãy tiếp tục với các chi tiết của trang tổng quan này về những gì phải cung cấp.
Trang tổng quan sao chép MySQL
MySQL Replication Dashboard cung cấp một bộ đồ thị rất đơn giản giúp bạn dễ dàng theo dõi (các) bản sao và bản sao MySQL của mình. Bắt đầu từ trên cùng, nó hiển thị các biến và thông tin quan trọng nhất để xác định tình trạng của (các) bản sao hoặc thậm chí là bản chính. Bảng điều khiển này cung cấp một phần rất hữu ích khi kiểm tra sức khỏe của nô lệ hoặc một bậc thầy trong thiết lập tổng thể. Người ta cũng có thể kiểm tra trên trang tổng quan này quá trình tạo nhật ký nhị phân của cái chính và xác định thứ nguyên tổng thể, về kích thước được tạo, tại một khoảng thời gian cụ thể.
Điều đầu tiên trong bảng điều khiển này, nó cung cấp cho bạn thông tin quan trọng nhất mà bạn có thể cần về tình trạng của bản sao của bạn. Xem biểu đồ bên dưới:
Về cơ bản, nó sẽ hiển thị cho bạn IO_Thread, SQL_Thread của luồng Slave, lỗi sao chép và nếu biến read_only đã được bật. Từ ảnh chụp màn hình mẫu ở trên, tất cả thông tin cho thấy nô lệ 192.168.70.20 của tôi khỏe mạnh và chạy bình thường.
Ngoài ra, ClusterControl cũng có thông tin để thu thập nếu bạn chuyển đến Cluster -> Tổng quan. Cuộn xuống và bạn có thể thấy biểu đồ bên dưới:
Một nơi khác để xem thiết lập sao chép là chế độ xem cấu trúc liên kết của thiết lập sao chép, có thể truy cập tại Cluster -> Topology. Trong nháy mắt, nó cung cấp một cái nhìn về các nút khác nhau trong thiết lập, vai trò của chúng, độ trễ sao chép, GTID được truy xuất và hơn thế nữa. Xem biểu đồ bên dưới:
Ngoài ra, Chế độ xem cấu trúc liên kết cũng hiển thị tất cả các nút khác nhau tạo thành một phần của cụm cơ sở dữ liệu của bạn cho dù là nút cơ sở dữ liệu, bộ cân bằng tải (ProxySQL / MaxScale / HaProxy) hay trọng tài (garbd), cũng như các kết nối giữa chúng. Các nút, kết nối và trạng thái của chúng được phát hiện bởi ClusterControl. Vì ClusterControl liên tục theo dõi các nút và giữ thông tin trạng thái, nên bất kỳ thay đổi nào trong cấu trúc liên kết đều được phản ánh trong giao diện web. Trong trường hợp lỗi của các nút được báo cáo, bạn có thể sử dụng chế độ xem này cùng với Bảng điều khiển SCUMM và xem tác động nào có thể gây ra lỗi đó.
Chế độ xem Topology có một số điểm tương đồng với Orchestrator trong đó bạn có thể quản lý các nút, thay đổi các nút chính bằng cách kéo và thả đối tượng trên nút chính mong muốn, khởi động lại các nút và đồng bộ hóa dữ liệu. Để biết thêm về Chế độ xem cấu trúc liên kết của chúng tôi, chúng tôi khuyên bạn nên đọc blog trước của chúng tôi - “Hình dung cấu trúc liên kết cụm của bạn trong ClusterControl”.
Bây giờ chúng ta hãy tiếp tục với các biểu đồ.
-
MySQL Replication Delay
Biểu đồ này rất quen thuộc với bất kỳ ai đang quản lý MySQL, đặc biệt là những người đang làm việc hàng ngày trên cơ sở thiết lập master-slave của họ. Biểu đồ này có các xu hướng cho tất cả các độ trễ được ghi lại trong một phạm vi thời gian cụ thể được chỉ định trong trang tổng quan này. Bất cứ khi nào chúng ta muốn kiểm tra thời gian rơi định kỳ mà bản sao của chúng ta có, thì biểu đồ này rất tốt để xem xét. Có những trường hợp nhất định bản sao có thể bị trễ vì những lý do kỳ lạ như RAID của bạn có BBU đã xuống cấp và cần thay thế, bảng không có khóa duy nhất nhưng không có trên bản chính, quét toàn bộ bảng không mong muốn hoặc quét chỉ mục đầy đủ hoặc một truy vấn không hợp lệ đã được điều hành bởi một nhà phát triển. Đây cũng là một chỉ báo tốt để xác định xem độ trễ của nô lệ có phải là vấn đề chính hay không, khi đó bạn có thể muốn tận dụng lợi thế của việc nhân rộng song song. -
Kích thước Binlog
Các đồ thị này có liên quan với nhau. Biểu đồ Kích thước Binlog cho bạn biết cách nút của bạn tạo nhật ký nhị phân và giúp xác định kích thước của nó dựa trên khoảng thời gian bạn đang quét. -
Dữ liệu Binlog được ghi theo giờ
Dữ liệu Binlog được ghi theo giờ là biểu đồ dựa trên ngày hiện tại và ngày trước đó được ghi lại. Điều này có thể hữu ích bất cứ khi nào bạn muốn xác định xem nút của bạn đang chấp nhận ghi lớn như thế nào, mà sau này bạn có thể sử dụng để lập kế hoạch dung lượng.
-
Số lượng binlog
Giả sử bạn mong đợi lưu lượng truy cập cao trong một tuần nhất định. Bạn muốn so sánh mức độ lớn các bài viết đang diễn ra qua chủ và nô lệ của bạn với tuần trước. Biểu đồ này rất hữu ích cho loại tình huống này - Để xác định mức độ cao của các bản ghi nhị phân được tạo trên bản thân chính hoặc thậm chí trên các nô lệ nếu biến log_slave_updates được bật. Bạn cũng có thể sử dụng chỉ báo này để xác định dữ liệu nhật ký nhị phân chính và nô lệ của bạn được tạo, đặc biệt nếu bạn đang lọc một số bảng hoặc lược đồ (replicate_ignore_db, replicate_ignore_table, replicate_wild_do_table) trên các nô lệ của bạn đã được tạo trong khi log_slave_updates được bật. -
Binlog được tạo hàng giờ
Biểu đồ này là tổng quan nhanh để so sánh việc tạo binlog của bạn hàng giờ từ ngày hôm qua và ngày hôm nay. -
Không gian nhật ký chuyển tiếp
Biểu đồ này đóng vai trò là cơ sở của nhật ký chuyển tiếp được tạo từ bản sao của bạn. Khi được sử dụng cùng với đồ thị MySQL Replication Delay, nó giúp xác định số lượng bản ghi chuyển tiếp được tạo ra là bao nhiêu, mà quản trị viên phải xem xét về tính khả dụng của ổ đĩa của bản sao hiện tại. Nó có thể gây ra sự cố khi nô lệ của bạn bị tụt hậu nghiêm trọng và đang tạo ra một số lượng lớn nhật ký chuyển tiếp. Điều này có thể tiêu tốn dung lượng ổ đĩa của bạn một cách nhanh chóng. Có những tình huống nhất định mà do số lượng ghi lớn từ bản chính, bản sao / bản sao sẽ bị trễ rất nhiều, do đó việc tạo ra một lượng lớn nhật ký có thể gây ra một số vấn đề nghiêm trọng trên bản sao đó. Điều này có thể giúp ích cho nhóm hoạt động khi trao đổi với quản lý của họ về việc lập kế hoạch năng lực. -
Nhật ký chuyển tiếp được viết theo giờ
Tương tự như Không gian ghi nhật ký tiếp sức nhưng thêm tổng quan nhanh để so sánh nhật ký chuyển tiếp của bạn được viết từ ngày hôm qua và ngày hôm nay.
Kết luận
Bạn đã học được rằng việc sử dụng SCUMM để theo dõi Bản sao MySQL của bạn sẽ tăng thêm năng suất và hiệu quả cho nhóm vận hành. Sử dụng các tính năng mà chúng tôi có từ các phiên bản trước kết hợp với các biểu đồ được cung cấp với SCUMM giống như bạn đi đến phòng tập thể dục và thấy những cải tiến lớn về năng suất của bạn. Đây là những gì SCUMM có thể cung cấp:giám sát trên steroid! (hiện tại, chúng tôi không ủng hộ việc bạn nên dùng steroid khi đến phòng tập thể dục!)
Trong Phần 3 của blog này, tôi sẽ thảo luận về Số liệu InnoDB và Bảng điều khiển giản đồ hiệu suất MySQL.
