HAProxy và ProxySQL đều là những trình cân bằng tải rất phổ biến trong thế giới MySQL, nhưng có một sự khác biệt đáng kể giữa cả hai proxy đó. Chúng tôi sẽ không đi vào chi tiết ở đây, bạn có thể đọc thêm về HAProxy trong HAProxy Tutorial và ProxySQL trong ProxySQL Tutorial. Sự khác biệt quan trọng nhất là ProxySQL là proxy nhận biết SQL, nó phân tích cú pháp lưu lượng và hiểu giao thức MySQL và như vậy, nó có thể được sử dụng để định hình lưu lượng nâng cao - bạn có thể chặn các truy vấn, viết lại chúng, hướng chúng đến các máy chủ cụ thể, bộ nhớ cache chúng và nhiều hơn nữa. Mặt khác, HAProxy là một proxy lớp 4 rất đơn giản nhưng hiệu quả và tất cả những gì nó làm là gửi các gói đến phần phụ trợ. ProxySQL có thể được sử dụng để thực hiện phân tách đọc-ghi - nó hiểu SQL và nó có thể được cấu hình để phát hiện xem một truy vấn có phải là CHỌN hay không và định tuyến chúng cho phù hợp:CHỌN đến tất cả các nút, chỉ truy vấn khác để làm chủ. Tính năng này không khả dụng trong HAProxy, tính năng này phải sử dụng hai cổng riêng biệt và hai phần phụ trợ riêng biệt cho chính và nô lệ - việc phân chia đọc-ghi phải được thực hiện ở phía ứng dụng.
Tại sao chuyển sang ProxySQL?
Dựa trên những khác biệt mà chúng tôi đã giải thích ở trên, chúng tôi sẽ nói rằng lý do chính tại sao bạn có thể muốn chuyển từ HAProxy sang ProxySQL là do thiếu phân tách đọc-ghi trong HAProxy. Nếu bạn sử dụng một cụm cơ sở dữ liệu MySQL và không thực sự quan trọng nếu đó là bản sao không đồng bộ hay Cụm Galera, bạn có thể muốn có thể tách các lần đọc khỏi các lần ghi. Đối với bản sao MySQL, rõ ràng, đây sẽ là cách duy nhất để sử dụng cụm cơ sở dữ liệu của bạn vì các bản ghi luôn phải được gửi đến máy chủ. Do đó, nếu bạn không thể thực hiện phân tách đọc-ghi, bạn chỉ có thể gửi các truy vấn đến cái chính mà thôi. Đối với Galera, việc đọc-ghi không phải là điều bắt buộc nhưng chắc chắn là điều tốt nên có. Chắc chắn, bạn có thể định cấu hình tất cả các nút Galera dưới dạng một phụ trợ trong HAProxy và gửi lưu lượng truy cập đến tất cả chúng theo kiểu vòng lặp nhưng điều này có thể dẫn đến việc ghi từ nhiều nút xung đột với nhau, dẫn đến bế tắc và giảm hiệu suất. Chúng tôi cũng đã thấy các vấn đề và lỗi trong cụm Galera, cho đến khi chúng được khắc phục, giải pháp thay thế là hướng tất cả các lần ghi vào một nút duy nhất. Do đó, cách tốt nhất là gửi tất cả các lần ghi tới một nút Galera vì điều này dẫn đến hành vi ổn định hơn và hiệu suất tốt hơn.
Một lý do rất tốt khác cho việc di chuyển sang ProxySQL là cần phải kiểm soát tốt hơn lưu lượng truy cập. Với HAProxy, bạn không thể làm bất cứ điều gì - nó chỉ gửi lưu lượng truy cập đến các phần phụ trợ của nó. Với ProxySQL, bạn có thể định hình lưu lượng truy cập của mình bằng cách sử dụng các quy tắc truy vấn (đối sánh lưu lượng truy cập bằng cách sử dụng biểu thức chính quy, người dùng, lược đồ, máy chủ lưu trữ nguồn và nhiều hơn nữa). Bạn có thể chuyển hướng các OLAP SELECT tới phân tích nô lệ (nó đúng cho cả bản sao và Galera). Bạn có thể giảm tải chủ của mình bằng cách chuyển hướng một số CHỌN khỏi nó. Bạn có thể triển khai tường lửa SQL. Bạn có thể thêm độ trễ cho một số truy vấn, bạn có thể hủy truy vấn nếu chúng mất nhiều hơn thời gian xác định trước. Bạn có thể viết lại các truy vấn để thêm các gợi ý về trình tối ưu hóa. Tất cả những điều đó không thể thực hiện được với HAProxy.
Làm cách nào để chuyển từ HAProxy sang ProxySQL?
Đầu tiên, hãy xem xét cấu trúc liên kết sau ...
Cấu trúc liên kết ClusterControl MySQL 
Cụm sao chép MySQL trong ClusterControl Ở đây chúng ta có một cụm sao chép bao gồm một chủ và hai nô lệ. Chúng tôi có hai nút HAProxy được triển khai, mỗi nút sử dụng hai phần phụ trợ - trên cổng 3307 cho chính (ghi) và 3308 cho tất cả các nút (đọc). Keepalived được sử dụng để cung cấp IP ảo cho hai trường hợp HAProxy đó - nếu một trong số chúng bị lỗi, một bản khác sẽ được sử dụng. Ứng dụng của chúng tôi kết nối trực tiếp với VIP, thông qua nó với một trong các phiên bản HAProxy. Giả sử ứng dụng của chúng tôi (chúng tôi sẽ sử dụng Sysbench) không thể thực hiện phân tách đọc-ghi, do đó chúng tôi phải kết nối với phần phụ trợ “nhà văn”. Do đó, phần lớn tải là trên chính của chúng tôi (10.0.0.101).
Các bước chuyển sang ProxySQL sẽ như thế nào? Hãy suy nghĩ về điều đó một chút. Đầu tiên, chúng ta phải triển khai và cấu hình ProxySQL. Chúng tôi sẽ phải thêm máy chủ vào ProxySQL, tạo người dùng giám sát được yêu cầu và tạo quy tắc truy vấn thích hợp. Cuối cùng, chúng tôi sẽ phải triển khai Keepalived trên ProxySQL, tạo một IP ảo khác và sau đó đảm bảo chuyển đổi liền mạch nhất có thể cho ứng dụng của chúng tôi từ HAProxy sang ProxySQL.
Hãy xem cách chúng tôi có thể thực hiện điều đó ...
Cách cài đặt ProxySQL
Người ta có thể cài đặt ProxySQL theo nhiều cách. Bạn có thể sử dụng kho lưu trữ, từ chính ProxySQL (https://repo.proxysql.com) hoặc nếu bạn tình cờ sử dụng Percona XtraDB Cluster, bạn cũng có thể cài đặt ProxySQL từ kho lưu trữ Percona mặc dù nó có thể yêu cầu một số cấu hình bổ sung vì nó dựa trên CLI các công cụ quản trị được tạo cho PXC. Vì chúng ta đang nói về sao chép, việc sử dụng chúng có thể chỉ làm cho mọi thứ phức tạp hơn. Cuối cùng, bạn cũng có thể cài đặt các tệp nhị phân ProxySQL sau khi tải xuống từ ProxySQL GitHub. Hiện tại có hai phiên bản ổn định là 1.4.x và 2.0.x. Có sự khác biệt giữa ProxySQL 1.4 và ProxySQL 2.0 về các tính năng, đối với blog này, chúng tôi sẽ gắn bó với nhánh 1.4.x, vì nó được thử nghiệm tốt hơn và bộ tính năng là đủ cho chúng tôi.
Chúng tôi sẽ sử dụng kho lưu trữ ProxySQL và chúng tôi sẽ triển khai ProxySQL trên hai nút bổ sung:10.0.0.103 và 10.0.0.104.
Đầu tiên, chúng tôi sẽ cài đặt ProxySQL bằng cách sử dụng kho lưu trữ chính thức. Chúng tôi cũng sẽ đảm bảo rằng máy khách MySQL đã được cài đặt (chúng tôi sẽ sử dụng nó để cấu hình ProxySQL). Xin lưu ý rằng quá trình chúng tôi trải qua không phải ở cấp độ sản xuất. Đối với sản xuất, bạn sẽ muốn ít nhất thay đổi thông tin đăng nhập mặc định cho người dùng quản trị. Bạn cũng sẽ muốn xem lại cấu hình và đảm bảo nó phù hợp với mong đợi và yêu cầu của bạn.
apt-get install -y lsb-release
wget -O - 'https://repo.proxysql.com/ProxySQL/repo_pub_key' | apt-key add -
echo deb https://repo.proxysql.com/ProxySQL/proxysql-1.4.x/$(lsb_release -sc)/ ./ | tee /etc/apt/sources.list.d/proxysql.list
apt-get -y update
apt-get -y install proxysql
service proxysql startBây giờ, vì ProxySQL đã được khởi động, chúng tôi sẽ sử dụng CLI để định cấu hình ProxySQL.
mysql -uadmin -padmin -P6032 -h127.0.0.1Đầu tiên, chúng tôi sẽ xác định máy chủ phụ trợ và nhóm máy chủ nhân rộng:
mysql> INSERT INTO mysql_servers (hostgroup_id, hostname) VALUES (10, '10.0.0.101'), (20, '10.0.0.102'), (20, '10.0.0.103');
Query OK, 3 rows affected (0.91 sec)mysql> INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (10, 20);
Query OK, 1 row affected (0.00 sec)Chúng tôi có ba máy chủ, chúng tôi cũng đã xác định rằng ProxySQL nên sử dụng nhóm máy chủ 10 cho chính (nút với read_only =0) và nhóm máy chủ 20 cho nô lệ (read_only =1).
Bước tiếp theo, chúng ta cần thêm người dùng giám sát trên các nút MySQL để ProxySQL có thể giám sát họ. Chúng tôi sẽ sử dụng mặc định, lý tưởng là bạn sẽ thay đổi thông tin đăng nhập trong ProxySQL.
mysql> SHOW VARIABLES LIKE 'mysql-monitor_username';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_username | monitor |
+------------------------+---------+
1 row in set (0.00 sec)mysql> SHOW VARIABLES LIKE 'mysql-monitor_password';
+------------------------+---------+
| Variable_name | Value |
+------------------------+---------+
| mysql-monitor_password | monitor |
+------------------------+---------+
1 row in set (0.00 sec)Vì vậy, chúng ta cần tạo ‘màn hình’ người dùng với mật khẩu ‘màn hình’. Để làm điều đó, chúng tôi sẽ cần thực thi quyền sau trên máy chủ MySQL chính:
mysql> create user [email protected]'%' identified by 'monitor';
Query OK, 0 rows affected (0.56 sec)Quay lại ProxySQL - chúng tôi phải định cấu hình người dùng mà ứng dụng của chúng tôi sẽ sử dụng để truy cập MySQL và các quy tắc truy vấn, nhằm cung cấp cho chúng tôi sự phân tách đọc-ghi.
mysql> INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('sbtest', 'sbtest', 10);
Query OK, 1 row affected (0.34 sec)mysql> INSERT INTO mysql_query_rules (rule_id,active,match_digest,destination_hostgroup,apply) VALUES (100, 1, '^SELECT.*FOR UPDATE$',10,1), (200,1,'^SELECT',20,1), (300,1,'.*',10,1);
Query OK, 3 rows affected (0.01 sec)Xin lưu ý rằng chúng tôi đã sử dụng mật khẩu ở dạng văn bản thuần túy và chúng tôi sẽ dựa vào ProxySQL để băm nó. Vì lợi ích bảo mật, bạn nên chuyển mã băm mật khẩu MySQL vào đây một cách rõ ràng.
Cuối cùng, chúng tôi cần áp dụng tất cả các thay đổi.
mysql> LOAD MYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.02 sec)mysql> LOAD MYSQL USERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> LOAD MYSQL QUERY RULES TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE MYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.07 sec)mysql> SAVE MYSQL QUERY RULES TO DISK;
Query OK, 0 rows affected (0.02 sec)Chúng tôi cũng muốn tải mật khẩu đã băm từ thời gian chạy:mật khẩu văn bản thuần túy được băm khi được tải vào cấu hình thời gian chạy, để giữ nó được băm trên đĩa, chúng tôi cần tải nó từ thời gian chạy và sau đó lưu trữ trên đĩa:
mysql> SAVE MYSQL USERS FROM RUNTIME;
Query OK, 0 rows affected (0.00 sec)mysql> SAVE MYSQL USERS TO DISK;
Query OK, 0 rows affected (0.02 sec)Đây là nó khi nói đến ProxySQL. Trước khi thực hiện các bước tiếp theo, bạn nên kiểm tra xem bạn có thể kết nối với proxy từ máy chủ ứng dụng của mình hay không.
[email protected]:~# mysql -h 10.0.0.103 -usbtest -psbtest -P6033 -e "SELECT * FROM sbtest.sbtest4 LIMIT 1\G"
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
id: 1
k: 50147
c: 68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441
pad: 22195207048-70116052123-74140395089-76317954521-98694025897Trong trường hợp của chúng tôi, mọi thứ có vẻ tốt. Bây giờ đã đến lúc cài đặt Keepalived.
Cài đặt đủ điều kiện
Cài đặt khá đơn giản (ít nhất là trên Ubuntu 16.04, mà chúng tôi đã sử dụng):
apt install keepalivedSau đó, bạn phải tạo tệp cấu hình cho cả hai máy chủ:
Nút lưu giữ chính:
vrrp_script chk_haproxy {
script "killall -0 haproxy" # verify the pid existance
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
interface eth1 # interface to monitor
state MASTER
virtual_router_id 52 # Assign one ID for this route
priority 101
unicast_src_ip 10.0.0.103
unicast_peer {
10.0.0.104
}
virtual_ipaddress {
10.0.0.112 # the virtual IP
}
track_script {
chk_haproxy
}
# notify /usr/local/bin/notify_keepalived.sh
}Sao lưu nút keepalived:
vrrp_script chk_haproxy {
script "killall -0 haproxy" # verify the pid existance
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
interface eth1 # interface to monitor
state MASTER
virtual_router_id 52 # Assign one ID for this route
priority 100
unicast_src_ip 10.0.0.103
unicast_peer {
10.0.0.104
}
virtual_ipaddress {
10.0.0.112 # the virtual IP
}
track_script {
chk_haproxy
}
# notify /usr/local/bin/notify_keepalived.shVậy là xong, bạn có thể bắt đầu được giữ nguyên trên cả hai nút:
service keepalived startBạn sẽ thấy thông tin trong nhật ký rằng một trong các nút đã vào trạng thái MASTER và VIP đã được đưa lên trên nút đó.
May 7 09:52:11 vagrant systemd[1]: Starting Keepalive Daemon (LVS and VRRP)...
May 7 09:52:11 vagrant Keepalived[26686]: Starting Keepalived v1.2.24 (08/06,2018)
May 7 09:52:11 vagrant Keepalived[26686]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived[26696]: Starting Healthcheck child process, pid=26697
May 7 09:52:11 vagrant Keepalived[26696]: Starting VRRP child process, pid=26698
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Initializing ipvs
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering Kernel netlink reflector
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering Kernel netlink command channel
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Registering gratuitous ARP shared channel
May 7 09:52:11 vagrant systemd[1]: Started Keepalive Daemon (LVS and VRRP).
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Unable to load ipset library
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Unable to initialise ipsets
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: Using LinkWatch kernel netlink reflector...
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Registering Kernel netlink reflector
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Registering Kernel netlink command channel
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Opening file '/etc/keepalived/keepalived.conf'.
May 7 09:52:11 vagrant Keepalived_healthcheckers[26697]: Using LinkWatch kernel netlink reflector...
May 7 09:52:11 vagrant Keepalived_vrrp[26698]: pid 26701 exited with status 256
May 7 09:52:12 vagrant Keepalived_vrrp[26698]: VRRP_Instance(VI_HAPROXY) Transition to MASTER STATE
May 7 09:52:13 vagrant Keepalived_vrrp[26698]: pid 26763 exited with status 256
May 7 09:52:13 vagrant Keepalived_vrrp[26698]: VRRP_Instance(VI_HAPROXY) Entering MASTER STATE
May 7 09:52:15 vagrant Keepalived_vrrp[26698]: pid 26806 exited with status 256[email protected]:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:ee:87:c4 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:feee:87c4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:fc:ac:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.103/24 brd 10.0.0.255 scope global eth1
valid_lft forever preferred_lft forever
inet 10.0.0.112/32 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fefc:ac21/64 scope link
valid_lft forever preferred_lft foreverNhư bạn có thể thấy, trên nút 10.0.0.103, một VIP (10.0.0.112) đã được nâng lên. Bây giờ chúng ta có thể kết thúc việc chuyển lưu lượng truy cập từ thiết lập cũ sang thiết lập mới.
Chuyển lưu lượng sang thiết lập ProxySQL
Có nhiều phương pháp về cách thực hiện, nó chủ yếu phụ thuộc vào môi trường cụ thể của bạn. Nếu bạn tình cờ sử dụng DNS để duy trì một miền trỏ tới VIP HAProxy của mình, bạn chỉ có thể thực hiện thay đổi ở đó và dần dần, theo thời gian, tất cả các kết nối sẽ chỉ định lại cho VIP mới. Bạn cũng có thể thực hiện thay đổi trong ứng dụng của mình, đặc biệt nếu chi tiết kết nối được mã hóa cứng - khi bạn triển khai thay đổi, các nút sẽ bắt đầu kết nối với thiết lập mới. Bất kể bạn làm theo cách nào, sẽ rất tốt nếu bạn kiểm tra thiết lập mới trước khi bạn thực hiện chuyển đổi toàn cầu. Bạn chắc chắn đã thử nghiệm nó trên môi trường dàn dựng của mình nhưng không phải là ý kiến tồi nếu chọn một số ít máy chủ ứng dụng và chuyển hướng chúng đến proxy mới, theo dõi xem chúng trông như thế nào về hiệu suất. Dưới đây là một ví dụ đơn giản sử dụng iptables, có thể hữu ích cho việc kiểm tra.
Trên máy chủ ProxySQL, chuyển hướng lưu lượng truy cập từ máy chủ 10.0.0.11 và cổng 3307 sang máy chủ 10.0.0.112 và cổng 6033:
iptables -t nat -A OUTPUT -p tcp -d 10.0.0.111 --dport 3307 -j DNAT --to-destination 10.0.0.112:6033Tùy thuộc vào ứng dụng của bạn, bạn có thể cần khởi động lại máy chủ web hoặc các dịch vụ khác (nếu ứng dụng của bạn tạo một nhóm kết nối liên tục đến cơ sở dữ liệu) hoặc chỉ cần đợi khi các kết nối mới sẽ được mở trên ProxySQL. Bạn có thể xác minh rằng ProxySQL đang nhận được lưu lượng truy cập:
mysql> show processlist;
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+
| SessionID | user | db | hostgroup | command | time_ms | info |
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+
| 12 | sbtest | sbtest | 20 | Sleep | 0 | |
| 13 | sbtest | sbtest | 10 | Query | 0 | DELETE FROM sbtest23 WHERE id=49957 |
| 14 | sbtest | sbtest | 10 | Query | 59 | DELETE FROM sbtest11 WHERE id=50185 |
| 15 | sbtest | sbtest | 20 | Query | 59 | SELECT c FROM sbtest8 WHERE id=46054 |
| 16 | sbtest | sbtest | 20 | Query | 0 | SELECT DISTINCT c FROM sbtest27 WHERE id BETWEEN 50115 AND 50214 ORDER BY c |
| 17 | sbtest | sbtest | 10 | Query | 0 | DELETE FROM sbtest32 WHERE id=50084 |
| 18 | sbtest | sbtest | 10 | Query | 26 | DELETE FROM sbtest28 WHERE id=34611 |
| 19 | sbtest | sbtest | 10 | Query | 16 | DELETE FROM sbtest4 WHERE id=50151 |
+-----------+--------+--------+-----------+---------+---------+-----------------------------------------------------------------------------+Vậy là xong, chúng tôi đã chuyển lưu lượng từ HAProxy sang thiết lập ProxySQL. Phải mất một số bước nhưng nó chắc chắn có thể thực hiện được với sự gián đoạn rất nhỏ đối với dịch vụ.
Làm cách nào để chuyển từ HAProxy sang ProxySQL bằng ClusterControl?
Trong phần trước, chúng tôi đã giải thích cách triển khai thiết lập ProxySQL theo cách thủ công và sau đó di chuyển vào đó. Trong phần này, chúng tôi muốn giải thích cách thực hiện cùng một mục tiêu bằng cách sử dụng ClusterControl. Thiết lập ban đầu hoàn toàn giống nhau, do đó chúng tôi cần tiến hành triển khai ProxySQL.
Triển khai ProxySQL bằng ClusterControl
Việc triển khai ProxySQL trong ClusterControl chỉ là vấn đề của một vài cú nhấp chuột.
Triển khai ProxySQL trong ClusterControl Chúng tôi phải chọn IP hoặc tên máy chủ của một nút, chuyển thông tin đăng nhập cho người dùng quản trị CLI và người dùng giám sát MySQL. Chúng tôi quyết định sử dụng MySQL hiện có và chúng tôi đã chuyển thông tin chi tiết truy cập cho người dùng ‘sbtest’ @ ’%’ mà chúng tôi sử dụng trong ứng dụng. Chúng tôi đã chọn các nút mà chúng tôi muốn sử dụng trong bộ cân bằng tải, chúng tôi cũng tăng độ trễ sao chép tối đa (nếu vượt qua ngưỡng đó, ProxySQL sẽ không gửi lưu lượng đến nô lệ đó) từ 10 giây mặc định lên 100 vì chúng tôi đã phải chịu đựng sự sao chép lỗi. Sau một thời gian ngắn các nút ProxySQL sẽ được thêm vào cụm.
Triển khai Keepalived cho ProxySQL bằng ClusterControl
Khi các nút ProxySQL đã được thêm, đã đến lúc triển khai Keepalived.
Được bảo vệ bằng ProxySQL trong ClusterControl Tất cả những gì chúng tôi phải làm là chọn các nút ProxySQL mà chúng tôi muốn Keepalived triển khai, IP ảo và giao diện mà VIP sẽ bị ràng buộc. Khi quá trình triển khai hoàn tất, chúng tôi sẽ chuyển lưu lượng sang thiết lập mới bằng một trong các phương pháp được đề cập trong phần “Chuyển lưu lượng sang thiết lập ProxySQL” ở trên.
Giám sát lưu lượng truy cập ProxySQL trong ClusterControl Chúng tôi có thể xác minh rằng lưu lượng đã chuyển sang ProxySQL bằng cách nhìn vào biểu đồ tải - như bạn có thể thấy, tải được phân bổ nhiều hơn trên các nút trong cụm. Bạn cũng có thể thấy nó trên biểu đồ bên dưới, biểu đồ này hiển thị sự phân bổ truy vấn trên toàn bộ cụm.
Bảng điều khiển ProxySQL trong ClusterControl Cuối cùng, bảng điều khiển ProxySQL cũng cho thấy rằng lưu lượng được phân phối trên tất cả các nút trong cụm:
Bảng điều khiển ProxySQL trong ClusterControl Chúng tôi hy vọng bạn sẽ được hưởng lợi từ bài đăng blog này, như bạn có thể thấy, với việc ClusterControl triển khai kiến trúc mới chỉ mất một chút thời gian và chỉ cần một vài cú nhấp chuột để mọi thứ hoạt động. Hãy cho chúng tôi biết về trải nghiệm của bạn trong những lần di chuyển như vậy.
