MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Làm cho các thành phần cơ sở dữ liệu của bạn khả dụng cao (HA) thông qua bộ cân bằng tải

Chọn cấu trúc liên kết HA của bạn

Có nhiều cách khác nhau để duy trì tính khả dụng cao với cơ sở dữ liệu. Bạn có thể sử dụng IP ảo (VRRP) để quản lý tính khả dụng của máy chủ, bạn có thể sử dụng trình quản lý tài nguyên như Zookeeper và Etcd để (lại) định cấu hình ứng dụng của mình hoặc sử dụng bộ cân bằng tải / proxy để phân phối khối lượng công việc trên tất cả các máy chủ có sẵn.

Các IP ảo cần một ứng dụng để quản lý chúng (MHA, Orchestrator), một số tập lệnh (Keepalived, Pacemaker / Corosync) hoặc một kỹ sư để xử lý lỗi theo cách thủ công và việc đưa ra quyết định trong quá trình này có thể trở nên phức tạp. Chuyển đổi dự phòng IP ảo là một quá trình đơn giản và dễ hiểu bằng cách xóa địa chỉ IP khỏi một máy chủ, gán nó cho một máy chủ khác và sử dụng arping để gửi phản hồi ARP vô cớ. Về lý thuyết, một IP ảo có thể được di chuyển trong một giây nhưng sẽ mất vài giây trước khi ứng dụng quản lý chuyển đổi dự phòng chắc chắn rằng máy chủ đã bị lỗi và hoạt động tương ứng. Trong thực tế, khoảng thời gian này sẽ nằm trong khoảng từ 10 đến 30 giây. Một hạn chế khác của IP ảo là một số nhà cung cấp đám mây không cho phép bạn quản lý các IP ảo của riêng mình hoặc chỉ định chúng. Ví dụ:Google không cho phép bạn làm điều đó trên các nút máy tính của họ.

Các nhà quản lý tài nguyên như Zookeeper và Etcd có thể giám sát cơ sở dữ liệu của bạn và (lại) cấu hình các ứng dụng của bạn khi máy chủ bị lỗi hoặc máy chủ được thăng cấp lên thành chủ. Nói chung đây là một ý tưởng hay nhưng việc thực hiện kiểm tra của bạn với Zookeeper và Etcd là một công việc phức tạp.

Bộ cân bằng tải hoặc proxy sẽ nằm giữa ứng dụng và máy chủ cơ sở dữ liệu và hoạt động minh bạch như thể máy khách sẽ kết nối trực tiếp với máy chủ cơ sở dữ liệu. Cũng giống như với IP ảo và trình quản lý tài nguyên, bộ cân bằng tải và proxy cũng cần giám sát các máy chủ và chuyển hướng lưu lượng truy cập nếu một máy chủ gặp sự cố. ClusterControl hỗ trợ hai proxy:HAProxy và ProxySQL và cả hai đều được hỗ trợ cho bản sao MySQL master-slave và cụm Galera. HAProxy và ProxySQL đều có các trường hợp sử dụng riêng, chúng tôi cũng sẽ mô tả chúng trong bài đăng này.

Tại sao bạn cần Cân bằng tải?

Về lý thuyết, bạn không cần một bộ cân bằng tải nhưng trong thực tế, bạn sẽ thích một bộ hơn. Chúng tôi sẽ giải thích lý do tại sao.

Nếu bạn đã thiết lập IP ảo, tất cả những gì bạn phải làm là trỏ ứng dụng của mình đến đúng địa chỉ IP (ảo) và mọi thứ phải kết nối tốt. Nhưng giả sử bạn đã thu nhỏ số lượng bản sao đã đọc, bạn có thể muốn cung cấp IP ảo cho mỗi bản sao đã đọc đó vì lý do bảo trì hoặc tính khả dụng. Đây có thể trở thành một nhóm rất lớn các IP ảo mà bạn phải quản lý. Nếu một trong những bản sao đã đọc đó bị lỗi, bạn cần gán lại IP ảo cho một máy chủ khác, nếu không ứng dụng của bạn sẽ kết nối với máy chủ bị hỏng hoặc trong trường hợp xấu nhất là máy chủ bị chậm với dữ liệu cũ. Do đó, giữ trạng thái nhân bản cho ứng dụng quản lý các IP ảo là cần thiết.

