Nhân rộng MySQL với ProxySQL trên Máy chủ WHM / cPanel:Phần thứ hai

Trong phần đầu tiên của loạt bài này, chúng tôi đã hướng dẫn bạn cách triển khai thiết lập MySQL Replication với ProxySQL với WHM và cPanel. Trong phần này, chúng tôi sẽ trình bày một số hoạt động sau triển khai để bảo trì, quản lý, chuyển đổi dự phòng cũng như các ưu điểm so với thiết lập độc lập.

Quản lý người dùng MySQL

Với việc tích hợp này được kích hoạt, việc quản lý người dùng MySQL sẽ phải được thực hiện từ WHM hoặc cPanel. Nếu không, bảng ProxySQL mysql_users sẽ không đồng bộ với những gì được cấu hình cho bản sao tổng thể của chúng tôi. Giả sử chúng ta đã tạo một người dùng có tên là vàin_user1 (tên người dùng MySQL được cPanel tự động đặt tiền tố để tuân theo giới hạn của MySQL) và chúng ta muốn gán cho cơ sở dữ liệu vàin_db1 như sau:

Ở trên sẽ dẫn đến kết quả đầu ra bảng mysql_users sau trong ProxySQL:

Nếu bạn muốn tạo tài nguyên MySQL bên ngoài cPanel, bạn có thể sử dụng ClusterControl -> Manage -> Schemas and Users và sau đó nhập người dùng cơ sở dữ liệu vào ProxySQL bằng cách đi tới ClusterControl -> Nodes -> chọn nút ProxySQL -> Người dùng -> Nhập Người dùng .

Mô-đun Proxysqlhook mà chúng tôi sử dụng để đồng bộ hóa người dùng ProxySQL gửi nhật ký gỡ lỗi vào / usr / local / cpanel / logs / error_log. Sử dụng tệp này để kiểm tra và hiểu những gì xảy ra ở hậu trường. Các dòng sau sẽ xuất hiện trong tệp nhật ký cPanel nếu chúng tôi đã cài đặt ứng dụng web có tên Zikula bằng Softaculous:

