ProxySQL là một trong những proxy tốt nhất hiện có cho MySQL. Nó giới thiệu rất nhiều tùy chọn cho quản trị viên cơ sở dữ liệu. Nó có thể định hình lưu lượng cơ sở dữ liệu bằng cách trì hoãn, lưu vào bộ nhớ đệm hoặc viết lại các truy vấn một cách nhanh chóng. Nó cũng có thể được sử dụng để tạo ra một môi trường trong đó chuyển đổi dự phòng sẽ không ảnh hưởng đến các ứng dụng và sẽ minh bạch đối với chúng. Chúng tôi đã đề cập đến các tính năng ProxySQL quan trọng nhất trong các bài đăng trên blog trước:
- Cách sử dụng ClusterControl và ProxySQL cho các truy vấn bộ nhớ đệm
- Cách xây dựng tường lửa SQL với ClusterControl và ProxySQL
- Cách triển khai một cụm ProxySQL
- Cách dễ dàng triển khai môi trường nhân bản MySQL với ProxySQL để có tính khả dụng cao
Chúng tôi thậm chí còn có một hướng dẫn về ProxySQL cho thấy cách nó có thể được sử dụng trong các thiết lập MySQL và MariaDB.
Gần đây, ProxySQL 2.0.3 đã được phát hành, là một bản vá cho dòng 2.0. Các lỗi đang được khắc phục và dòng 2.0 dường như bắt đầu nhận được lực kéo mà nó xứng đáng. Trong bài đăng blog này, chúng tôi muốn thảo luận về những thay đổi lớn được giới thiệu trong ProxySQL 2.0.
Đọc nguyên nhân bằng GTID
Tất cả những ai từng phải đối phó với độ trễ sao chép và vật lộn với các tình huống đọc-sau-ghi bị ảnh hưởng bởi độ trễ sao chép chắc chắn sẽ rất hài lòng với tính năng này. Cho đến nay, trong môi trường sao chép MySQL, cách duy nhất để đảm bảo đọc nhân quả là đọc từ bản chính (và không thành vấn đề nếu bạn sử dụng sao chép không đồng bộ hay bán đồng bộ). Một tùy chọn khác là sử dụng Galera, có một tùy chọn để thực thi các lần đọc nhân quả, giống như, luôn luôn (trước đây nó từng là wsrep-causal-read và bây giờ là wsrep-sync-wait). Gần đây (trong 8.0.14) bản sao MySQL Group có tính năng tương tự. Tuy nhiên, sao chép thường xuyên không thể giải quyết vấn đề này. May mắn thay, ProxySQL ở đây và nó mang lại cho chúng tôi một tùy chọn để xác định trên cơ sở quy tắc cho mỗi truy vấn với những gì nhóm máy chủ đọc phù hợp với quy tắc truy vấn đó phải nhất quán. Việc triển khai đi kèm với trình đọc binlog ProxySQL và nó có thể hoạt động với định dạng binlog ROW cho MySQL 5.7 và mới hơn. Chỉ Oracle MySQL được hỗ trợ do thiếu chức năng cần thiết trong MariaDB. Tính năng này và các chi tiết kỹ thuật của nó đã được giải thích trên blog chính thức của ProxySQL.
SSL cho kết nối giao diện người dùng
ProxySQL luôn có hỗ trợ cho kết nối SSL phụ trợ nhưng nó thiếu mã hóa SSL cho các kết nối đến từ các máy khách. Đây không phải là vấn đề lớn do mô hình triển khai được đề xuất là sắp xếp ProxySQL trên các nút ứng dụng và sử dụng ổ cắm Unix an toàn để kết nối từ ứng dụng đến proxy. Đây vẫn là một khuyến nghị, đặc biệt nếu bạn sử dụng ProxySQL cho các truy vấn bộ nhớ đệm (các ổ cắm Unix nhanh hơn kết nối TCP, ngay cả các ổ cắm cục bộ và với bộ đệm ẩn thì rất tốt để tránh gây ra độ trễ không cần thiết). Điều tốt là với ProxySQL 2.0 hiện có sự lựa chọn vì nó đã giới thiệu hỗ trợ SSL cho các kết nối đến. Bạn có thể dễ dàng kích hoạt nó bằng cách đặt mysql-have_ssl thành ‘true’. Việc kích hoạt SSL không đi kèm với tác động không thể chấp nhận được về hiệu suất. Ngược lại, theo kết quả từ blog ProxySQL chính thức, hiệu suất giảm rất thấp.
Hỗ trợ riêng cho Cụm Galera
Galera Cluster đã được hỗ trợ bởi ProxySQL gần như ngay từ đầu nhưng cho đến nay nó đã được thực hiện thông qua tập lệnh bên ngoài (thường) được gọi từ bộ lập lịch nội bộ của ProxySQL. Tùy thuộc vào kịch bản để đảm bảo rằng cấu hình ProxySQL phù hợp, người viết (hoặc người viết) đã được phát hiện và định cấu hình chính xác trong nhóm máy chủ người viết. Tập lệnh có thể phát hiện các trạng thái khác nhau mà nút Galera có thể có (Chính, không phải Chính, Đã đồng bộ hóa, Nhà tài trợ / Bỏ đồng bộ, Tham gia, Đã tham gia) và đánh dấu nút tương ứng là có sẵn hoặc không. Vấn đề chính là kịch bản gốc không bao giờ được coi là bất cứ thứ gì khác ngoài bằng chứng về khái niệm được viết bằng Bash. Tuy nhiên, khi nó được phân phối cùng với ProxySQL, nó bắt đầu được cải tiến, sửa đổi bởi những người đóng góp bên ngoài. Những người khác (như Percona) đã xem xét việc tạo các tập lệnh của riêng họ, đi kèm với phần mềm của họ. Một số bản sửa lỗi đã được giới thiệu trong tập lệnh từ kho lưu trữ ProxySQL, một số bản sửa lỗi đã được đưa vào phiên bản Percona của tập lệnh. Điều này dẫn đến sự nhầm lẫn và mặc dù tất cả các tập lệnh thường được sử dụng xử lý 95% các trường hợp sử dụng, không có tập lệnh nào trong số các tập lệnh phổ biến thực sự bao gồm tất cả các tình huống khác nhau và các biến mà cụm Galera có thể sử dụng. May mắn thay, ProxySQL 2.0 đi kèm với hỗ trợ riêng cho Galera Cluster. Điều này làm cho ProxySQL hỗ trợ sao chép nội bộ MySQL, sao chép nhóm MySQL và bây giờ là Galera Cluster. Cách thức thực hiện rất giống nhau. Chúng tôi muốn đề cập đến cấu hình của tính năng này vì nó có thể không rõ ràng trong cái nhìn đầu tiên.
Như với bản sao MySQL và MySQL Group Replication, một bảng đã được tạo trong ProxySQL:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Có rất nhiều cài đặt để định cấu hình và chúng tôi sẽ xem xét từng cài đặt một. Trước hết, có bốn nhóm máy chủ:
- Writer_hostgroup - nó sẽ chứa tất cả những người viết (với read_only =0) cho đến cài đặt ‘max_writers’. Theo mặc định, nó chỉ có một người viết
- Backup_writer_hostgroup - nó chứa những người viết còn lại (read_only =0) còn lại sau khi ‘max_writers’ đã được thêm vào writer_hostgroup
- Reader_hostgroup - nó chứa các trình đọc (read_only =1), nó cũng có thể chứa các trình viết dự phòng, theo cài đặt ‘writer_is_also_reader’
- Offline_hostgroup - nó chứa các nút được coi là không thể sử dụng được (ngoại tuyến hoặc ở trạng thái khiến chúng không thể xử lý lưu lượng truy cập)
Sau đó, chúng tôi có các cài đặt còn lại:
- Đang hoạt động - mục nhập trong mysql_galera_hostgroups có đang hoạt động hay không
- Max_writers - có thể đặt tối đa bao nhiêu nút trong nhómriter_host
- Writer_is_also_reader - nếu được đặt thành 0, các nhà văn (read_only =0) sẽ không được đưa vào reader_hostgroup. Nếu được đặt thành 1, người viết (read_only =0) sẽ được đưa vào reader_hostgroup. Nếu được đặt thành 2, các nút từ backup_writer_hostgroup sẽ được đưa vào reader_hostgroup. Cái này hơi phức tạp nên chúng tôi sẽ trình bày một ví dụ sau trong bài đăng trên blog này
- Max_transactions_behind - dựa trên wsrep_local_recv_queue, hàng đợi tối đa có thể chấp nhận được. Nếu hàng đợi trên nút vượt quá max_transactions_behind, nút đã cho sẽ được đánh dấu là SHUNNED và nó sẽ không khả dụng cho lưu lượng truy cập
Điều ngạc nhiên chính có thể là việc xử lý trình đọc, khác với cách tập lệnh có trong ProxySQL hoạt động. Trước hết, điều bạn cần lưu ý là ProxySQL sử dụng read_only =1 để quyết định xem nút có phải là trình đọc hay không. Điều này là phổ biến trong thiết lập sao chép, không phổ biến trong Galera. Do đó, rất có thể, bạn sẽ muốn sử dụng cài đặt ‘writer_is_also_reader’ để định cấu hình cách người đọc sẽ được thêm vào reader_hostgroup. Hãy xem xét ba nút Galera, tất cả chúng đều có read_only =0. Chúng tôi cũng có max_writers =1 vì chúng tôi muốn hướng tất cả các lần ghi về một nút. Chúng tôi đã định cấu hình mysql_galera_hostgroups như sau:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Hãy xem qua tất cả các tùy chọn:
riter_is_also_reader =0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Kết quả này khác với những gì bạn sẽ thấy trong các tập lệnh - ở đó bạn sẽ có các nút còn lại được đánh dấu là trình đọc. Ở đây, do chúng tôi không muốn người viết là người đọc và do không có nút nào có read_only =1, nên sẽ không có người đọc nào được định cấu hình. Một người viết (theo max_writers), các nút còn lại trong backup_writer_hostgroup.
riter_is_also_reader =1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Ở đây, chúng tôi muốn người viết của mình đóng vai trò là người đọc, do đó tất cả chúng (hoạt động và sao lưu) sẽ được đưa vào reader_hostgroup.
riter_is_also_reader =2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Đây là cài đặt dành cho những người không muốn người viết đang hoạt động của họ xử lý các lần đọc. Trong trường hợp này, chỉ các nút từ backup_writer_hostgroup sẽ được sử dụng để đọc. Cũng xin lưu ý rằng số lượng người đọc sẽ thay đổi nếu bạn đặt max_writers thành một số giá trị khác. Nếu chúng tôi đặt nó thành 3, sẽ không có người viết dự phòng (tất cả các nút sẽ kết thúc trong nhóm máy chủ người viết), do đó, một lần nữa, sẽ không có nút nào trong nhóm máy chủ người đọc.
Tất nhiên, bạn sẽ muốn định cấu hình các quy tắc truy vấn phù hợp với cấu hình nhóm máy chủ. Chúng tôi sẽ không xem xét quá trình này ở đây, bạn có thể kiểm tra xem nó có thể được thực hiện như thế nào trong blog ProxySQL. Nếu bạn muốn kiểm tra cách nó hoạt động trong môi trường Docker, chúng tôi có một blog trình bày cách chạy cụm Galera và ProxySQL 2.0 trên Docker.
Các thay đổi khác
Những gì chúng tôi mô tả ở trên là những cải tiến đáng chú ý nhất trong ProxySQL 2.0. Có nhiều người khác, theo bảng thay đổi. Đáng nói là những cải tiến xung quanh bộ đệm truy vấn (ví dụ:bổ sung PROXYSQL FLUSH QUERY CACHE) và thay đổi cho phép ProxySQL dựa vào super_read_only để xác định chính và nô lệ trong thiết lập sao chép.
Chúng tôi hy vọng tổng quan ngắn về những thay đổi trong ProxySQL 2.0 này sẽ giúp bạn xác định phiên bản ProxySQL nào bạn nên sử dụng. Hãy nhớ rằng nhánh 1.4, ngay cả khi nó không nhận được bất kỳ tính năng mới nào, nó vẫn được duy trì.
