Phần lớn DBA thực hiện kiểm tra tình trạng trên cơ sở dữ liệu của họ thỉnh thoảng. Thông thường, nó sẽ xảy ra hàng ngày hoặc hàng tuần. Trước đây chúng ta đã thảo luận về lý do tại sao những kiểm tra như vậy lại quan trọng và chúng nên bao gồm những gì.
Để đảm bảo hệ thống của bạn ở trạng thái tốt, bạn cần phải xem qua khá nhiều thông tin - thống kê máy chủ lưu trữ, thống kê MySQL, thống kê khối lượng công việc, trạng thái sao lưu, gói cơ sở dữ liệu, nhật ký, v.v. Dữ liệu như vậy phải có sẵn trong mọi môi trường được giám sát thích hợp, mặc dù đôi khi nó nằm rải rác trên nhiều vị trí - bạn có thể có một công cụ để theo dõi trạng thái MySQL, một công cụ khác để thu thập thống kê hệ thống, có thể là một bộ tập lệnh, ví dụ:để kiểm tra trạng thái các bản sao lưu của bạn. Điều này làm cho việc kiểm tra sức khỏe tốn nhiều thời gian hơn bình thường - DBA phải ghép các phần khác nhau lại với nhau để hiểu trạng thái của hệ thống.
Các công cụ tích hợp như ClusterControl có một lợi thế là tất cả các bit được đặt ở cùng một nơi (hoặc trong cùng một ứng dụng). Điều đó không có nghĩa là chúng nằm cạnh nhau - chúng có thể nằm trong các phần khác nhau của giao diện người dùng và một DBA có thể phải dành một chút thời gian nhấp qua giao diện người dùng để truy cập tất cả dữ liệu thú vị.
Toàn bộ ý tưởng đằng sau việc tạo Báo cáo hoạt động là đưa tất cả dữ liệu quan trọng nhất vào một tài liệu duy nhất, tài liệu này có thể được nhanh chóng xem xét để hiểu được trạng thái của cơ sở dữ liệu.
Báo cáo hoạt động có sẵn từ menu Side Menu -> Báo cáo hoạt động:
Khi bạn đến đó, bạn sẽ thấy một danh sách các báo cáo được tạo theo cách thủ công hoặc tự động, dựa trên lịch biểu được xác định trước:
Nếu bạn muốn tạo báo cáo mới theo cách thủ công, bạn sẽ sử dụng tùy chọn 'Tạo'. Chọn loại báo cáo, tên cụm (đối với báo cáo theo cụm), người nhận email (tùy chọn - nếu bạn muốn báo cáo được gửi cho bạn) và bạn đã hoàn thành khá nhiều việc:
Các báo cáo cũng có thể được lập lịch để tạo một cách thường xuyên:
Tại thời điểm này, có 5 loại báo cáo:
- Báo cáo tính khả dụng - Tất cả các cụm.
- Báo cáo dự phòng - Tất cả các cụm.
- Báo cáo thay đổi lược đồ - Chỉ cụm dựa trên MySQL / MariaDB.
- Báo cáo hệ thống hàng ngày - Mỗi cụm.
- Báo cáo nâng cấp gói - Mỗi cụm.
Báo cáo tính khả dụng
Báo cáo tính khả dụng tập trung vào, tốt, tính khả dụng. Nó bao gồm ba phần. Đầu tiên, tóm tắt về tình trạng còn hàng:
Bạn có thể xem thông tin về thống kê tính khả dụng của cơ sở dữ liệu của mình, loại cụm, tổng thời gian hoạt động và thời gian ngừng hoạt động, trạng thái hiện tại của cụm và khi trạng thái đó thay đổi lần cuối.
Phần khác cung cấp thêm thông tin chi tiết về tính khả dụng cho mọi cụm. Ảnh chụp màn hình bên dưới chỉ hiển thị một trong các cụm cơ sở dữ liệu:
Chúng ta có thể thấy khi nào một nút chuyển trạng thái và quá trình chuyển đổi đó là gì. Đó là một nơi tuyệt vời để kiểm tra xem có bất kỳ sự cố nào gần đây với cụm không. Dữ liệu tương tự được hiển thị trong phần thứ ba của báo cáo này, nơi bạn có thể xem qua lịch sử của các thay đổi trong trạng thái cụm.
Báo cáo dự phòng
Loại báo cáo thứ hai là loại báo cáo bao gồm các bản sao lưu của tất cả các cụm. Nó bao gồm hai phần - tóm tắt sao lưu và chi tiết sao lưu, trong đó phần trước về cơ bản cung cấp cho bạn bản tóm tắt ngắn về thời điểm tạo bản sao lưu cuối cùng, nếu hoàn thành thành công hay không thành công, trạng thái xác minh sao lưu, tỷ lệ thành công và thời gian lưu giữ:
ClusterControl cũng cung cấp các ví dụ về chính sách sao lưu nếu nó tìm thấy bất kỳ cụm cơ sở dữ liệu được giám sát nào đang chạy mà không có bất kỳ sao lưu theo lịch trình hoặc nô lệ bị trì hoãn nào được định cấu hình. Tiếp theo là các chi tiết sao lưu:
Bạn cũng có thể kiểm tra danh sách các bản sao lưu được thực thi trên cụm với trạng thái, loại và kích thước của chúng trong khoảng thời gian được chỉ định. Điều này gần như bạn có thể chắc chắn rằng các bản sao lưu hoạt động chính xác mà không cần chạy kiểm tra khôi phục đầy đủ. Chúng tôi chắc chắn khuyến nghị rằng các thử nghiệm như vậy được thực hiện thường xuyên. Tin tốt là ClusterControl hỗ trợ khôi phục và xác minh dựa trên MySQL trên một máy chủ độc lập trong Sao lưu -> Khôi phục Sao lưu.
Báo cáo hệ thống hàng ngày
Loại báo cáo này chứa thông tin chi tiết về một cụm cụ thể. Nó bắt đầu với một bản tóm tắt các cảnh báo khác nhau có liên quan đến cụm:
Phần tiếp theo là về trạng thái của các nút là một phần của cụm:
Bạn có danh sách các nút trong cụm, loại, vai trò của chúng (chính hoặc phụ), trạng thái của nút, thời gian hoạt động và hệ điều hành.
Một phần khác của báo cáo là phần tóm tắt dự phòng, giống như chúng ta đã thảo luận ở trên. Tiếp theo là một bản tóm tắt các truy vấn hàng đầu trong cụm:
Cuối cùng, chúng tôi thấy "Tổng quan về trạng thái nút", trong đó bạn sẽ được trình bày các biểu đồ liên quan đến các chỉ số OS và MySQL cho mỗi nút.
Như bạn có thể thấy, chúng tôi có các biểu đồ ở đây bao gồm tất cả các khía cạnh của tải trên máy chủ lưu trữ - CPU, bộ nhớ, mạng, đĩa, tải CPU và đĩa trống. Điều này đủ để biết liệu có điều gì kỳ lạ xảy ra gần đây hay không. Bạn cũng có thể xem một số chi tiết về khối lượng công việc của MySQL - bao nhiêu truy vấn đã được thực thi, loại truy vấn nào, dữ liệu được truy cập như thế nào (thông qua trình xử lý nào)? Mặt khác, điều này sẽ đủ để chọn ra hầu hết các vấn đề về phía MySQL. Những gì bạn muốn xem là tất cả những điểm đột biến mà bạn chưa từng thấy trong quá khứ. Có thể một truy vấn mới đã được thêm vào hỗn hợp và kết quả là handler_read_rnd_next tăng vọt? Có thể có sự gia tăng tải của CPU và số lượng kết nối cao có thể dẫn đến việc tăng tải trên MySQL, nhưng cũng có thể dẫn đến một số loại tranh cãi. Một mô hình bất ngờ có thể tốt để điều tra, vì vậy bạn biết điều gì đang xảy ra.
Báo cáo nâng cấp gói
Báo cáo này cung cấp tóm tắt về các gói có sẵn để nâng cấp bởi người quản lý kho lưu trữ trên các máy chủ được giám sát. Để có báo cáo chính xác, hãy đảm bảo bạn luôn sử dụng kho lưu trữ ổn định và đáng tin cậy trên mọi máy chủ. Trong một số trường hợp không mong muốn, các máy chủ được giám sát có thể được định cấu hình với một kho lưu trữ lỗi thời sau khi nâng cấp (ví dụ:mỗi phiên bản MariaDB chính sử dụng hệ thống lưu trữ khác nhau), kho lưu trữ nội bộ không hoàn chỉnh (ví dụ:được sao chép một phần từ ngược dòng) hoặc kho lưu trữ cạnh chảy máu (thường là không ổn định gói xây dựng hàng đêm).
Phần đầu tiên là tóm tắt nâng cấp:
Nó tóm tắt tổng số gói có sẵn để nâng cấp cũng như dịch vụ được quản lý liên quan cho cụm như bộ cân bằng tải, địa chỉ IP ảo và trình phân xử. Tiếp theo, ClusterControl cung cấp danh sách gói chi tiết, được nhóm theo loại gói cho mọi máy chủ:
Báo cáo này cung cấp phiên bản có sẵn và rất có thể giúp chúng tôi lập kế hoạch thời gian bảo trì của mình một cách hiệu quả. Đối với các nâng cấp quan trọng như gói cơ sở dữ liệu và bảo mật, chúng tôi có thể ưu tiên nó hơn các nâng cấp không quan trọng, có thể được hợp nhất với các cửa sổ bảo trì ít ưu tiên khác.
Báo cáo thay đổi giản đồ
Báo cáo này so sánh các thay đổi cơ sở dữ liệu MySQL / MariaDB đã chọn trong cấu trúc bảng đã xảy ra giữa hai báo cáo được tạo khác nhau. Trong các phiên bản cũ hơn của MySQL / MariaDB, hoạt động DDL là hoạt động phi nguyên tử (trước 8.0) và yêu cầu bản sao bảng đầy đủ (trước 5.6 cho hầu hết các hoạt động) - chặn các giao dịch khác cho đến khi hoàn tất. Thay đổi lược đồ có thể trở thành một vấn đề lớn khi các bảng của bạn nhận được một lượng dữ liệu đáng kể và phải được lập kế hoạch cẩn thận, đặc biệt là trong một thiết lập theo nhóm. Trong môi trường phát triển nhiều tầng, chúng tôi đã thấy nhiều trường hợp các nhà phát triển âm thầm sửa đổi cấu trúc bảng, dẫn đến tác động đáng kể đến hiệu suất truy vấn.
Để ClusterControl tạo ra một báo cáo chính xác, các tùy chọn đặc biệt phải được định cấu hình bên trong tệp cấu hình CMON cho cụm tương ứng:
- schema_change_detection_address - Việc kiểm tra sẽ được thực hiện bằng cách sử dụng SHOW TABLES / SHOW CREATE TABLE để xác định xem lược đồ có thay đổi hay không. Việc kiểm tra được thực hiện trên địa chỉ được chỉ định và có định dạng HOSTNAME:PORT. schema_change_detection_databases cũng phải được thiết lập. Một khác biệt của một bảng đã thay đổi được tạo (sử dụng khác biệt).
- schema_change_detection_databases - Danh sách cơ sở dữ liệu được phân tách bằng dấu phẩy để theo dõi các thay đổi của lược đồ. Nếu trống, không có séc nào được thực hiện.
Trong ví dụ này, chúng tôi muốn theo dõi các thay đổi giản đồ cho cơ sở dữ liệu "myapp" và "sbtest" trên Cụm MariaDB của chúng tôi với ID cụm 27. Chọn một trong các nút cơ sở dữ liệu làm giá trị của schema_change_detection_address . Đối với sao chép MySQL, đây phải là máy chủ chính hoặc bất kỳ máy chủ nô lệ nào chứa cơ sở dữ liệu (trong trường hợp sao chép một phần đang hoạt động). Sau đó, bên trong /etc/cmon.d/cmon_27.cnf, thêm hai dòng sau:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestKhởi động lại dịch vụ CMON để tải thay đổi:
$ systemctl restart cmonĐối với báo cáo đầu tiên và quan trọng nhất, ClusterControl chỉ trả về kết quả thu thập siêu dữ liệu, tương tự như bên dưới:
Với báo cáo đầu tiên làm cơ sở, các báo cáo tiếp theo sẽ trả về kết quả mà chúng tôi mong đợi:
Lưu ý rằng chỉ các bảng mới hoặc bảng đã thay đổi mới được in trong báo cáo. Báo cáo đầu tiên chỉ dành cho việc thu thập siêu dữ liệu để so sánh trong các vòng tiếp theo, do đó chúng tôi phải chạy báo cáo này ít nhất hai lần để thấy được sự khác biệt.
Với báo cáo này, giờ đây bạn có thể thu thập các dấu chân của cấu trúc cơ sở dữ liệu và hiểu cơ sở dữ liệu của bạn đã phát triển như thế nào theo thời gian.
Lời kết
Báo cáo hoạt động là một cách toàn diện để hiểu trạng thái của cơ sở hạ tầng cơ sở dữ liệu của bạn. Nó được xây dựng cho cả nhân viên vận hành hoặc quản lý và có thể rất hữu ích trong việc phân tích hoạt động cơ sở dữ liệu của bạn. Báo cáo có thể được tạo tại chỗ hoặc có thể được gửi cho bạn qua email, điều này giúp mọi thứ trở nên dễ dàng thuận tiện nếu bạn có silo báo cáo.
Chúng tôi rất muốn nghe phản hồi của bạn về bất kỳ điều gì khác mà bạn muốn đưa vào báo cáo, những gì còn thiếu và những gì không cần thiết.
