Cân bằng tải MariaDB MaxScale trên Docker:Quản lý:Phần thứ hai

Bài đăng trên blog này là phần tiếp theo của Cân bằng tải MariaDB MaxScale trên Docker:Triển khai - Phần 1. Trong phần này, chúng tôi sẽ tập trung nhiều hơn vào các hoạt động quản lý với các trường hợp sử dụng nâng cao như kiểm soát dịch vụ, quản lý cấu hình, xử lý truy vấn, bảo mật và điều chỉnh cụm. Các bước và hướng dẫn ví dụ được hiển thị trong bài đăng này dựa trên môi trường đang chạy mà chúng tôi đã thiết lập trong phần đầu tiên của loạt bài blog này.

Kiểm soát dịch vụ

Đối với MaxScale, bắt đầu và dừng vùng chứa là cách duy nhất để kiểm soát dịch vụ. Với điều kiện vùng chứa đã được tạo, chúng ta có thể sử dụng lệnh sau để quản lý dịch vụ:

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

Chạy mà không cần Đặc quyền Root

Các vùng chứa Docker theo mặc định chạy với đặc quyền root và ứng dụng chạy bên trong vùng chứa cũng vậy. Đây là một mối quan tâm lớn khác từ góc độ bảo mật vì tin tặc có thể giành được quyền truy cập root vào máy chủ Docker bằng cách hack ứng dụng đang chạy bên trong vùng chứa.

Để chạy Docker với tư cách người dùng không phải root, bạn phải thêm người dùng của mình vào nhóm docker. Trước hết, hãy tạo một nhóm docker nếu không có:

$ sudo groupadd docker

Sau đó, thêm người dùng của bạn vào nhóm docker. Trong ví dụ này, người dùng của chúng tôi là "vagrant":

$ sudo usermod -aG docker vagrant

Đăng xuất và đăng nhập lại để thành viên nhóm của bạn được đánh giá lại (hoặc khởi động lại nếu nó không hoạt động). Tại thời điểm này, bạn có thể chạy vùng chứa MaxScale bằng lệnh chạy tiêu chuẩn (không yêu cầu sudo) với tư cách là người dùng "vagrant":

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

Quá trình MaxScale chạy bởi người dùng "maxscale" và không yêu cầu đặc quyền đặc biệt ở cấp cơ sở. Do đó, chạy vùng chứa ở chế độ không đặc quyền luôn là cách tốt nhất nếu bạn lo lắng về bảo mật.

Quản lý cấu hình

Đối với vùng chứa MaxScale độc ​​lập, quản lý cấu hình yêu cầu sửa đổi tệp cấu hình được ánh xạ, sau đó khởi động lại vùng chứa MaxScale. Tuy nhiên, nếu bạn đang chạy dưới dạng dịch vụ Docker Swarm, cấu hình mới phải được tải vào Swarm Configs dưới dạng phiên bản mới, ví dụ:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Sau đó, cập nhật dịch vụ bằng cách xóa cấu hình cũ (maxscale_config) và thêm cấu hình mới (maxscale_config_v2) vào cùng một mục tiêu:

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

Docker Swarm sau đó sẽ lập lịch trình loại bỏ vùng chứa và thay thế từng vùng chứa một cho đến khi đáp ứng được yêu cầu về bản sao.

Nâng cấp và hạ cấp

Một trong những lợi thế khi chạy các ứng dụng của bạn trong Docker là quy trình nâng cấp và hạ cấp nhỏ. Mọi vùng chứa đang chạy đều dựa trên một hình ảnh và hình ảnh này có thể được chuyển đổi dễ dàng bằng thẻ hình ảnh. Để nhận danh sách các hình ảnh có sẵn cho MaxScale, hãy xem phần Thẻ trong Docker Hub. Các ví dụ sau đây cho thấy quá trình hạ cấp MaxScale 2.3 xuống một phiên bản nhỏ trước đó, 2.2:

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

Đảm bảo các tùy chọn cấu hình tương thích với phiên bản bạn muốn chạy. Ví dụ:việc hạ cấp ở trên sẽ không thành công ở lần chạy đầu tiên do các lỗi sau:

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

Những gì chúng ta cần làm là xóa các tùy chọn cấu hình không được hỗ trợ như được hiển thị ở trên trong tệp cấu hình trước khi hạ cấp hình ảnh vùng chứa:

• master_reconnection
• delay_retry
• transaction_replay
• causal_reads_timeout
• causal_reads

Cuối cùng, bắt đầu lại thùng chứa và bạn sẽ tốt. Nâng cấp phiên bản cho MaxScale hoạt động tương tự. Chỉ cần thay đổi thẻ bạn muốn sử dụng và bạn có thể bắt đầu.

Bộ lọc MaxScale

MaxScale sử dụng một thành phần được gọi là bộ lọc để thao tác hoặc xử lý các yêu cầu khi chúng đi qua nó. Có rất nhiều bộ lọc bạn có thể sử dụng, như được liệt kê trong trang này, Bộ lọc MaxScale 2.3. Ví dụ:một truy vấn cụ thể có thể được đăng nhập vào một tệp nếu nó phù hợp với một tiêu chí hoặc bạn có thể viết lại truy vấn đến trước khi nó đến các máy chủ phụ trợ.