Ngoài ra, đối với Galera, có một thách thức tương tự:về lý thuyết, bạn có thể thêm bao nhiêu máy chủ tùy thích vào cấu hình ứng dụng của mình và chọn ngẫu nhiên một máy chủ. Vấn đề tương tự cũng phát sinh khi máy chủ này gặp sự cố:bạn có thể kết nối với máy chủ không khả dụng. Ngoài ra, việc sử dụng tất cả các máy chủ cho cả đọc và ghi cũng có thể gây ra hiện tượng khôi phục do khóa lạc quan trong Galera. Nếu hai kết nối cố gắng ghi vào cùng một hàng cùng một lúc, một trong số chúng sẽ nhận được một cuộn ngược lại. Trong trường hợp khối lượng công việc của bạn có các bản cập nhật đồng thời như vậy, bạn chỉ nên sử dụng một nút trong Galera để ghi vào. Do đó, bạn muốn một người quản lý theo dõi trạng thái bên trong của cụm cơ sở dữ liệu của bạn.

Cả HAProxy và ProxySQL sẽ cung cấp cho bạn chức năng giám sát các máy chủ cơ sở dữ liệu MySQL / MariaDB và giữ trạng thái của cụm của bạn và cấu trúc liên kết của nó. Đối với thiết lập sao chép, trong trường hợp một bản sao nô lệ bị lỗi, cả HAProxy và ProxySQL đều có thể phân phối lại các kết nối đến một máy chủ lưu trữ khác. Nhưng nếu một nhân bản chính bị lỗi, HAProxy sẽ từ chối kết nối và ProxySQL sẽ trả lại một lỗi thích hợp cho máy khách. Đối với thiết lập Galera, cả hai bộ cân bằng tải đều có thể chọn một nút chính từ cụm Galera và chỉ gửi các hoạt động ghi tới nút cụ thể đó.

Nhìn bề ngoài thì HAProxy và ProxySQL có vẻ là các giải pháp tương tự nhau, nhưng chúng khác nhau rất nhiều về các tính năng và cách chúng phân phối các kết nối và truy vấn. HAProxy hỗ trợ một số thuật toán cân bằng như ít kết nối nhất, nguồn, ngẫu nhiên và round-robin trong khi ProxySQL phân phối các kết nối bằng cách sử dụng thuật toán round-robin dựa trên trọng số (trọng số bằng nhau có nghĩa là phân phối bằng nhau). Vì ProxySQL là một proxy thông minh, nó nhận biết được cơ sở dữ liệu và cũng có thể phân tích các truy vấn của bạn. ProxySQL có thể thực hiện phân tách đọc / ghi dựa trên các quy tắc truy vấn, nơi bạn có thể chuyển tiếp các truy vấn đến các nô lệ hoặc chủ được chỉ định trong cụm của bạn. ProxySQL bao gồm các chức năng bổ sung như ghi lại truy vấn, bộ nhớ đệm và tường lửa truy vấn với tạo thống kê chuyên sâu, thời gian thực về khối lượng công việc.

Đó phải là đủ thông tin cơ bản về chủ đề này, vì vậy hãy xem cách bạn có thể triển khai cả hai trình cân bằng tải cho bản sao MySQL và cấu trúc liên kết Galera.

Triển khai HAProxy

Sử dụng ClusterControl để triển khai HAProxy trên một cụm Galera thật dễ dàng:chuyển đến cụm liên quan và chọn “Thêm Load Balancer”:

Và bạn sẽ có thể triển khai một phiên bản HAProxy bằng cách thêm địa chỉ máy chủ và chọn các phiên bản máy chủ mà bạn muốn đưa vào cấu hình:

