Kết nối HAProxy và Kết nối MySQL - Điều bạn nên biết

Có một bộ cân bằng tải hoặc proxy ngược trước máy chủ MySQL hoặc MariaDB của bạn sẽ thêm một chút phức tạp vào thiết lập cơ sở dữ liệu của bạn, điều này có thể dẫn đến một số, mọi thứ hoạt động khác nhau. Về mặt lý thuyết, bộ cân bằng tải đặt trước máy chủ MySQL (ví dụ:HAProxy trước Cụm Galera) sẽ chỉ hoạt động như một trình quản lý kết nối và phân phối kết nối đến các máy chủ phụ trợ theo một số thuật toán cân bằng. Mặt khác, MySQL có cách riêng để quản lý các kết nối máy khách. Tốt nhất, chúng ta cần định cấu hình hai thành phần này cùng nhau để tránh các hành vi không mong muốn và thu hẹp bề mặt khắc phục sự cố khi gỡ lỗi các sự cố.

Nếu bạn có thiết lập như vậy, điều quan trọng là phải hiểu các thành phần này vì chúng có thể ảnh hưởng đến hiệu suất tổng thể của dịch vụ cơ sở dữ liệu của bạn. Trong bài đăng trên blog này, chúng ta sẽ đi sâu vào max_connections của MySQL và HAProxy maxconn các tùy chọn tương ứng. Lưu ý rằng thời gian chờ là một thông số quan trọng khác mà chúng ta nên biết, nhưng chúng ta sẽ đề cập đến vấn đề đó trong một bài đăng riêng.

Các kết nối tối đa của MySQL

Tài nguyên liên quan MySQL Load Balancing with HAProxy - Hướng dẫn phát lại và hỏi đáp trên web:cách triển khai và quản lý ProxySQL, HAProxy và MaxScale Webinar Replay &Slides:Cách xây dựng cơ sở hạ tầng cơ sở dữ liệu có thể mở rộng với MariaDB &HAProxy

Số lượng kết nối được phép tới máy chủ MySQL được kiểm soát bởi max_connections biến hệ thống. Giá trị mặc định là 151 (MySQL 5.7).

Để xác định một con số tốt cho max_connections , các công thức cơ bản là:

Ở đâu,

** Biến innodb_additional_mem_pool_size bị loại bỏ trong MySQL 5.7.4+. Nếu bạn đang chạy trong phiên bản cũ hơn, hãy tính đến biến này.

Và,

Bằng cách sử dụng các công thức trên, chúng tôi có thể tính toán max_connections phù hợp giá trị cho máy chủ MySQL cụ thể này. Để bắt đầu quá trình, hãy dừng tất cả các kết nối từ máy khách và khởi động lại máy chủ MySQL. Đảm bảo bạn chỉ có số lượng quy trình tối thiểu đang chạy tại thời điểm cụ thể đó. Bạn có thể sử dụng 'mysqladmin' hoặc 'SHOW PROCESSLIST' cho mục đích này:

$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id     | User | Host      | db   | Command | Time | State | Info             | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query   |    0 | NULL  | show processlist |    0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)

Từ kết quả ở trên, chúng ta có thể biết rằng chỉ có một người dùng được kết nối với máy chủ MySQL là máy chủ gốc. Sau đó, truy xuất RAM khả dụng (tính bằng MB) của máy chủ (xem trong cột 'khả dụng'):

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3778        1427         508         148        1842        1928
Swap:          2047           4        2043

Chỉ để biết thông tin, cột 'khả dụng' cung cấp ước tính về dung lượng bộ nhớ có sẵn để khởi động các ứng dụng mới mà không cần hoán đổi (chỉ khả dụng trong kernel 3.14+).

Sau đó, chỉ định bộ nhớ khả dụng, 1928 MB trong câu lệnh sau:

mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
|                      265 |
+--------------------------+

** Biến innodb_additional_mem_pool_size bị loại bỏ trong MySQL 5.7.4+. Nếu bạn đang chạy trong phiên bản cũ hơn, hãy tính đến biến này.