Để kích hoạt một bộ lọc, bạn phải xác định một phần và bao gồm tên định nghĩa vào định nghĩa dịch vụ tương ứng, như được hiển thị trong các ví dụ bên dưới.

Tất cả ghi nhật ký truy vấn (QLA)

Như tên của nó giải thích, nhật ký bộ lọc QLA tất cả các truy vấn khớp với tập hợp quy tắc cho mỗi phiên khách hàng. Tất cả các truy vấn sẽ được ghi lại theo định dạng filebase.

Đầu tiên, xác định thành phần với type =filter và module =qlafilter:

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

Sau đó, thêm thành phần bộ lọc vào các dịch vụ của chúng tôi:

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

Bạn cũng nên ánh xạ / tmp của vùng chứa với thư mục thực trên máy chủ Docker, vì vậy chúng tôi không phải truy cập vùng chứa để truy xuất các tệp nhật ký đã tạo. Đầu tiên, tạo một thư mục và cấp quyền có thể ghi toàn cầu:

$ mkdir qla
$ chmod 777 qla

Vì chúng ta cần liên kết thư mục trên vào vùng chứa, chúng ta phải dừng và xóa vùng chứa đang chạy và chạy lại nó bằng lệnh sau:

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

Sau đó, bạn có thể truy xuất nội dung của các truy vấn đã ghi bên trong thư mục qla:

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

Viết lại truy vấn

Ghi lại truy vấn là một tính năng, tùy thuộc vào các truy vấn đang chạy trên máy chủ cơ sở dữ liệu, cho phép nhanh chóng cô lập và sửa các truy vấn có vấn đề, đồng thời cải thiện hiệu suất.

Việc viết lại truy vấn có thể được thực hiện thông qua regexfilter. Bộ lọc này có thể đối sánh hoặc loại trừ các câu lệnh đến bằng cách sử dụng cụm từ thông dụng và thay thế chúng bằng một câu lệnh khác. Mọi quy tắc được xác định trong phần riêng của nó và bao gồm tên phần trong dịch vụ tương ứng để kích hoạt nó.

Bộ lọc sau sẽ khớp với một số lệnh SHOW mà chúng tôi không muốn hiển thị cho máy khách chỉ đọc:

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

Sau đó, chúng tôi có thể thêm bộ lọc vào dịch vụ mà chúng tôi muốn áp dụng. Ví dụ:tất cả các kết nối chỉ đọc phải được lọc cho những điều trên:

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Hãy nhớ rằng nhiều bộ lọc có thể được xác định bằng cú pháp tương tự như đường dẫn shell Linux "|" cú pháp. Khởi động lại vùng chứa để áp dụng các thay đổi cấu hình:

$ docker restart maxscale

Sau đó, chúng tôi có thể xác minh bằng truy vấn sau:

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

Bạn sẽ nhận được kết quả như mong đợi.

Khôi phục cụm

MaxScale 2.2.2 trở lên hỗ trợ sao chép MariaDB tự động hoặc thủ công hoặc khôi phục cụm cho các sự kiện sau:

• chuyển đổi dự phòng
• trình chuyển đổi
• tham gia lại
• đặt lại-sao chép

Chuyển đổi dự phòng cho cụm chủ-tớ có thể và thường phải được đặt để kích hoạt tự động. Chuyển đổi phải được kích hoạt thủ công thông qua MaxAdmin, MaxCtrl hoặc giao diện REST. Rejoin có thể được đặt thành tự động hoặc kích hoạt thủ công. Các tính năng này được triển khai trong mô-đun "mariadbmon".

Các sự kiện chuyển đổi dự phòng tự động sau đây đã xảy ra nếu chúng tôi cố tình tắt máy chủ đang hoạt động, 192.168.0.91:

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

Sau khi chuyển đổi dự phòng hoàn tất, cấu trúc liên kết của chúng tôi bây giờ trông như thế này:

Đối với hoạt động chuyển đổi, nó yêu cầu sự can thiệp của con người và một cách để thực hiện thông qua bảng điều khiển MaxCtrl. Giả sử cái cũ đã hoạt động trở lại và sẵn sàng thăng cấp làm cái, chúng ta có thể thực hiện thao tác chuyển đổi bằng cách gửi lệnh sau:

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

Ở đâu, định dạng là:

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

Sau đó, xác minh cấu trúc liên kết mới bằng cách liệt kê ra các máy chủ:

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Chúng tôi vừa thăng cấp cho chủ cũ của mình trở lại vị trí ban đầu. Thực tế thú vị là tính năng khôi phục tự động ClusterControl thực hiện chính xác những điều tương tự nếu nó được bật.

Lời kết

Chạy MariaDB MaxScale trên Docker mang lại các lợi ích bổ sung như phân cụm MaxScale, dễ dàng nâng cấp và hạ cấp cũng như các chức năng ủy quyền nâng cao cho các cụm MySQL và MariaDB.