Theo mặc định, phiên bản HAProxy sẽ được định cấu hình để gửi kết nối đến các phiên bản máy chủ nhận ít kết nối nhất, nhưng bạn có thể thay đổi chính sách đó thành vòng lặp hoặc nguồn.

Trong cài đặt nâng cao, bạn có thể đặt thời gian chờ, số lượng kết nối tối đa và thậm chí bảo mật proxy bằng cách đưa dải IP vào danh sách trắng cho các kết nối.

Trong tab nút của cụm đó, nút HAProxy sẽ xuất hiện:

Giờ đây, cụm Galera của bạn cũng có sẵn thông qua nút HAProxy mới được triển khai trên cổng 3307. Đừng quên CẤP quyền truy cập ứng dụng của bạn từ IP HAProxy, vì bây giờ lưu lượng truy cập sẽ đến từ proxy thay vì máy chủ ứng dụng. Ngoài ra, hãy nhớ trỏ kết nối ứng dụng của bạn tới nút HAProxy.

Bây giờ, giả sử phiên bản một máy chủ gặp sự cố, HAProxy sẽ nhận thấy điều này trong vòng vài giây và ngừng gửi lưu lượng đến phiên bản này:

Hai nút khác vẫn ổn và sẽ tiếp tục nhận được lưu lượng truy cập. Điều này giữ cho cụm có tính khả dụng cao mà khách hàng thậm chí không nhận thấy sự khác biệt.

Triển khai nút HAProxy phụ

Bây giờ chúng tôi đã chuyển trách nhiệm duy trì tính khả dụng cao trên các kết nối cơ sở dữ liệu từ máy khách sang HAProxy, điều gì sẽ xảy ra nếu nút proxy chết? Câu trả lời là tạo một phiên bản HAProxy khác và sử dụng một IP ảo do Keepalived kiểm soát như được hiển thị trong sơ đồ này:

Lợi ích so với việc sử dụng IP ảo trên các nút cơ sở dữ liệu là logic cho MySQL ở cấp proxy và chuyển đổi dự phòng cho proxy rất đơn giản.

Vì vậy, hãy triển khai một nút HAProxy phụ:

Sau khi chúng tôi đã triển khai một nút HAProxy phụ, chúng tôi cần thêm Keepalived:

Và sau khi Keepalived được thêm vào, tổng quan về các nút của bạn sẽ trông như thế này:

Vì vậy, bây giờ thay vì trỏ trực tiếp các kết nối ứng dụng của bạn tới nút HAProxy, bạn phải trỏ chúng tới IP ảo.

Trong ví dụ ở đây, chúng tôi đã sử dụng các máy chủ riêng biệt để chạy HAProxy, nhưng bạn cũng có thể dễ dàng thêm chúng vào các phiên bản máy chủ hiện có. HAProxy không mang lại nhiều chi phí, mặc dù bạn nên nhớ rằng trong trường hợp máy chủ bị lỗi, bạn sẽ mất cả nút cơ sở dữ liệu và proxy.

Triển khai ProxySQL

Triển khai ProxySQL cho cụm của bạn được thực hiện theo cách tương tự như HAProxy:"Thêm Load Balancer" trong danh sách cụm bên dưới tab ProxySQL.

Trong trình hướng dẫn triển khai, chỉ định nơi ProxySQL sẽ được cài đặt, người dùng / mật khẩu quản trị, người dùng / mật khẩu giám sát để kết nối với phần phụ trợ MySQL. Từ ClusterControl, bạn có thể tạo người dùng mới để ứng dụng sử dụng (người dùng sẽ được tạo trên cả MySQL và ProxySQL) hoặc sử dụng người dùng cơ sở dữ liệu hiện có (người dùng sẽ chỉ được tạo trên ProxySQL). Đặt xem bạn có đang sử dụng các giao dịch ngầm hay không. Về cơ bản, nếu bạn không sử dụng SET autocommit =0 để tạo giao dịch mới, ClusterControl sẽ định cấu hình phân tách đọc / ghi.

