Khi bạn cần làm việc với một cơ sở dữ liệu mà bạn không quen thuộc 100%, bạn có thể bị choáng ngợp bởi hàng trăm số liệu có sẵn. Những cái nào là quan trọng nhất? Tôi nên giám sát những gì, và tại sao? Những mẫu số liệu nào sẽ rung lên một hồi chuông cảnh báo? Trong bài đăng trên blog này, chúng tôi sẽ cố gắng giới thiệu cho bạn một số chỉ số quan trọng nhất cần theo dõi khi chạy MySQL hoặc MariaDB trong sản xuất.
Bộ đếm trạng thái Com_ *
Chúng ta sẽ bắt đầu với bộ đếm Com_ * - bộ đếm xác định số lượng và kiểu truy vấn mà MySQL thực thi. Chúng ta đang nói ở đây về các loại truy vấn như CHỌN, CHÈN, CẬP NHẬT và nhiều loại khác. Điều khá quan trọng là phải theo dõi những điều đó vì đột ngột tăng đột biến hoặc giảm đột ngột có thể cho thấy có sự cố trong hệ thống.
Hệ thống quản lý cơ sở dữ liệu toàn diện của chúng tôi ClusterControl hiển thị cho bạn dữ liệu này liên quan đến các loại truy vấn phổ biến nhất trong phần “Tổng quan”.
Handler_ * Bộ đếm trạng thái
Một danh mục số liệu bạn nên để ý là bộ đếm Handler_ * trong MySQL. Bộ đếm Com_ * cho bạn biết loại truy vấn mà phiên bản MySQL của bạn đang thực thi nhưng một SELECT có thể hoàn toàn khác với một SELECT khác - SELECT có thể là tra cứu khóa chính, cũng có thể là quét bảng nếu không thể sử dụng chỉ mục. Trình xử lý cho bạn biết cách MySQL truy cập dữ liệu được lưu trữ - điều này rất hữu ích để điều tra các vấn đề về hiệu suất và đánh giá xem liệu có thể đạt được lợi ích trong việc xem xét truy vấn và lập chỉ mục bổ sung hay không.
Như bạn có thể thấy từ biểu đồ ở trên, có nhiều số liệu cần theo dõi (và biểu đồ ClusterControl là những biểu đồ quan trọng nhất) - chúng tôi sẽ không trình bày tất cả chúng ở đây (bạn có thể tìm thấy mô tả trong tài liệu MySQL) nhưng chúng tôi muốn làm nổi bật những cái quan trọng nhất.
Handler_read_rnd_next - bất cứ khi nào MySQL truy cập một hàng mà không cần tra cứu chỉ mục, theo thứ tự tuần tự, bộ đếm này sẽ được tăng lên. Nếu trong khối lượng công việc của bạn, handler_read_rnd_next chịu trách nhiệm cho một tỷ lệ phần trăm cao của toàn bộ lưu lượng truy cập, điều đó có nghĩa là các bảng của bạn, rất có thể, có thể sử dụng một số chỉ mục bổ sung vì MySQL thực hiện rất nhiều lần quét bảng.
Handler_read_next và handler_read_prev - hai bộ đếm đó được cập nhật bất cứ khi nào MySQL thực hiện quét chỉ mục - tiến hoặc lùi. Handler_read_first và handler_read_last có thể làm sáng tỏ hơn về loại quét chỉ mục đó là gì - nếu chúng ta đang nói về quét chỉ mục đầy đủ (tiến hoặc lùi), hai bộ đếm đó sẽ được cập nhật.
Handler_read_key - ngược lại, bộ đếm này, nếu giá trị của nó cao, cho bạn biết rằng các bảng của bạn đã được lập chỉ mục tốt vì nhiều hàng đã được truy cập thông qua tra cứu chỉ mục.
Trễ sao chép
Nếu bạn đang làm việc với nhân bản MySQL, thì độ trễ sao chép là một số liệu mà bạn chắc chắn muốn theo dõi. Lỗi sao chép là không thể tránh khỏi và bạn sẽ phải đối phó với nó, nhưng để đối phó với nó, bạn cần hiểu tại sao nó lại xảy ra. Để làm được điều đó, bước đầu tiên sẽ là biết _ khi nào_ nó xuất hiện.
Bất cứ khi nào bạn thấy độ trễ sao chép tăng đột biến, bạn muốn kiểm tra các biểu đồ khác để có thêm manh mối - tại sao điều đó lại xảy ra? Điều gì có thể đã gây ra nó? Các lý do có thể khác nhau - DML dài, nặng, số lượng DML được thực thi trong một khoảng thời gian ngắn tăng lên đáng kể, CPU hoặc I / O giới hạn.
I / O InnoDB
Có một số chỉ số quan trọng cần theo dõi liên quan đến I / O.
Trong biểu đồ trên, bạn có thể thấy một số chỉ số cho bạn biết loại I / O InnoDB thực hiện - dữ liệu ghi và đọc, làm lại ghi nhật ký, fsync. Các số liệu đó sẽ giúp bạn quyết định, ví dụ:nếu độ trễ sao chép là do I / O tăng đột biến hoặc có thể do một số lý do khác. Điều quan trọng là phải theo dõi các số liệu đó và so sánh chúng với các giới hạn phần cứng của bạn - nếu bạn đang tiến gần đến giới hạn phần cứng của đĩa, có lẽ đã đến lúc xem xét vấn đề này trước khi nó ảnh hưởng nghiêm trọng hơn đến hiệu suất cơ sở dữ liệu của bạn.
Somenines DevOps Guide to Management DatabaseTìm hiểu về những điều bạn cần biết để tự động hóa và quản lý cơ sở dữ liệu nguồn mở của bạnTải xuống miễn phíChỉ số Galera - Kiểm soát luồng và hàng đợi
Nếu bạn tình cờ sử dụng Galera Cluster (bất kể bạn sử dụng hương vị nào), có một số chỉ số khác mà bạn muốn theo dõi chặt chẽ, các chỉ số này có phần ràng buộc với nhau. Trước hết là các chỉ số liên quan đến kiểm soát luồng.
Kiểm soát luồng, trong Galera, là một phương tiện để giữ cho cụm đồng bộ. Bất cứ khi nào một nút dừng lại và không thể theo kịp phần còn lại của cụm, nó sẽ bắt đầu gửi thông báo điều khiển luồng yêu cầu các nút cụm còn lại chạy chậm lại. Điều này cho phép nó bắt kịp. Điều này làm giảm hiệu suất của cụm, vì vậy điều quan trọng là có thể biết nút nào và khi nào nó bắt đầu gửi thông báo điều khiển luồng. Điều này có thể giải thích một số sự chậm chạp mà người dùng gặp phải hoặc giới hạn khoảng thời gian và máy chủ lưu trữ để sử dụng để điều tra thêm.
Bộ chỉ số thứ hai cần theo dõi là những chỉ số liên quan đến hàng đợi gửi và nhận trong Galera.
Các nút Galera có thể lưu các tập ghi (giao dịch) vào bộ nhớ cache nếu chúng không thể áp dụng tất cả chúng ngay lập tức. Nếu cần, chúng cũng có thể lưu các tập ghi vào bộ nhớ cache sắp được gửi đến các nút khác (nếu một nút nhất định nhận được các ghi từ ứng dụng). Cả hai trường hợp đều là các triệu chứng của sự chậm lại, rất có thể, sẽ dẫn đến việc gửi các thông báo điều khiển luồng và cần một số điều tra - tại sao điều đó lại xảy ra, ở nút nào, vào thời điểm nào?
Tất nhiên, đây chỉ là phần nổi của tảng băng trôi khi chúng tôi xem xét tất cả các chỉ số mà MySQL cung cấp - tuy nhiên, bạn không thể sai nếu bắt đầu xem những chỉ số mà chúng tôi đã đề cập ở đây, ngoài các số liệu hệ điều hành / phần cứng thông thường như CPU , bộ nhớ, việc sử dụng đĩa và trạng thái của các dịch vụ.
