ProxySQL là một proxy SQL thông minh và hiệu suất cao hỗ trợ MySQL, MariaDB và ClickHouse. Gần đây, ProxySQL 2.0 đã trở thành GA và nó đi kèm với các tính năng thú vị mới như đọc nhất quán GTID, giao diện người dùng SSL, hỗ trợ gốc Galera và MySQL Group Replication.
Nó tương đối dễ dàng để chạy ProxySQL như Docker container. Trước đây chúng tôi đã viết về cách chạy ProxySQL trên Kubernetes dưới dạng vùng chứa trợ giúp hoặc dưới dạng dịch vụ Kubernetes, dựa trên ProxySQL 1.x. Trong bài đăng blog này, chúng tôi sẽ sử dụng phiên bản mới ProxySQL 2.x sử dụng một cách tiếp cận khác cho cấu hình Galera Cluster.
Hình ảnh Docker ProxySQL 2.x
Chúng tôi đã phát hành một vùng chứa hình ảnh ProxySQL 2.0 Docker mới và nó có sẵn trong Docker Hub. README cung cấp một số ví dụ cấu hình đặc biệt cho Galera và MySQL Replication, trước và sau v2.x. Các dòng cấu hình có thể được xác định trong một tệp văn bản và được ánh xạ vào đường dẫn của vùng chứa tại /etc/proxysql.cnf để được tải vào dịch vụ ProxySQL.
Thẻ hình ảnh "mới nhất" vẫn trỏ đến 1.x cho đến khi ProxySQL 2.0 chính thức trở thành GA (chúng tôi chưa thấy bất kỳ bài báo / blog phát hành chính thức nào từ nhóm ProxySQL). Có nghĩa là, bất cứ khi nào bạn cài đặt hình ảnh ProxySQL bằng thẻ mới nhất từ Somenines, bạn vẫn sẽ nhận được phiên bản 1.x với nó. Hãy lưu ý rằng các cấu hình ví dụ mới cũng cho phép thống kê web ProxySQL (được giới thiệu trong 1.4.4 nhưng vẫn đang trong giai đoạn thử nghiệm) - một trang tổng quan đơn giản tóm tắt cấu hình tổng thể và trạng thái của chính ProxySQL.
Hỗ trợ ProxySQL 2.x cho Galera Cluster
Hãy nói chi tiết hơn về hỗ trợ gốc của Galera Cluster. Bảng mysql_galera_hostgroups mới bao gồm các trường sau:
- writer_hostgroup : ID của nhóm máy chủ sẽ chứa tất cả các thành viên là người viết (read_only =0).
- backup_writer_hostgroup : Nếu cụm đang chạy ở chế độ nhiều người viết (tức là có nhiều nút với read_only =0) và max_writers được đặt thành một số nhỏ hơn tổng số nút, thì các nút bổ sung sẽ được chuyển đến nhóm máy chủ người viết dự phòng này.
- reader_hostgroup : ID của nhóm máy chủ sẽ chứa tất cả các thành viên là trình đọc (tức là các nút có read_only =1)
- offline_hostgroup : Khi giám sát ProxySQL xác định máy chủ lưu trữ là OFFLINE, máy chủ đó sẽ được chuyển đến offline_hostgroup.
- hoạt động : giá trị boolean (0 hoặc 1) để kích hoạt nhóm máy chủ
- max_writers : Kiểm soát số lượng tối đa các nút được phép trong nhóm máy chủ người viết, như đã đề cập trước đó, các nút bổ sung sẽ được chuyển đến nhóm backup_writer_hostgroup.
- writer_is_also_reader : Khi 1, một nút trong writer_hostgroup cũng sẽ được đặt trong reader_hostgroup để nó sẽ được sử dụng cho các lần đọc. Khi được đặt thành 2, các nút từ backup_writer_hostgroup sẽ được đặt trong reader_hostgroup, thay vì (các) nút trong writer_hostgroup.
- max_transactions_behind : xác định số lần ghi tối đa mà một nút trong cụm có thể xếp hàng đợi trước khi nút được CHỤP để ngăn các lần đọc cũ (điều này được xác định bằng cách truy vấn biến wsrep_local_recv_queue Galera).
- nhận xét : Trường văn bản có thể được sử dụng cho bất kỳ mục đích nào do người dùng xác định
Đây là cấu hình ví dụ cho mysql_galera_hostgroups ở định dạng bảng:
Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment: ProxySQL thực hiện kiểm tra tình trạng Galera bằng cách theo dõi trạng thái / biến MySQL sau:
- read_only - Nếu BẬT, thì ProxySQL sẽ nhóm máy chủ đã xác định thành reader_hostgroup trừ khi writer_is_also_reader là 1.
- wsrep_desync - Nếu BẬT, ProxySQL sẽ đánh dấu nút là không khả dụng, chuyển nó sang offline_hostgroup.
- wsrep_reject_queries - Nếu biến này được BẬT, ProxySQL sẽ đánh dấu nút là không khả dụng, chuyển nó sang offline_hostgroup (hữu ích trong một số trường hợp bảo trì nhất định).
- wsrep_sst_donor_rejects_queries - Nếu biến này BẬT, ProxySQL sẽ đánh dấu nút là không khả dụng trong khi nút Galera đang đóng vai trò là nhà tài trợ SST, di chuyển nó đến offline_hostgroup.
- wsrep_local_state - Nếu trạng thái này trả về khác với 4 (4 nghĩa là Đã đồng bộ hóa), ProxySQL sẽ đánh dấu nút là không khả dụng và chuyển nó vào offline_hostgroup.
- wsrep_local_recv_queue - Nếu trạng thái này cao hơn max_transactions_behind, nút sẽ bị tắt.
- wsrep_cluster_status - Nếu trạng thái này trả về không phải là chính, ProxySQL sẽ đánh dấu nút là không khả dụng và chuyển nó vào offline_hostgroup.
Phải nói rằng, bằng cách kết hợp các tham số mới này trong mysql_galera_hostgroups cùng với mysql_query_rules, ProxySQL 2.x có khả năng linh hoạt để phù hợp với nhiều trường hợp sử dụng Galera hơn. Ví dụ:một người có thể có nhóm máy chủ một người viết, nhiều người viết và nhiều người đọc được xác định là nhóm máy chủ đích của quy tắc truy vấn, với khả năng giới hạn số lượng người viết và kiểm soát tốt hơn đối với hành vi đọc cũ.
Ngược lại điều này với ProxySQL 1.x, trong đó người dùng phải xác định rõ ràng một bộ lập lịch để gọi một tập lệnh bên ngoài để thực hiện kiểm tra tình trạng phụ trợ và cập nhật trạng thái máy chủ cơ sở dữ liệu. Điều này yêu cầu một số tùy chỉnh đối với tập lệnh (người dùng phải cập nhật người dùng / mật khẩu / cổng quản trị ProxySQL) cộng với nó phụ thuộc vào một công cụ bổ sung (ứng dụng khách MySQL) để kết nối với giao diện quản trị ProxySQL.
Đây là một cấu hình ví dụ của bộ lập lịch tập lệnh kiểm tra sức khỏe Galera ở định dạng bảng cho ProxySQL 1.x:
Admin> select * from scheduler\G
*************************** 1. row ***************************
id: 1
active: 1
interval_ms: 2000
filename: /usr/share/proxysql/tools/proxysql_galera_checker.sh
arg1: 10
arg2: 20
arg3: 1
arg4: 1
arg5: /var/lib/proxysql/proxysql_galera_checker.log
comment:Bên cạnh đó, vì luồng trình lập lịch ProxySQL thực thi bất kỳ tập lệnh nào một cách độc lập, nên có rất nhiều phiên bản của tập lệnh kiểm tra sức khỏe có sẵn trên mạng. Tất cả các phiên bản ProxySQL được ClusterControl triển khai đều sử dụng tập lệnh mặc định được cung cấp bởi gói trình cài đặt ProxySQL.
Trong ProxySQL 2.x, các biến max_writers và writer_is_also_reader có thể xác định cách ProxySQL nhóm động các máy chủ MySQL phụ trợ và sẽ ảnh hưởng trực tiếp đến việc phân phối kết nối và định tuyến truy vấn. Ví dụ:hãy xem xét các máy chủ phụ trợ MySQL sau:
Admin> select hostgroup_id, hostname, status, weight from mysql_servers;
+--------------+--------------+--------+--------+
| hostgroup_id | hostname | status | weight |
+--------------+--------------+--------+--------+
| 10 | DB1 | ONLINE | 1 |
| 10 | DB2 | ONLINE | 1 |
| 10 | DB3 | ONLINE | 1 |
+--------------+--------------+--------+--------+Cùng với định nghĩa nhóm máy chủ Galera sau:
Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 20
reader_hostgroup: 30
offline_hostgroup: 9999
active: 1
max_writers: 1
writer_is_also_reader: 2
max_transactions_behind: 20
comment: Xem xét tất cả các máy chủ đã được thiết lập và đang chạy, ProxySQL rất có thể sẽ nhóm các máy chủ như sau:
Hãy xem xét từng cái một:
Cấu hình| Mô tả | |
|---|---|
| riter_is_also_reader =0 |
|
| riter_is_also_reader =1 |
|
| riter_is_also_reader =2 |
|
Với cấu hình này, người ta có thể có nhiều lựa chọn khác nhau cho đích đến của nhóm máy chủ để phục vụ cho các khối lượng công việc cụ thể. Các ghi "hotspot" có thể được định cấu hình để chỉ đi đến một máy chủ để giảm xung đột đa chủ, các ghi không xung đột có thể được phân phối đồng đều trên các chủ khác, hầu hết các lần đọc có thể được phân phối đồng đều trên tất cả các máy chủ MySQL hoặc người không ghi, các lần đọc quan trọng có thể được chuyển tiếp đến các máy chủ cập nhật nhất và các bài đọc phân tích có thể được chuyển tiếp đến một bản sao nô lệ.
Triển khai ProxySQL cho Galera Cluster
Trong ví dụ này, giả sử chúng ta đã có một Cụm Galera ba nút được ClusterControl triển khai như thể hiện trong sơ đồ sau:
Các ứng dụng Wordpress của chúng tôi đang chạy trên Docker trong khi cơ sở dữ liệu Wordpress được lưu trữ trên Galera Cluster của chúng tôi đang chạy trên các máy chủ trần. Chúng tôi quyết định chạy một vùng chứa ProxySQL cùng với các vùng chứa Wordpress của chúng tôi để kiểm soát tốt hơn việc định tuyến truy vấn cơ sở dữ liệu Wordpress và sử dụng đầy đủ cơ sở hạ tầng cụm cơ sở dữ liệu của chúng tôi. Vì tỷ lệ đọc-ghi là khoảng 80% -20%, chúng tôi muốn định cấu hình ProxySQL thành:
- Chuyển tiếp tất cả các lần ghi vào một nút Galera (ít xung đột hơn, tập trung vào việc ghi)
- Cân bằng tất cả các lần đọc cho hai nút Galera khác (phân phối tốt hơn cho phần lớn khối lượng công việc)
Đầu tiên, hãy tạo tệp cấu hình ProxySQL bên trong máy chủ Docker để chúng tôi có thể ánh xạ nó vào vùng chứa của mình:
$ mkdir /root/proxysql-docker
$ vim /root/proxysql-docker/proxysql.cnfSau đó, sao chép các dòng sau (chúng tôi sẽ giải thích thêm về các dòng cấu hình):
datadir="/var/lib/proxysql"
admin_variables=
{
admin_credentials="admin:admin"
mysql_ifaces="0.0.0.0:6032"
refresh_interval=2000
web_enabled=true
web_port=6080
stats_credentials="stats:admin"
}
mysql_variables=
{
threads=4
max_connections=2048
default_query_delay=0
default_query_timeout=36000000
have_compress=true
poll_timeout=2000
interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
default_schema="information_schema"
stacksize=1048576
server_version="5.1.30"
connect_timeout_server=10000
monitor_history=60000
monitor_connect_interval=200000
monitor_ping_interval=200000
ping_interval_server_msec=10000
ping_timeout_server=200
commands_stats=true
sessions_sort=true
monitor_username="proxysql"
monitor_password="proxysqlpassword"
monitor_galera_healthcheck_interval=2000
monitor_galera_healthcheck_timeout=800
}
mysql_galera_hostgroups =
(
{
writer_hostgroup=10
backup_writer_hostgroup=20
reader_hostgroup=30
offline_hostgroup=9999
max_writers=1
writer_is_also_reader=1
max_transactions_behind=30
active=1
}
)
mysql_servers =
(
{ address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)
mysql_query_rules =
(
{
rule_id=100
active=1
match_pattern="^SELECT .* FOR UPDATE"
destination_hostgroup=10
apply=1
},
{
rule_id=200
active=1
match_pattern="^SELECT .*"
destination_hostgroup=30
apply=1
},
{
rule_id=300
active=1
match_pattern=".*"
destination_hostgroup=10
apply=1
}
)
mysql_users =
(
{ username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
{ username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)Bây giờ, chúng ta hãy ghé thăm một số phần cấu hình nhất. Đầu tiên, chúng tôi xác định cấu hình nhóm máy chủ Galera như sau:
mysql_galera_hostgroups =
(
{
writer_hostgroup=10
backup_writer_hostgroup=20
reader_hostgroup=30
offline_hostgroup=9999
max_writers=1
writer_is_also_reader=1
max_transactions_behind=30
active=1
}
)Nhóm máy chủ 10 sẽ là nhóm nhà văn, nhóm máy chủ lưu trữ 20 cho bộ sao lưu và nhóm máy chủ lưu trữ 30 cho bộ đọc. Chúng tôi đặt max_writers thành 1 để chúng tôi có thể có một nhóm máy chủ một người viết cho nhóm máy chủ 10 nơi tất cả các bài viết sẽ được gửi đến. Sau đó, chúng tôi xác địnhriter_is_also_reader thành 1, điều này sẽ làm cho tất cả các nút Galera cũng như trình đọc, phù hợp cho các truy vấn có thể được phân phối đồng đều cho tất cả các nút. Hostgroup 9999 được dành riêng cho offline_hostgroup nếu ProxySQL phát hiện các nút Galera chưa hoạt động.
Sau đó, chúng tôi định cấu hình máy chủ MySQL của mình với mặc định thành nhóm máy chủ 10:
mysql_servers =
(
{ address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
{ address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)
Với các cấu hình trên, ProxySQL sẽ "nhìn thấy" các nhóm máy chủ của chúng ta như bên dưới:
Sau đó, chúng tôi xác định định tuyến truy vấn thông qua các quy tắc truy vấn. Dựa trên yêu cầu của chúng tôi, tất cả các lần đọc phải được gửi đến tất cả các nút Galera ngoại trừ người viết (nhóm máy chủ 20) và mọi thứ khác được chuyển tiếp đến nhóm máy chủ 10 cho người viết đơn:
mysql_query_rules =
(
{
rule_id=100
active=1
match_pattern="^SELECT .* FOR UPDATE"
destination_hostgroup=10
apply=1
},
{
rule_id=200
active=1
match_pattern="^SELECT .*"
destination_hostgroup=20
apply=1
},
{
rule_id=300
active=1
match_pattern=".*"
destination_hostgroup=10
apply=1
}
)Cuối cùng, chúng tôi xác định người dùng MySQL sẽ được chuyển qua ProxySQL:
mysql_users =
(
{ username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
{ username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)Chúng tôi đặt giao dịch_theo dai dẳng thành 0 để tất cả các kết nối đến từ những người dùng này sẽ tôn trọng các quy tắc truy vấn để định tuyến đọc và ghi. Nếu không, các kết nối sẽ kết thúc với một nhóm máy chủ, điều này làm mất đi mục đích cân bằng tải. Đừng quên tạo những người dùng đó trước trên tất cả các máy chủ MySQL. Đối với người dùng ClusterControl, bạn có thể sử dụng tính năng Quản lý -> Lược đồ và Người dùng để tạo những người dùng đó.
Bây giờ chúng tôi đã sẵn sàng để bắt đầu vùng chứa của chúng tôi. Chúng tôi sẽ ánh xạ tệp cấu hình ProxySQL dưới dạng liên kết gắn kết khi khởi động vùng chứa ProxySQL. Do đó, lệnh run sẽ là:
$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
severalnines/proxysql:2.0Cuối cùng, thay đổi cơ sở dữ liệu Wordpress trỏ đến cổng vùng chứa ProxySQL 6033, ví dụ:
$ docker run -d \
--name wordpress \
--publish 80:80 \
--restart=unless-stopped \
-e WORDPRESS_DB_HOST=proxysql2:6033 \
-e WORDPRESS_DB_USER=wordpress \
-e WORDPRESS_DB_HOST=passw0rd \
wordpressTại thời điểm này, kiến trúc của chúng tôi trông giống như sau:
Nếu bạn muốn vùng chứa ProxySQL ổn định, hãy ánh xạ / var / lib / proxysql / tới một ổ đĩa Docker hoặc gắn kết liên kết, ví dụ:
$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
-v proxysql-volume:/var/lib/proxysql \
severalnines/proxysql:2.0Hãy nhớ rằng chạy với bộ nhớ liên tục như trên sẽ làm cho /root/proxysql/proxysql.cnf của chúng tôi bị lỗi thời vào lần khởi động lại thứ hai. Điều này là do cấu hình nhiều lớp của ProxySQL, theo đó nếu /var/lib/proxysql/proxysql.db tồn tại, ProxySQL sẽ bỏ qua các tùy chọn tải từ tệp cấu hình và tải bất kỳ thứ gì có trong cơ sở dữ liệu SQLite (trừ khi bạn khởi động dịch vụ proxysql với --initial lá cờ). Phải nói rằng, quản lý cấu hình ProxySQL tiếp theo phải được thực hiện thông qua bảng điều khiển quản trị ProxySQL trên cổng 6032, thay vì sử dụng tệp cấu hình.
Giám sát
Nhật ký quy trình ProxySQL theo mặc định ghi vào nhật ký hệ thống và bạn có thể xem chúng bằng cách sử dụng lệnh docker tiêu chuẩn:
$ docker ps
$ docker logs proxysql2Để xác minh nhóm máy chủ hiện tại, hãy truy vấn bảng runtime_mysql_servers:
$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname | status |
+--------------+--------------+--------+
| 10 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.22 | ONLINE |
| 30 | 192.168.0.23 | ONLINE |
| 20 | 192.168.0.22 | ONLINE |
| 20 | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+Nếu người viết đã chọn gặp sự cố, nó sẽ được chuyển sang offline_hostgroup (HID 9999):
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname | status |
+--------------+--------------+--------+
| 10 | 192.168.0.22 | ONLINE |
| 9999 | 192.168.0.21 | ONLINE |
| 30 | 192.168.0.22 | ONLINE |
| 30 | 192.168.0.23 | ONLINE |
| 20 | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+Những thay đổi cấu trúc liên kết trên có thể được minh họa trong sơ đồ sau:
Chúng tôi cũng đã bật giao diện người dùng thống kê web với admin-web_enabled =true. Để truy cập giao diện người dùng web, chỉ cần truy cập máy chủ Docker ở cổng 6080, ví dụ: http://192.168.0.200:8060 và bạn sẽ được nhắc với tên người dùng / mật khẩu bật lên. Nhập thông tin đăng nhập như được xác định trong admin-stats_credentials và bạn sẽ thấy trang sau:
Bằng cách theo dõi bảng tổng hợp kết nối MySQL, chúng ta có thể có được tổng quan về phân phối kết nối cho tất cả các nhóm máy chủ:
Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;
+-----------+--------------+--------+----------+-------------+---------+
| hostgroup | srv_host | status | ConnUsed | MaxConnUsed | Queries |
+-----------+--------------+--------+----------+-------------+---------+
| 20 | 192.168.0.23 | ONLINE | 5 | 24 | 11458 |
| 30 | 192.168.0.23 | ONLINE | 0 | 0 | 0 |
| 20 | 192.168.0.22 | ONLINE | 2 | 24 | 11485 |
| 30 | 192.168.0.22 | ONLINE | 0 | 0 | 0 |
| 10 | 192.168.0.21 | ONLINE | 32 | 32 | 9746 |
| 30 | 192.168.0.21 | ONLINE | 0 | 0 | 0 |
+-----------+--------------+--------+----------+-------------+---------+Kết quả ở trên cho thấy rằng nhóm máy chủ 30 không xử lý bất kỳ điều gì bởi vì các quy tắc truy vấn của chúng tôi không có nhóm máy chủ này được định cấu hình làm nhóm máy chủ đích.
Các thống kê liên quan đến các nút Galera có thể được xem trong bảng mysql_server_galera_log:
Admin> select * from mysql_server_galera_log order by time_start_us desc limit 3\G
*************************** 1. row ***************************
hostname: 192.168.0.23
port: 3306
time_start_us: 1552992553332489
success_time_us: 2045
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULL
*************************** 2. row ***************************
hostname: 192.168.0.22
port: 3306
time_start_us: 1552992553329653
success_time_us: 2799
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULL
*************************** 3. row ***************************
hostname: 192.168.0.21
port: 3306
time_start_us: 1552992553329013
success_time_us: 2715
primary_partition: YES
read_only: NO
wsrep_local_recv_queue: 0
wsrep_local_state: 4
wsrep_desync: NO
wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
error: NULLTập kết quả trả về trạng thái biến / trạng thái MySQL có liên quan cho mọi nút Galera cho một dấu thời gian cụ thể. Trong cấu hình này, chúng tôi đã định cấu hình kiểm tra tình trạng Galera để chạy 2 giây một lần (monitor_galera_healthcheck_interval =2000). Do đó, thời gian chuyển đổi dự phòng tối đa sẽ là khoảng 2 giây nếu thay đổi cấu trúc liên kết xảy ra với cụm.
Tài liệu tham khảo
- Hỗ trợ ProxySQL Native Galera
- HA và giải pháp phân cụm:ProxySQL như một bộ định tuyến thông minh cho Galera và Group Replication
- Hình ảnh ProxySQL Docker của Somenines
- Cách giám sát ProxySQL với Prometheus và ClusterControl