Từ ví dụ này, chúng ta có thể có tối đa 265 kết nối MySQL đồng thời tùy theo RAM khả dụng mà máy chủ có. Không có ý nghĩa gì khi định cấu hình một giá trị cao hơn giá trị đó. Sau đó, nối dòng sau vào bên trong tệp cấu hình MySQL, trong lệnh [mysqld]:

max_connections = 265

Khởi động lại dịch vụ MySQL để áp dụng thay đổi. Khi tổng số kết nối đồng thời đạt 265, bạn sẽ gặp lỗi "Quá nhiều kết nối" khi cố gắng kết nối với máy chủ mysqld. Điều này có nghĩa là tất cả các kết nối có sẵn đều được các ứng dụng khách khác sử dụng. MySQL thực sự cho phép max_connections +1 khách hàng để kết nối. Kết nối bổ sung được dành riêng cho các tài khoản có đặc quyền SUPER. Vì vậy, nếu gặp lỗi này, bạn nên cố gắng truy cập máy chủ với tư cách là người dùng root (hoặc bất kỳ người dùng SUPER nào khác) và xem danh sách xử lý để bắt đầu khắc phục sự cố.

Các kết nối tối đa của HAProxy

HAProxy có 3 loại kết nối tối đa (maxconn) - toàn cầu, mặc định / lắng nghe và máy chủ mặc định. Giả sử một phiên bản HAProxy được định cấu hình với hai trình nghe, một để nghe nhiều người viết trên cổng 3307 (các kết nối được phân phối đến tất cả các máy chủ MySQL phụ trợ) và một phiên bản khác là trình ghi đơn trên cổng 3308 (các kết nối được chuyển tiếp đến một máy chủ MySQL duy nhất):

global
    ...
    maxconn 2000 #[a]
    ...
defaults
    ...
    maxconn 3 #[b]
    ...
listen mysql_3307
    ...
    maxconn 8 #[c]
    balance leastconn
    default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check
    server db3 192.168.55.173 check
listen mysql_3308
    ...
    default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
    server db1 192.168.55.171 check
    server db2 192.168.55.172 check backup #[f]

Hãy xem ý nghĩa của một số dòng cấu hình:

global.maxconn [a]

Tổng số kết nối đồng thời được phép kết nối với phiên bản HAProxy này. Thông thường, giá trị này là giá trị cao nhất. Trong trường hợp này, HAProxy sẽ chấp nhận tối đa 2000 kết nối tại một thời điểm và phân phối chúng cho tất cả người nghe được xác định trong quy trình HAProxy hoặc worker (bạn có thể chạy nhiều quy trình HAProxy bằng cách sử dụng nbproc tùy chọn).

HAProxy sẽ ngừng chấp nhận kết nối khi đạt đến giới hạn này. Tham số "ulimit-n" được tự động điều chỉnh thành giá trị này. Vì các socket được coi là tương đương với các tệp từ góc độ hệ thống, giới hạn bộ mô tả tệp mặc định là khá nhỏ. Bạn có thể sẽ muốn tăng giới hạn mặc định bằng cách điều chỉnh hạt nhân cho các bộ mô tả tệp.

defaults.maxconn [b]

Mặc định giá trị kết nối tối đa cho tất cả người nghe. Sẽ không hợp lý nếu giá trị này cao hơn global.maxconn .

Nếu dòng "maxconn" bị thiếu dưới khổ thơ "nghe" ( nghe.maxconn ), người nghe sẽ tuân theo giá trị này. Trong trường hợp này, trình nghe mysql_3308 sẽ nhận được tối đa 3 kết nối cùng một lúc. Để an toàn, hãy đặt giá trị này bằng global.maxconn , chia cho số lượng người nghe. Tuy nhiên, nếu bạn muốn ưu tiên những người nghe khác có nhiều kết nối hơn, hãy sử dụng listening.maxconn thay vào đó.

nghe.maxconn [c]

Các kết nối tối đa được phép cho người nghe tương ứng. Trình nghe được ưu tiên hơn defaults.maxconn nếu được chỉ định. Sẽ không hợp lý nếu giá trị này cao hơn global.maxconn .

