MaxScale 2.4 được phát hành vào ngày 21 tháng 12 năm 2019 và ClusterControl 1.7.6 hỗ trợ giám sát và quản lý đến phiên bản này. Tuy nhiên, để triển khai, ClusterControl chỉ hỗ trợ tối đa phiên bản 2.3. Người ta phải nâng cấp phiên bản theo cách thủ công và may mắn thay, các bước nâng cấp rất đơn giản. Chỉ cần tải xuống phiên bản mới nhất từ trang tải xuống MariaDB MaxScale và thực hiện lệnh cài đặt gói.
Các lệnh sau cho biết cách nâng cấp từ MaxScale 2.3 hiện có lên MaxScale 2.4 trên hộp CentOS 7:
$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10Trong bài đăng trên blog này, chúng tôi sẽ nêu bật một số cải tiến đáng chú ý và các tính năng mới của phiên bản này cũng như cách nó hoạt động. Để có danh sách đầy đủ các thay đổi trong MariaDB MaxScale 2.4, hãy xem bảng thay đổi của nó.
Lịch sử Lệnh Chế độ Tương tác
Về cơ bản, đây là một cải tiến nhỏ có tác động lớn đến hiệu quả tác vụ giám sát và quản trị MaxScale. Chế độ tương tác cho MaxCtrl hiện có lịch sử lệnh của nó. Lịch sử lệnh dễ dàng cho phép bạn lặp lại lệnh đã thực hiện bằng cách nhấn phím mũi tên lên hoặc xuống. Tuy nhiên, chức năng Ctrl + R (gọi lại lệnh cuối cùng khớp với các ký tự bạn cung cấp) vẫn không có ở đó.
Trong các phiên bản trước, người ta phải sử dụng chế độ shell tiêu chuẩn để đảm bảo các lệnh được ghi lại bằng tệp .bash_history.
Giám sát GTID cho galeramon
Đây là một cải tiến tốt cho những người đang chạy trên Galera Cluster có dư thừa về địa lý thông qua sao chép không đồng bộ, còn được gọi là sao chép cụm-thành-cụm hoặc sao chép Cụm MariaDB Galera qua MariaDB Replication.
Trong MaxScale 2.3 trở lên, giao diện sẽ như thế này nếu bạn đã bật tính năng sao chép chủ-nô lệ giữa các Cụm MariaDB:
Đối với MaxScale 2.4, nó trông như thế này (chú ý đến Galera1's hàng):
Giờ đây, việc xem trạng thái sao chép cho tất cả các nút từ MaxScale trở nên dễ dàng hơn mà không cần sự cần thiết phải kiểm tra lặp lại các nút riêng lẻ.
SmartRouter
Đây là một trong những tính năng chính mới trong MaxScale 2.4, nơi MaxScale hiện đủ thông minh để tìm hiểu máy chủ phụ trợ MariaDB nào là tốt nhất để xử lý truy vấn. SmartRouter theo dõi hiệu suất hoặc thời gian thực thi của các truy vấn đến các cụm. Các phép đo được lưu trữ bằng khóa chính tắc của một truy vấn. Quy tắc của một truy vấn là SQL với tất cả các hằng số do người dùng xác định được thay thế bằng dấu chấm hỏi, ví dụ:
UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? Đây là một tính năng rất hữu ích nếu bạn đang chạy MariaDB trên bản sao địa lý nhiều trang web hoặc kết hợp các công cụ lưu trữ MariaDB trong một chuỗi sao chép, ví dụ:một nô lệ chuyên dụng để xử lý khối lượng công việc giao dịch (OLTP ) với công cụ lưu trữ InnoDB và một nô lệ chuyên dụng khác để xử lý khối lượng công việc phân tích (OLAP) với công cụ lưu trữ Columnstore.
Giả sử chúng tôi đang có hai địa điểm - Sydney và Singapore như minh họa trong sơ đồ sau:
Trang web chính đặt tại Singapore và có một chủ MariaDB và một nô lệ , trong khi một nô lệ chỉ đọc khác nằm ở Sydney. Ứng dụng kết nối với phiên bản MaxScale ở quốc gia tương ứng với các cài đặt cổng sau:
- Phân chia đọc-ghi:3306
- Vòng tròn:3307
- Bộ định tuyến thông minh:3308
Định nghĩa trình nghe và dịch vụ SmarRouter của chúng tôi là:
[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308Khởi động lại MaxScale và bắt đầu gửi truy vấn chỉ đọc đến cả hai nút MaxScale ở Singapore và Sydney. Nếu truy vấn được xử lý bởi bộ định tuyến round-robin (cổng 3307), chúng tôi sẽ thấy truy vấn đang được định tuyến dựa trên thuật toán round-robin:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Từ những điều trên, chúng ta có thể nói rằng MaxScale của Sydney đã chuyển tiếp truy vấn trên tới nô lệ ở Singapore của chúng tôi, đây không phải là tùy chọn định tuyến tốt nhất.
Với việc lắng nghe SmartRouter trên cổng 3308, chúng tôi sẽ thấy truy vấn đang được chuyển đến nô lệ gần nhất ở Sydney:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname |
+-----------+-----------------+
| 1000000 | mariadb_sydney1 |
+-----------+-----------------+Và nếu cùng một truy vấn được thực thi trên trang web Singapore của chúng tôi, nó sẽ được chuyển đến nô lệ MariaDB ở Singapore:
(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname |
+-----------+--------------------+
| 1000000 | mariadb_singapore2 |
+-----------+--------------------+Có một vấn đề. Khi SmartRouter nhìn thấy một truy vấn đọc mà chưa từng thấy trước đây, nó sẽ gửi truy vấn đến tất cả các cụm. Phản hồi đầu tiên từ một cụm sẽ chỉ định cụm đó là nhóm tốt nhất cho trang chuẩn đó. Ngoài ra, khi nhận được phản hồi đầu tiên, các truy vấn khác sẽ bị hủy. Phản hồi được gửi đến máy khách sau khi tất cả các cụm đã trả lời truy vấn hoặc hủy.
Điều này có nghĩa là, để theo dõi truy vấn chuẩn (truy vấn chuẩn hóa) và đo lường hiệu suất của nó, bạn có thể sẽ thấy truy vấn đầu tiên không thành công trong lần thực thi đầu tiên, ví dụ:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during queryTừ nhật ký chung trong MariaDB Sydney, chúng ta có thể biết rằng truy vấn đầu tiên (ID 74) đã được thực thi thành công (kết nối, truy vấn và thoát), mặc dù có lỗi "Mất kết nối" từ MaxScale:
74 Connect [email protected] as anonymous on
74 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
74 QuitTrong khi truy vấn tiếp theo giống hệt nhau đã được xử lý chính xác và được trả về với phản hồi chính xác:
(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname |
+-----------+------------------------+
| 1000000 | mariadb_sydney.cluster |
+-----------+------------------------+Nhìn lại nhật ký chung trong MariaDB Sydney (ID 75), các sự kiện xử lý tương tự đã xảy ra giống như truy vấn đầu tiên:
75 Connect [email protected] as anonymous on
75 Query SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
75 QuitTừ quan sát này, chúng ta có thể kết luận rằng đôi khi, MaxScale phải thực hiện không thành công truy vấn đầu tiên để đo lường hiệu suất và trở nên thông minh hơn cho các truy vấn giống hệt nhau sau đó. Ứng dụng của bạn phải có khả năng xử lý đúng "lỗi đầu tiên" này trước khi quay lại ứng dụng khách hoặc thử lại giao dịch một lần nữa.
Ổ cắm UNIX cho Máy chủ
Có nhiều cách để kết nối với máy chủ MySQL hoặc MariaDB đang chạy. Bạn có thể sử dụng mạng tiêu chuẩn TCP / IP với địa chỉ IP máy chủ và cổng (kết nối từ xa), đường ống / bộ nhớ chia sẻ được đặt tên trên Windows hoặc tệp ổ cắm Unix trên hệ thống dựa trên Unix. Tệp ổ cắm UNIX là một loại tệp đặc biệt hỗ trợ giao tiếp giữa các quá trình khác nhau, trong trường hợp này là máy khách MySQL và máy chủ. Tệp socket là giao tiếp dựa trên tệp và bạn không thể truy cập socket từ một máy khác. Nó cung cấp kết nối nhanh hơn TCP / IP (không có mạng) và cách tiếp cận kết nối an toàn hơn vì nó chỉ có thể được sử dụng khi kết nối với một dịch vụ hoặc quy trình trên cùng một máy tính.
Giả sử máy chủ MaxScale cũng được cài đặt trên chính Máy chủ MariaDB, chúng ta có thể sử dụng tệp ổ cắm UNIX socket để thay thế. Trong phần Máy chủ, xóa hoặc ghi chú dòng "địa chỉ" và thêm thông số socket với vị trí của tệp socket:
[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sockTrước khi áp dụng các thay đổi trên, chúng ta phải tạo người dùng MaxScale axscale từ localhost. Trên máy chủ chính:
MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';Sau khi khởi động lại, MaxScale sẽ hiển thị đường dẫn ổ cắm UNIX thay vì địa chỉ thực và danh sách máy chủ sẽ được hiển thị như sau:
Như bạn có thể thấy, trạng thái và thông tin GTID được truy xuất chính xác thông qua kết nối ổ cắm. Lưu ý rằng DB_2 này vẫn đang lắng nghe cổng 3306 cho các kết nối từ xa. Nó chỉ cho thấy rằng MaxScale sử dụng một ổ cắm để kết nối với máy chủ này để theo dõi.
Sử dụng socket luôn tốt hơn do thực tế là nó chỉ cho phép kết nối cục bộ và an toàn hơn. Bạn cũng có thể đóng máy chủ MariaDB của mình khỏi mạng (ví dụ:--skip-networking) và để MaxScale xử lý các kết nối "bên ngoài" và chuyển tiếp chúng đến máy chủ MariaDB thông qua tệp ổ cắm UNIX.
Hệ thống thoát máy chủ
Trong MaxScale 2.4, các máy chủ phụ trợ có thể được thoát ra, có nghĩa là các kết nối hiện có có thể tiếp tục được sử dụng, nhưng sẽ không có kết nối mới nào được tạo đến máy chủ. Với tính năng thoát, chúng tôi có thể thực hiện một hoạt động bảo trì ân hạn mà không ảnh hưởng đến trải nghiệm người dùng từ phía ứng dụng. Lưu ý rằng việc thoát máy chủ có thể mất nhiều thời gian hơn, tùy thuộc vào các truy vấn đang chạy cần được đóng lại.
Để thoát máy chủ, hãy sử dụng lệnh sau:
Hiệu ứng sau có thể là một trong các trạng thái sau:
- Đang thoát - Máy chủ đang được thoát.
- Drained - Máy chủ đã thoát. Máy chủ đang bị thoát và hiện số lượng kết nối đến máy chủ đã giảm xuống còn 0.
- Bảo trì - Máy chủ đang được bảo trì.
Sau khi máy chủ đã được thoát, trạng thái của máy chủ MariaDB theo quan điểm MaxScale là "Bảo trì":
Khi máy chủ ở chế độ bảo trì, sẽ không có kết nối nào được tạo với nó và các kết nối hiện có sẽ bị đóng.
Kết luận
MaxScale 2.4 mang đến nhiều cải tiến và thay đổi so với phiên bản trước và đây là proxy cơ sở dữ liệu tốt nhất để xử lý các máy chủ MariaDB và tất cả các thành phần của nó.