[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****

Bạn sẽ thấy một số dòng lặp lại như "Kiểm tra xem {DB user} có tồn tại hay không" vì WHM tạo nhiều máy chủ / người dùng MySQL cho mọi yêu cầu tạo cơ sở dữ liệu của người dùng. Trong ví dụ của chúng tôi, WHM sẽ tạo 3 người dùng sau:

ProxySQL chỉ cần tên người dùng, mật khẩu và thông tin nhóm máy chủ mặc định khi thêm người dùng. Do đó, các dòng kiểm tra ở đó để tránh nhiều lần chèn của cùng một người dùng.

Nếu bạn muốn sửa đổi mô-đun và thực hiện một số cải tiến đối với nó, đừng quên đăng ký lại mô-đun bằng cách chạy lệnh sau trên máy chủ WHM:

(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHook

Giám sát truy vấn và lưu vào bộ nhớ đệm

Với ProxySQL, bạn có thể giám sát tất cả các truy vấn đến từ ứng dụng đã được chuyển hoặc đang chuyển qua nó. WHM tiêu chuẩn không cung cấp mức độ chi tiết này trong việc giám sát truy vấn MySQL. Phần sau hiển thị tất cả các truy vấn MySQL đã được ProxySQL nắm bắt:

Với ClusterControl, bạn có thể dễ dàng tra cứu các truy vấn lặp lại nhiều nhất và lưu vào bộ nhớ cache thông qua tính năng bộ nhớ cache truy vấn ProxySQL. Sử dụng menu thả xuống "Đặt hàng theo" để sắp xếp các truy vấn theo "Đếm dấu sao", di chuyển đến truy vấn mà bạn muốn lưu vào bộ nhớ cache và nhấp vào nút "Truy vấn bộ nhớ cache" bên dưới nó. Hộp thoại sau sẽ xuất hiện:

Tập kết quả của các truy vấn được lưu trong bộ nhớ cache sẽ được lưu trữ và phân phát bởi chính ProxySQL, giảm số lần truy cập vào phần phụ trợ, điều này sẽ làm giảm tải toàn bộ cụm sao chép MySQL của bạn. Triển khai bộ đệm truy vấn ProxySQL về cơ bản khác với bộ đệm truy vấn MySQL. Đó là bộ nhớ cache dựa trên thời gian và sẽ hết hạn sau thời gian chờ được gọi là "Cache TTL". Trong cấu hình này, chúng tôi muốn lưu vào bộ nhớ cache truy vấn trên trong 5 giây (5000 mili giây) kể từ khi nhấn vào nhóm người đọc có nhóm máy chủ đích là 20.

Đọc / ghi Tách và Cân bằng

Bằng cách lắng nghe cổng mặc định của MySQL 3306, ProxySQL hoạt động giống như chính máy chủ MySQL. Nó nói giao thức MySQL trên cả giao diện người dùng và phụ trợ. Các quy tắc truy vấn được ClusterControl xác định khi thiết lập ProxySQL sẽ tự động chia tất cả các lần đọc (^ SELECT. * Trong ngôn ngữ Regex) thành nhóm máy chủ 20 là nhóm người đọc và phần còn lại sẽ được chuyển tiếp đến nhóm máy chủ nhà văn 10, như được hiển thị trong phần quy tắc truy vấn sau:

Với kiến trúc này, bạn không phải lo lắng về việc chia nhỏ các truy vấn đọc / ghi vì ProxySQL sẽ thực hiện công việc đó cho bạn. Người dùng có tối thiểu hoặc không có thay đổi nào đối với mã, cho phép người dùng lưu trữ sử dụng tất cả các ứng dụng và tính năng do WHM và cPanel cung cấp nguyên bản, tương tự như kết nối với thiết lập MySQL độc lập.

Về cân bằng kết nối, nếu bạn có nhiều hơn một nút hoạt động trong một nhóm máy chủ cụ thể (như nhóm máy chủ đọc 20 trong ví dụ này), ProxySQL sẽ tự động phân bổ tải giữa chúng dựa trên một số tiêu chí - trọng số, độ trễ sao chép, kết nối được sử dụng , tải tổng thể và độ trễ. ProxySQL được biết là rất tốt trong môi trường đồng thời cao bằng cách triển khai cơ chế gộp kết nối nâng cao. Trích dẫn từ bài đăng trên blog ProxySQL, ProxySQL không chỉ triển khai Kết nối liên tục mà còn cả Ghép kênh kết nối. Trên thực tế, ProxySQL có thể xử lý hàng trăm nghìn máy khách, nhưng chuyển tiếp tất cả lưu lượng truy cập của họ đến một vài kết nối tới phần phụ trợ. Vì vậy, ProxySQL có thể xử lý N kết nối máy khách và M kết nối phụ trợ, trong đó N> M (thậm chí N lớn hơn M hàng nghìn lần).

Chuyển đổi dự phòng và phục hồi MySQL

Với ClusterControl quản lý cụm sao chép, chuyển đổi dự phòng được thực hiện tự động nếu tính năng khôi phục tự động được bật. Trong trường hợp lỗi chính:

ClusterControl sẽ phát hiện và xác minh lỗi chính thông qua máy khách MySQL, SSH và ping.
ClusterControl sẽ đợi 3 giây trước khi bắt đầu quy trình chuyển đổi dự phòng.
ClusterControl sẽ thúc đẩy máy chủ cập nhật nhất trở thành máy chủ tiếp theo.
Nếu bản gốc cũ trực tuyến trở lại, bản chính sẽ được bắt đầu ở dạng chỉ đọc mà không cần tham gia vào quá trình tái tạo đang hoạt động.
Người dùng quyết định điều gì sẽ xảy ra với bản chính cũ. Nó có thể được đưa trở lại chuỗi nhân bản bằng cách sử dụng chức năng "Rebuild Replication Slave" trong ClusterControl.
ClusterControl sẽ chỉ cố gắng thực hiện chuyển đổi dự phòng chính một lần. Nếu không thành công, cần phải có sự can thiệp của người dùng.

Bạn có thể theo dõi toàn bộ quá trình chuyển đổi dự phòng trong ClusterControl -> Hoạt động -> Công việc -> Chuyển đổi dự phòng sang một cái mới như hình dưới đây:

Trong quá trình chuyển đổi dự phòng, tất cả các kết nối đến máy chủ cơ sở dữ liệu sẽ được xếp hàng trong ProxySQL. Chúng sẽ không bị chấm dứt cho đến khi hết thời gian chờ, được kiểm soát bởi mysql-default_query_timeout biến là 86400000 mili giây hoặc 24 giờ. Các ứng dụng hầu như sẽ không thấy lỗi hoặc hỏng cơ sở dữ liệu tại thời điểm này, nhưng sự cân bằng là độ trễ tăng lên, trong một ngưỡng có thể định cấu hình.

Tại thời điểm này, ClusterControl sẽ trình bày cấu trúc liên kết như sau:

Nếu chúng tôi muốn cho phép bản chính cũ tham gia trở lại vào bản sao sau khi nó được thiết lập và khả dụng, chúng ta sẽ cần xây dựng lại nó dưới dạng nô lệ bằng cách đi tới ClusterControl -> Nodes -> chọn bản chính cũ -> Xây dựng lại bản sao Nô lệ -> chọn chủ mới -> Tiếp tục . Sau khi xây dựng lại hoàn tất, bạn sẽ nhận được cấu trúc liên kết sau (thông báo 192.168.0.32 hiện là cái chính):

Hợp nhất máy chủ và mở rộng cơ sở dữ liệu

Với kiến trúc này, chúng tôi có thể hợp nhất nhiều máy chủ MySQL nằm trên mọi máy chủ WHM thành một thiết lập sao chép duy nhất. Bạn có thể mở rộng quy mô nhiều nút cơ sở dữ liệu hơn khi bạn phát triển hoặc có nhiều cụm sao chép để hỗ trợ tất cả chúng và được quản lý bởi một máy chủ ClusterControl duy nhất. Sơ đồ kiến trúc sau đây minh họa nếu chúng ta có hai máy chủ WHM được kết nối với một cụm sao chép MySQL duy nhất thông qua tệp ổ cắm ProxySQL:

Những điều trên cho phép chúng tôi tách biệt hai tầng quan trọng nhất trong hệ thống lưu trữ của chúng tôi - ứng dụng (front-end) và cơ sở dữ liệu (back-end). Như bạn có thể biết, việc đồng định vị MySQL trong máy chủ WHM thường dẫn đến cạn kiệt tài nguyên vì MySQL cần phân bổ RAM trả trước rất lớn để khởi động và hoạt động tốt (chủ yếu phụ thuộc vào innodb_buffer_pool_size Biến đổi). Xem xét dung lượng ổ đĩa là đủ, với thiết lập trên, bạn có thể có nhiều tài khoản lưu trữ hơn được lưu trữ trên mỗi máy chủ, nơi tất cả các tài nguyên máy chủ có thể được sử dụng bởi các ứng dụng lớp front-end.

Mở rộng quy mô cụm sao chép MySQL sẽ đơn giản hơn nhiều với kiến trúc tầng riêng biệt. Nếu giả sử chủ yêu cầu bảo trì mở rộng quy mô (nâng cấp RAM, đĩa cứng, RAID, NIC), chúng ta có thể chuyển vai trò chủ sang một nô lệ khác ( ClusterControl -> Nodes -> chọn một nô lệ -> Thúc đẩy Slave ) và sau đó thực hiện tác vụ bảo trì mà không ảnh hưởng đến dịch vụ MySQL nói chung. Đối với hoạt động mở rộng quy mô (thêm nhiều nô lệ hơn), bạn có thể thực hiện điều đó mà không ảnh hưởng đến tổng thể bằng cách thực hiện phân đoạn trực tiếp từ bất kỳ nô lệ đang hoạt động nào. Với ClusterControl, bạn thậm chí có thể tạo một nô lệ mới từ bản sao lưu MySQL hiện có (chỉ tương thích với PITR):

Việc xây dựng lại một nô lệ từ bản sao lưu sẽ không mang thêm gánh nặng cho chủ nhân. ClusterControl sẽ sao chép tệp sao lưu đã chọn từ máy chủ ClusterControl vào nút đích và thực hiện khôi phục ở đó. Sau khi hoàn tất, nút sẽ kết nối với nút chính và bắt đầu truy xuất tất cả các giao dịch bị thiếu kể từ thời điểm khôi phục và bắt kịp với nút chính. Khi nó bị trễ, ProxySQL sẽ không bao gồm nút trong bộ cân bằng tải cho đến khi độ trễ sao chép dưới 10 giây (có thể định cấu hình khi thêm bảng mysql_servers qua giao diện quản trị ProxySQL).

Lời kết

ProxySQL mở rộng khả năng của WHM cPanel trong việc quản lý MySQL Replication. Với ClusterControl quản lý cụm sao chép của bạn, tất cả các tác vụ phức tạp liên quan đến quản lý cụm sao chép giờ đây trở nên dễ dàng hơn bao giờ hết.