Để phân phối hợp lý các kết nối đến máy chủ phụ trợ như trong trường hợp trình nghe nhiều người viết (mysql_3307), hãy đặt giá trị này là hear.default-server.maxconn nhân với số lượng máy chủ phụ trợ. Trong ví dụ này, giá trị tốt hơn phải là 12 thay vì 8 [c]. Nếu chúng tôi chọn gắn bó với cấu hình này, db1 và db2 dự kiến sẽ nhận được tối đa 3 kết nối mỗi thứ, trong khi db3 sẽ nhận được tối đa 2 kết nối (do ít cân bằng con nhất), tổng cộng là 8 kết nối. Nó sẽ không đạt đến giới hạn như được chỉ định trong [d].

Đối với trình nghe một người viết (mysql_3308) nơi các kết nối phải được phân bổ cho một và chỉ một máy chủ phụ trợ tại một thời điểm, hãy đặt giá trị này bằng hoặc cao hơn hear.default-server.maxconn .

nghe.default-server.maxconn [d] [e]

Đây là số lượng kết nối tối đa mà mọi máy chủ phụ trợ có thể nhận tại một thời điểm. Sẽ không hợp lý nếu giá trị này cao hơn hear.maxconn hoặc defaults.maxconn . Giá trị này phải thấp hơn hoặc bằng max_connections của MySQL Biến đổi. Nếu không, bạn có nguy cơ cạn kiệt các kết nối đến máy chủ MySQL phụ trợ, đặc biệt khi các biến thời gian chờ của MySQL được định cấu hình thấp hơn thời gian chờ của HAProxy.

Trong ví dụ này, chúng tôi đã đặt mỗi máy chủ MySQL chỉ nhận được tối đa 4 kết nối tại một thời điểm cho các nút Galera nhiều người viết [d]. Trong khi nút Galera một người viết sẽ nhận được tối đa 3 kết nối tại một thời điểm, do giới hạn áp dụng từ [b]. Vì chúng tôi đã chỉ định "sao lưu" [f] cho nút khác, nút đang hoạt động sẽ cùng lúc nhận cả 3 kết nối được phân bổ cho trình nghe này.

Giải thích trên có thể được minh họa trong sơ đồ sau:

Để tổng hợp phân phối kết nối, db1 được mong đợi nhận được số lượng tối đa là 6 kết nối (3 từ 3307 + 3 từ 3308). Db2 sẽ nhận được 3 kết nối (trừ khi db1 bị hỏng, nơi nó sẽ có thêm 3) và db3 sẽ dính vào 2 kết nối bất kể thay đổi cấu trúc liên kết trong cụm.

Giám sát kết nối với ClusterControl

Với ClusterControl, bạn có thể giám sát việc sử dụng kết nối MySQL và HAProxy từ giao diện người dùng. Ảnh chụp màn hình sau cung cấp bản tóm tắt về trình cố vấn kết nối MySQL (ClusterControl -> Performance -> Advisors) nơi nó giám sát các kết nối MySQL hiện tại và đã từng được sử dụng cho mọi máy chủ trong cụm:

Đối với HAProxy, ClusterControl tích hợp với trang thống kê HAProxy để thu thập số liệu. Chúng được trình bày trong tab Nodes:

Từ ảnh chụp màn hình ở trên, chúng ta có thể biết rằng mỗi máy chủ phụ trợ trên trình nghe nhiều người viết nhận được tối đa 8 kết nối. 4 phiên đồng thời đang chạy. Các kết nối này được đánh dấu trong ô vuông màu đỏ trên cùng, trong khi trình nghe một người viết đang phân phát 2 kết nối và chuyển tiếp chúng tới một nút duy nhất tương ứng.

Kết luận

Định cấu hình các kết nối tối đa cho máy chủ HAProxy và MySQL là điều quan trọng để đảm bảo phân phối tải tốt cho các máy chủ cơ sở dữ liệu của chúng tôi và bảo vệ máy chủ MySQL khỏi quá tải hoặc cạn kiệt các kết nối của nó.