Chúng tôi đã thêm một số bảng điều khiển mới cho MySQL trong bản phát hành mới nhất của ClusterControl 1.7.0. - và trong blog trước của chúng tôi, chúng tôi đã chỉ cho bạn Cách giám sát ProxySQL của bạn bằng Prometheus và ClusterControl.
Trong blog này, chúng ta sẽ xem xét bảng điều khiển Tổng quan về MySQL.
Vì vậy, chúng tôi đã bật Giám sát dựa trên tác nhân trong tab Trang tổng quan để bắt đầu thu thập số liệu cho các nút. Lưu ý rằng khi bật Giám sát dựa trên tác nhân, bạn có các tùy chọn để đặt “ Khoảng thời gian cạo (giây) ”Và“ Lưu giữ dữ liệu (ngày) ”. Scraping Interval là nơi bạn muốn đặt mức độ mạnh mẽ của Prometheus sẽ thu thập dữ liệu từ mục tiêu và Dữ liệu lưu giữ là khoảng thời gian bạn muốn giữ dữ liệu của mình được Prometheus thu thập trước khi bị xóa.
Khi được bật, bạn có thể xác định cụm nào có tác nhân và cụm nào có giám sát không tác nhân.
So với cách tiếp cận không có tác nhân, mức độ chi tiết của dữ liệu trong biểu đồ sẽ cao hơn với các tác nhân.
Đồ thị MySQL
Phiên bản mới nhất của ClusterControl 1.7.0 (mà bạn có thể tải xuống miễn phí - ClusterControl Community) có các Trang tổng quan MySQL sau đây để bạn có thể thu thập thông tin cho các máy chủ MySQL của mình. Đây là Tổng quan về MySQL, Số liệu MySQL InnoDB, Lược đồ Hiệu suất MySQL và Bản sao MySQL.
Chúng tôi sẽ trình bày chi tiết về các biểu đồ có sẵn trong bảng điều khiển Tổng quan về MySQL.
Bảng điều khiển tổng quan về MySQL
Trang tổng quan này chứa các biến hoặc thông tin quan trọng thông thường liên quan đến tình trạng của nút MySQL của bạn. Các biểu đồ có trên trang tổng quan này là cụ thể cho nút được chọn khi xem các trang tổng quan như bên dưới:
Nó bao gồm 26 đồ thị, nhưng bạn có thể không cần tất cả những thứ này khi chẩn đoán sự cố. Tuy nhiên, các biểu đồ này cung cấp một đại diện quan trọng của các chỉ số tổng thể cho các máy chủ MySQL của bạn. Hãy xem qua những điều cơ bản, vì đây có thể là những điều phổ biến nhất mà một DBA sẽ thường xuyên xem xét.
Bốn biểu đồ đầu tiên được hiển thị ở trên cùng với thời gian hoạt động, truy vấn mỗi giây và thông tin vùng đệm của MySQL là những gợi ý cơ bản nhất mà chúng ta có thể cần. Từ các biểu đồ được hiển thị ở trên, đây là các đại diện của chúng:
- Kết nối MySQL
Đây là nơi bạn muốn kiểm tra tổng số kết nối khách hàng của mình được phân bổ cho đến nay trong một khoảng thời gian cụ thể. - Hoạt động chuỗi ứng dụng khách MySQL
Đôi khi máy chủ MySQL của bạn có thể rất bận. Ví dụ:nó có thể nhận được sự gia tăng lưu lượng truy cập vào một thời điểm cụ thể và bạn muốn theo dõi hoạt động chuỗi đang chạy của mình. Biểu đồ này thực sự quan trọng để xem xét. Đôi khi, hiệu suất truy vấn của bạn có thể giảm sút nếu chẳng hạn như một bản cập nhật lớn khiến các luồng khác phải đợi để có được khóa. Điều này sẽ dẫn đến số lượng chủ đề đang chạy của bạn tăng lên. Tỷ lệ bỏ lỡ bộ nhớ cache được tính dưới dạng Threads_create / Connections. - Câu hỏi MySQL Đây là các truy vấn chạy trong một khoảng thời gian cụ thể. Một chuỗi có thể là một giao dịch bao gồm nhiều truy vấn và đây có thể là một biểu đồ tốt để xem xét.
- Bộ nhớ cache chuỗi MySQL
Biểu đồ này hiển thị giá trị thread_cache_size, các luồng được lưu trong bộ nhớ cache (các luồng được sử dụng lại) và các luồng được tạo (các luồng mới). Bạn có thể kiểm tra trên biểu đồ này để biết các trường hợp như bạn cần điều chỉnh các truy vấn đã đọc của mình khi nhận thấy số lượng kết nối đến cao và các chuỗi của bạn được tạo tăng nhanh chóng. Ví dụ:nếu Threads_running / thread_cache_size> 2 thì việc tăng thread_cache_size có thể tăng hiệu suất cho máy chủ của bạn. Hãy lưu ý rằng việc tạo và phá hủy các luồng rất tốn kém. Tuy nhiên, trong các phiên bản gần đây của MySQL (> =5.6.8), theo mặc định, biến này có chế độ tự động thay đổi kích thước mà bạn có thể coi là không bị ảnh hưởng.
Bốn đồ thị tiếp theo là Đối tượng tạm thời của MySQL, Kiểu chọn MySQL, Kiểu MySQL và Truy vấn chậm MySQL. Các biểu đồ này có liên quan với nhau, đặc biệt nếu bạn đang chẩn đoán các truy vấn đang chạy dài và các truy vấn lớn cần tối ưu hóa.
- Đối tượng Tạm thời của MySQL
Biểu đồ này sẽ là một nguồn tốt để dựa vào nếu bạn muốn theo dõi các truy vấn đang chạy dài sẽ kết thúc bằng cách sử dụng đĩa thay vì các bảng hoặc tệp tạm thời đi trong bộ nhớ. Đó là một nơi tốt để bắt đầu tìm kiếm sự xuất hiện định kỳ của các truy vấn có thể tăng thêm để tạo ra các vấn đề về dung lượng ổ đĩa, đặc biệt là trong những thời điểm lẻ. - Loại Chọn MySQL Một nguồn của hiệu suất kém là các truy vấn đang sử dụng các phép nối đầy đủ, quét bảng, chọn dải ô không sử dụng bất kỳ chỉ mục nào. Biểu đồ này sẽ hiển thị cách truy vấn của bạn hoạt động và những gì trong danh sách từ kết hợp đầy đủ, đến kết hợp toàn dải, chọn phạm vi, quét bảng có xu hướng cao nhất.
- Các loại MySQL
Chẩn đoán những truy vấn đang sử dụng tính năng sắp xếp và những truy vấn cần nhiều thời gian để hoàn thành. - Truy vấn chậm MySQL Xu hướng truy vấn chậm của bạn được thu thập tại đây trên biểu đồ này. Điều này rất hữu ích, đặc biệt là trong việc chẩn đoán tần suất các truy vấn của bạn bị chậm. Những điều cần được điều chỉnh là gì? Đó có thể là vùng đệm quá nhỏ, các bảng thiếu chỉ mục và phải quét toàn bộ bảng, các bản sao lưu logic chạy theo lịch trình không mong muốn, v.v. Sử dụng Trình theo dõi truy vấn của chúng tôi trong ClusterControl cùng với biểu đồ này rất có lợi vì nó giúp xác định các truy vấn chậm.
Các biểu đồ tiếp theo mà chúng tôi đề cập đến là nhiều hơn về hoạt động mạng, khóa bảng và bộ nhớ trong cơ bản mà MySQL đang sử dụng trong quá trình hoạt động của MySQL.
- Kết nối bị hủy bỏ MySQL
Số lượng kết nối bị hủy bỏ sẽ hiển thị trên biểu đồ này. Điều này bao gồm các ứng dụng khách bị hủy bỏ chẳng hạn như nơi mạng bị đóng đột ngột hoặc nơi kết nối internet bị ngắt hoặc bị gián đoạn. Nó cũng ghi lại các kết nối bị hủy bỏ hoặc các nỗ lực, chẳng hạn như mật khẩu sai hoặc gói dữ liệu xấu khi thiết lập kết nối từ máy khách. - MySQL Table Locks Xu hướng
cho các bảng yêu cầu khóa bảng đã được cấp ngay lập tức và cho các bảng yêu cầu khóa chưa được cấp ngay lập tức. Ví dụ:nếu bạn có các khóa cấp bảng trên các bảng MyISAM và các yêu cầu đến của cùng một bảng, thì chúng không thể được cấp ngay lập tức. - Lưu lượng truy cập mạng MySQL
Biểu đồ này cho thấy xu hướng của hoạt động mạng gửi đến và gửi đi trong máy chủ MySQL. “Inbound” là dữ liệu nhận được bởi máy chủ MySQL trong khi “Outbound” là dữ liệu được gửi hoặc chuyển bởi máy chủ từ MySQL server. là vừa phải nhưng bạn đang thắc mắc tại sao nó có dữ liệu được truyền ra bên ngoài rất cao, chẳng hạn như dữ liệu BLOB. - Sử dụng Mạng MySQL Hàng giờ
Giống như lưu lượng mạng hiển thị dữ liệu Đã nhận và Đã gửi. Xin lưu ý rằng nó dựa trên "mỗi giờ" và được gắn nhãn "ngày cuối cùng" sẽ không theo khoảng thời gian bạn đã chọn trong bộ chọn ngày. - Tổng quan về Bộ nhớ trong MySQL
Biểu đồ này quen thuộc với một MySQL DBA dày dặn. Mỗi chú giải này trong biểu đồ thanh đều rất quan trọng, đặc biệt nếu bạn muốn theo dõi mức sử dụng bộ nhớ, mức sử dụng vùng đệm hoặc kích thước chỉ mục băm thích ứng của mình.
Các biểu đồ sau đây hiển thị các bộ đếm mà một DBA có thể dựa vào, chẳng hạn như kiểm tra thống kê, ví dụ:thống kê cho các lựa chọn, chèn, cập nhật, số trạng thái chính đã được thực thi, số BIỂU BIỂU đã được thực thi, kiểm tra nếu bạn có truy vấn không hợp lệ khi quét bảng hoặc bảng không sử dụng chỉ mục bằng cách xem qua bộ đếm read_ *, v.v.
- Bộ đếm lệnh hàng đầu (Hàng giờ)
Đây là những biểu đồ mà bạn có thể sẽ phải kiểm tra bất cứ khi nào bạn muốn xem thống kê cho các lần chèn, xóa, cập nhật, các lệnh đã thực thi như thu thập danh sách xử lý, trạng thái nô lệ, trạng thái hiển thị (thống kê tình trạng của máy chủ MySQL ), và nhiều thứ khác nữa. Đây là một nơi tốt nếu bạn muốn kiểm tra loại bộ đếm lệnh MySQL nào là hàng đầu và nếu cần một số điều chỉnh hiệu suất hoặc tối ưu hóa truy vấn. Nó cũng có thể cho phép bạn xác định những lệnh nào đang hoạt động mạnh trong khi không cần đến nó. - Trình xử lý MySQL
Thông thường, một DBA sẽ đi qua các trình xử lý này và kiểm tra xem các truy vấn đang hoạt động như thế nào trong máy chủ MySQL của bạn. Về cơ bản, biểu đồ này bao gồm các bộ đếm từ API xử lý của MySQL. Hầu hết các bộ xử lý phổ biến cho một DBA cho API lưu trữ trong MySQL là Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd và Handler_read_rnd_next. Có rất nhiều Trình xử lý MySQL để kiểm tra. Bạn có thể đọc về chúng trong tài liệu tại đây. - Trình xử lý Giao dịch MySQL
Nếu máy chủ MySQL của bạn đang sử dụng các giao dịch XA, câu lệnh SAVEPOINT, ROLLBACK TO SAVEPOINT. Sau đó, biểu đồ này là một tham chiếu tốt để xem xét. Bạn cũng có thể sử dụng biểu đồ này để theo dõi tất cả các cam kết nội bộ của máy chủ. Hãy lưu ý rằng bộ đếm cho Handler_commit tăng ngay cả đối với các câu lệnh SELECT nhưng khác với các câu lệnh chèn / cập nhật / xóa đi đến nhật ký nhị phân trong khi gọi câu lệnh COMMIT.
Biểu đồ tiếp theo sẽ hiển thị xu hướng về trạng thái quy trình và mức sử dụng hàng giờ của chúng. Có rất nhiều điểm chính ở đây trong chú giải biểu đồ thanh mà DBA sẽ kiểm tra. Gặp sự cố dung lượng ổ đĩa, sự cố kết nối và xem nhóm kết nối của bạn có hoạt động như mong đợi hay không, I / O ổ đĩa cao, sự cố mạng, v.v.
- Trạng thái xử lý / Trạng thái xử lý hàng đầu hàng giờ
Biểu đồ này là nơi bạn có thể theo dõi trạng thái luồng hàng đầu của các truy vấn đang chạy trong danh sách xử lý. Điều này rất nhiều thông tin và hữu ích cho các nhiệm vụ DBA như vậy, nơi bạn có thể kiểm tra ở đây bất kỳ trạng thái tồn đọng nào cần giải quyết. Ví dụ: mở bảng trạng thái rất cao và giá trị nhỏ nhất của nó gần như gần giá trị lớn nhất. Điều này có thể chỉ ra rằng bạn cần điều chỉnh table_open_cache. Nếu thống kê cao và bạn nhận thấy máy chủ của mình chạy chậm lại, điều này có thể cho thấy rằng máy chủ của bạn bị giới hạn đĩa và bạn có thể cần xem xét việc tăng vùng đệm của mình. Nếu bạn có số lượng tạo bảng tmp cao thì bạn có thể phải kiểm tra nhật ký chậm của mình và tối ưu hóa các truy vấn vi phạm. Bạn có thể xem hướng dẫn sử dụng để biết danh sách đầy đủ các trạng thái chuỗi MySQL tại đây.
Biểu đồ tiếp theo mà chúng tôi sẽ kiểm tra là về bộ đệm truy vấn, bộ đệm định nghĩa bảng MySQL, tần suất MySQL mở các tệp hệ thống.
- Hoạt động / Bộ nhớ Cache Truy vấn MySQL Các đồ thị này
có quan hệ với nhau. Nếu bạn có query_cache_size <> 0 và query_cache_type <> 0, thì biểu đồ này có thể hữu ích. Tuy nhiên, trong các phiên bản MySQL mới hơn, bộ đệm truy vấn đã được đánh dấu là không dùng nữa vì bộ đệm truy vấn MySQL được biết là nguyên nhân gây ra các vấn đề về hiệu suất. Bạn có thể không cần điều này trong tương lai. Phiên bản gần đây nhất của MySQL 8.0 có những cải tiến mạnh mẽ; nó có xu hướng tăng hiệu suất vì đi kèm với một số chiến lược để xử lý thông tin bộ nhớ đệm trong bộ đệm bộ nhớ. - Mở tệp MySQL
Biểu đồ này hiển thị xu hướng cho các tệp đã mở kể từ thời gian hoạt động của máy chủ MySQL nhưng nó loại trừ các tệp như ổ cắm hoặc đường ống. Nó cũng không bao gồm các tệp được mở bởi công cụ lưu trữ vì chúng có bộ đếm riêng là Innodb_num_open_files. - Tệp Mở MySQL
Biểu đồ này là nơi bạn muốn kiểm tra các tệp InnoDB hiện đang mở, các tệp đang mở MySQL hiện tại và biến open_files_limit của bạn. - Trạng thái Bộ nhớ cache Mở Bảng MySQL
Nếu bạn đặt table_open_cache rất thấp ở đây, biểu đồ này sẽ cho bạn biết về những bảng bị lỗi bộ nhớ đệm (bảng mới mở) hoặc bị thiếu do tràn. Nếu bạn gặp phải một con số cao hoặc quá nhiều trạng thái "Đang mở bảng" trong danh sách xử lý của mình, biểu đồ này sẽ đóng vai trò là tham chiếu của bạn để xác định điều này. Điều này sẽ cho bạn biết liệu có cần tăng biến table_open_cache của bạn hay không. - Bảng Mở MySQL
Liên quan đến Trạng thái bộ nhớ đệm mở bảng của MySQL, biểu đồ này hữu ích trong một số trường hợp nhất định như bạn muốn xác định xem có cần tăng table_open_cache của mình lên hay giảm xuống nếu bạn nhận thấy số bảng đang mở hoặc biến trạng thái Open_tables tăng cao. . Lưu ý rằng table_open_cache có thể chiếm một lượng lớn dung lượng bộ nhớ, vì vậy bạn phải cẩn thận thiết lập điều này, đặc biệt là trong các hệ thống sản xuất. - Bộ đệm ẩn Định nghĩa Bảng MySQL
Nếu bạn muốn kiểm tra số lượng biến trạng thái Open_table_definitions và Opened_table_definitions, thì biểu đồ này chính là thứ bạn cần. Đối với các phiên bản MySQL mới hơn (> =5.6.8), bạn có thể không cần thay đổi giá trị của biến này và sử dụng giá trị mặc định vì nó có tính năng tự động lưu trữ.
Kết luận
Việc bổ sung SCUMM trong phiên bản mới nhất của ClusterControl 1.7.0 mang lại những lợi ích mới đáng kể cho một số tác vụ DBA chính. Các biểu đồ mới có thể giúp dễ dàng xác định nguyên nhân của các vấn đề mà DBA hoặc sysadmins thường phải giải quyết và giúp tìm ra giải pháp thích hợp nhanh hơn.
Chúng tôi rất muốn biết trải nghiệm và suy nghĩ của bạn về việc sử dụng ClusterControl 1.7.0 với SCUMM (bạn có thể tải xuống miễn phí - ClusterControl Community).
Trong phần 2 của blog này, tôi sẽ thảo luận về Giám sát hiệu quả việc nhân rộng MySQL với Bảng điều khiển SCUMM.