Sau khi ProxySQL đã được triển khai, nó sẽ có sẵn trong tab Nút:

Mở tổng quan về nút ProxySQL sẽ giới thiệu cho bạn giao diện quản lý và giám sát ProxySQL, vì vậy không có lý do gì để đăng nhập vào ProxySQL trên nút nữa. ClusterControl bao gồm hầu hết các thống kê quan trọng của ProxySQL như sử dụng bộ nhớ, bộ đệm truy vấn, bộ xử lý truy vấn, v.v., cũng như các số liệu khác như nhóm máy chủ, máy chủ phụ trợ, lần truy cập quy tắc truy vấn, truy vấn hàng đầu và các biến ProxySQL. Trong khía cạnh quản lý ProxySQL, bạn có thể quản lý các quy tắc truy vấn, máy chủ phụ trợ, người dùng, cấu hình và bộ lập lịch ngay từ giao diện người dùng.

Hãy xem trang hướng dẫn ProxySQL của chúng tôi bao gồm nhiều cách để thực hiện Cân bằng tải cơ sở dữ liệu cho MySQL và MariaDB với ProxySQL.

Triển khai Garbd

Galera triển khai một thuật toán dựa trên túc số để chọn một thành phần chính mà qua đó nó thực thi tính nhất quán. Thành phần chính cần phải có đa số phiếu bầu (50% + 1 nút), vì vậy trong hệ thống 2 nút, sẽ không có đa số dẫn đến não bị chia rẽ. May mắn thay, có thể thêm một garbd (Galera Arbitrator Daemon), là một daemon không trạng thái nhẹ có thể hoạt động như một nút lẻ. Lợi ích bổ sung khi thêm Galera Arbitrator là giờ đây bạn có thể thực hiện chỉ với hai nút trong cụm của mình.

Nếu ClusterControl phát hiện thấy cụm Galera của bạn bao gồm một số nút chẵn, bạn sẽ được ClusterControl đưa ra cảnh báo / lời khuyên để mở rộng cụm thành một số nút lẻ:

Chọn một cách khôn ngoan máy chủ để triển khai garbd, vì nó sẽ nhận tất cả dữ liệu được sao chép. Đảm bảo rằng mạng có thể xử lý lưu lượng truy cập và đủ an toàn. Bạn có thể chọn một trong các máy chủ HAProxy hoặc ProxySQL để triển khai garbd, như trong ví dụ bên dưới:

Lưu ý rằng bắt đầu từ ClusterControl 1.5.1, không thể cài đặt garbd trên cùng một máy chủ lưu trữ như ClusterControl do nguy cơ xung đột gói.

Sau khi cài đặt garbd, bạn sẽ thấy nó xuất hiện bên cạnh hai nút Galera của bạn:

Lời kết

Chúng tôi đã chỉ cho bạn cách thiết lập cụm chủ MySQL và Galera của bạn mạnh mẽ hơn và duy trì tính khả dụng cao bằng cách sử dụng HAProxy và ProxySQL. Ngoài ra garbd là một daemon đẹp có thể lưu thêm nút thứ ba trong cụm Galera của bạn.

Điều này hoàn thiện mặt triển khai của ClusterControl. Trong blog tiếp theo của chúng tôi, chúng tôi sẽ chỉ cho bạn cách tích hợp ClusterControl trong tổ chức của bạn bằng cách sử dụng các nhóm và chỉ định một số vai trò nhất định cho người dùng.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách thiết lập sao chép MariaDB 10.3 bằng Ansible và Vagrant

  2. Giám sát hiệu quả quá trình nhân rộng MySQL với bảng điều khiển SCUMM:Phần 2

  3. Cảm ơn bạn, Amazon, đã truyền cảm hứng cho chúng tôi để cung cấp một DBaaS tốt hơn:SkySQL

  4. Chạy ProxySQL dưới dạng Vùng chứa trợ giúp trên Kubernetes

  5. Chuẩn bị máy chủ MySQL hoặc MariaDB để sản xuất - Phần thứ hai