Mọi doanh nghiệp có lãi đều đòi hỏi tính sẵn sàng cao. Trang web và blog cũng không khác gì vì các công ty và cá nhân thậm chí còn nhỏ hơn yêu cầu trang web của họ phải hoạt động để giữ danh tiếng của họ.
WordPress cho đến nay, là CMS phổ biến nhất trên thế giới cung cấp năng lượng cho hàng triệu trang web từ nhỏ đến lớn. Nhưng làm thế nào bạn có thể đảm bảo rằng trang web của bạn vẫn hoạt động. Cụ thể hơn, làm cách nào để đảm bảo việc cơ sở dữ liệu không có sẵn sẽ không ảnh hưởng đến trang web của tôi?
Trong bài đăng trên blog này, chúng tôi sẽ hướng dẫn cách thực hiện chuyển đổi dự phòng cho trang web WordPress của bạn bằng cách sử dụng ClusterControl.
Thiết lập mà chúng tôi sẽ sử dụng cho blog này sẽ sử dụng Máy chủ Percona 5.7. Chúng ta sẽ có một máy chủ khác chứa ứng dụng Apache và Wordpress. Chúng tôi sẽ không chạm vào phần ứng dụng có tính khả dụng cao, nhưng đây cũng là điều bạn muốn đảm bảo có. Chúng tôi sẽ sử dụng ClusterControl để quản lý cơ sở dữ liệu nhằm đảm bảo tính khả dụng và chúng tôi sẽ sử dụng máy chủ lưu trữ thứ ba để cài đặt và thiết lập chính ClusterControl.
Giả sử rằng ClusterControl đang hoạt động, chúng ta cần nhập cơ sở dữ liệu hiện có của mình vào đó.
Nhập Cụm cơ sở dữ liệu với ClusterControl
Đi tới tùy chọn Nhập Máy chủ / Cơ sở dữ liệu Hiện có trong trình hướng dẫn triển khai.
Chúng tôi phải định cấu hình kết nối SSH vì đây là yêu cầu để ClusterControl có thể quản lý các nút.
Bây giờ chúng ta phải xác định một số chi tiết về nhà cung cấp, phiên bản, người dùng root quyền truy cập, chính nút và nếu chúng tôi muốn ClusterControl quản lý tự động khôi phục cho chúng tôi hay không. Đó là tất cả, khi công việc thành công, bạn sẽ được hiển thị với một nhóm trong danh sách.
Để thiết lập môi trường khả dụng cao, chúng ta cần thực thi một số của các hành động. Môi trường của chúng ta sẽ bao gồm ...
- Cặp Master - Slave
- Hai phiên bản ProxySQL để phân tách đọc / ghi và phát hiện cấu trúc liên kết
- Hai phiên bản Keepalived để quản lý IP ảo
Ý tưởng rất đơn giản - chúng tôi sẽ triển khai nô lệ cho chủ nhân của chúng tôi, vì vậy chúng tôi sẽ có một phiên bản thứ hai để chuyển đổi dự phòng nếu chủ sở hữu không thành công. ClusterControl sẽ chịu trách nhiệm phát hiện lỗi và nó sẽ thúc đẩy nô lệ nếu cái chủ không khả dụng. ProxySQL sẽ theo dõi cấu trúc liên kết sao chép và nó sẽ chuyển hướng lưu lượng truy cập đến đúng nút - các lần ghi sẽ được gửi đến nút chính, bất kể nút đó ở trong nút nào, các lần đọc có thể được gửi đến chỉ chủ hoặc được phân phối trên chủ và nô lệ . Cuối cùng, Keepalived sẽ được kết hợp với ProxySQL và nó sẽ cung cấp VIP cho ứng dụng để kết nối. VIP đó sẽ luôn được chỉ định cho một trong các phiên bản ProxySQL và Keepalived sẽ chuyển nó sang phiên bản thứ hai, nếu nút ProxySQL “chính” bị lỗi.
Đã nói tất cả những điều đó, hãy cấu hình điều này bằng cách sử dụng ClusterControl. Tất cả điều đó có thể được thực hiện chỉ trong một vài cú nhấp chuột. Chúng tôi sẽ bắt đầu với việc thêm nô lệ.
Thêm Nô lệ cơ sở dữ liệu với ClusterControl
Chúng tôi bắt đầu với việc chọn công việc “Thêm mô hình nhân bản”. Sau đó, chúng tôi được yêu cầu điền vào biểu mẫu:
Chúng tôi phải chọn trang cái (trong trường hợp của chúng tôi, chúng tôi thực sự không có nhiều tùy chọn), chúng tôi phải chuyển IP hoặc tên máy chủ cho nô lệ mới. Nếu chúng tôi đã tạo các bản sao lưu trước đó, chúng tôi có thể sử dụng một trong số chúng để cung cấp cho nô lệ. Trong trường hợp của chúng tôi, điều này không khả dụng và ClusterControl sẽ cung cấp nô lệ trực tiếp từ chủ. Đó là tất cả, công việc bắt đầu và ClusterControl thực hiện các hành động cần thiết. Bạn có thể theo dõi tiến trình trong tab Hoạt động.
Cuối cùng, khi công việc hoàn thành thành công, nô lệ sẽ hiển thị trên danh sách cụm.
Bây giờ chúng ta sẽ tiến hành cấu hình các phiên bản ProxySQL. Trong trường hợp của chúng tôi, môi trường là tối thiểu, để giữ cho mọi thứ đơn giản hơn, chúng tôi sẽ định vị ProxySQL trên một trong các nút cơ sở dữ liệu. Tuy nhiên, đây không phải là lựa chọn tốt nhất trong môi trường sản xuất thực tế. Lý tưởng nhất, ProxySQL sẽ được đặt trên một nút riêng biệt hoặc được đặt chung với các máy chủ ứng dụng khác.
Nơi bắt đầu công việc là Quản lý -> Loadbalancers.
Tại đây bạn phải chọn nơi ProxySQL sẽ được cài đặt, chuyển thông tin đăng nhập quản trị và thêm một người dùng cơ sở dữ liệu. Trong trường hợp của chúng tôi, chúng tôi sẽ sử dụng người dùng hiện tại của mình vì ứng dụng WordPress của chúng tôi đã sử dụng nó để kết nối với cơ sở dữ liệu. Sau đó, chúng tôi phải chọn các nút nào sẽ sử dụng trong ProxySQL (chúng tôi muốn cả chủ và nô lệ ở đây) và cho ClusterControl biết liệu chúng tôi có sử dụng các giao dịch rõ ràng hay không. Điều này không thực sự phù hợp trong trường hợp của chúng tôi, vì chúng tôi sẽ cấu hình lại ProxySQL sau khi nó được triển khai. Khi bạn bật tùy chọn đó, tính năng phân chia đọc / ghi sẽ không được bật. Nếu không thì ClusterControl sẽ cấu hình ProxySQL để phân chia đọc / ghi. Trong thiết lập tối thiểu của chúng tôi, chúng tôi nên suy nghĩ nghiêm túc nếu chúng tôi muốn phân tách đọc / ghi xảy ra. Hãy phân tích điều đó.
Ưu điểm &Nhược điểm của Đọc / Ghi Spit trong ProxySQL
Ưu điểm chính của việc sử dụng phân tách đọc / ghi là tất cả lưu lượng SELECT sẽ được phân phối giữa chủ và phụ. Điều này có nghĩa là tải trên các nút sẽ thấp hơn và thời gian phản hồi cũng sẽ thấp hơn. Điều này nghe có vẻ hay nhưng hãy nhớ rằng nếu một nút bị lỗi, nút kia sẽ phải có khả năng đáp ứng tất cả lưu lượng truy cập. Có rất ít điểm trong việc thực hiện chuyển đổi dự phòng tự động nếu việc mất một nút có nghĩa là nút thứ hai sẽ bị quá tải và trên thực tế, cũng không khả dụng.
Có thể hợp lý khi phân phối tải nếu bạn có nhiều nô lệ - việc mất một trong số năm nút sẽ ít ảnh hưởng hơn việc mất một trong hai. Bất kể bạn quyết định điều gì, bạn có thể dễ dàng thay đổi hành vi bằng cách đi tới nút ProxySQL và nhấp vào tab Quy tắc.
Đảm bảo xem quy tắc 200 (quy tắc bắt tất cả các câu lệnh SELECT ). Trên ảnh chụp màn hình bên dưới, bạn có thể thấy rằng nhóm máy chủ đích là 20, có nghĩa là tất cả các nút trong cụm - phân chia đọc / ghi và chia tỷ lệ được bật. Chúng tôi có thể dễ dàng vô hiệu hóa điều này bằng cách chỉnh sửa quy tắc này và thay đổi Nhóm máy chủ đích thành 10 (nhóm chứa cái chính).
Nếu bạn muốn bật phân tách đọc / ghi, bạn có thể dễ dàng làm như vậy bằng cách chỉnh sửa lại quy tắc truy vấn này và đặt nhóm máy chủ đích trở lại 20.
Bây giờ, hãy triển khai ProxySQL thứ hai.
Để tránh chuyển lại tất cả các tùy chọn cấu hình, chúng ta có thể sử dụng "Nhập cấu hình ”Và chọn ProxySQL hiện có của chúng tôi làm nguồn.
Khi công việc này hoàn thành, chúng ta vẫn phải thực hiện bước cuối cùng trong việc thiết lập môi trường của mình. Chúng tôi phải triển khai Keepalived trên các phiên bản ProxySQL.
Triển khai Keepalived trên Bản sao ProxySQL
Ở đây chúng tôi đã chọn ProxySQL làm loại cân bằng tải, đã chuyển cả hai phiên bản ProxySQL cho Keepalived để được cài đặt trên và chúng tôi đã nhập VIP và giao diện mạng của mình.
Như bạn có thể thấy, hiện tại chúng tôi đã thiết lập toàn bộ và sẵn sàng. Chúng tôi có VIP là 10.0.0.111 được chỉ định cho một trong các phiên bản ProxySQL. Các phiên bản ProxySQL sẽ chuyển hướng lưu lượng truy cập của chúng tôi đến các nút MySQL phụ trợ chính xác và ClusterControl sẽ theo dõi môi trường thực hiện chuyển đổi dự phòng nếu cần. Thao tác cuối cùng chúng ta phải làm là cấu hình lại Wordpress để sử dụng IP ảo kết nối với cơ sở dữ liệu.
Để làm điều đó, chúng ta phải chỉnh sửa wp-config.php và thay đổi biến DB_HOST thành Virtual IP:
/** MySQL hostname */
define( 'DB_HOST', '10.0.0.111' );Kết luận
Từ bây giờ Wordpress sẽ kết nối với cơ sở dữ liệu bằng VIP và ProxySQL. Trong trường hợp nút chính bị lỗi, ClusterControl sẽ thực hiện chuyển đổi dự phòng.
Như bạn có thể thấy, chủ mới đã được chọn và ProxySQL cũng hướng tới chủ mới trong nhóm máy chủ 10.
Chúng tôi hy vọng bài đăng trên blog này cung cấp cho bạn một số ý tưởng về cách thiết kế môi trường cơ sở dữ liệu có tính khả dụng cao cho trang web Wordpress và cách ClusterControl có thể được sử dụng để triển khai tất cả các phần tử của nó.
