Chuyển đổi dự phòng tự động là điều bắt buộc phải có đối với nhiều ứng dụng - thời gian hoạt động là điều hiển nhiên. Thật khó để chấp nhận rằng một ứng dụng ngừng hoạt động trong 20 hoặc 30 phút vì ai đó phải được phân trang để đăng nhập và điều tra tình hình trước khi thực hiện hành động.
Trong thế giới thực, các thiết lập sao chép có xu hướng phát triển theo thời gian để trở nên phức tạp, đôi khi lộn xộn. Và có những ràng buộc. Ví dụ:không phải mọi nút trong một thiết lập đều là một ứng cử viên chính tốt. Có thể phần cứng khác nhau và một số bản sao có phần cứng kém mạnh hơn vì chúng được dành riêng để xử lý một số loại khối lượng công việc cụ thể? Có thể bạn đang trong quá trình di chuyển sang phiên bản MySQL mới và một số nô lệ đã được nâng cấp? Bạn không muốn có một bản chính trong phiên bản gần đây hơn sao chép sang các bản sao cũ, vì điều này có thể phá vỡ bản sao. Nếu bạn có hai trung tâm dữ liệu, một đang hoạt động và một để khôi phục sau thảm họa, bạn có thể chỉ muốn chọn các ứng cử viên chính trong trung tâm dữ liệu đang hoạt động, để giữ cái chính gần với các máy chủ ứng dụng. Đó chỉ là những tình huống ví dụ, trong đó bạn có thể thấy mình cần can thiệp thủ công trong quá trình chuyển đổi dự phòng. May mắn thay, nhiều công cụ chuyển đổi dự phòng có tùy chọn để kiểm soát quá trình bằng cách sử dụng danh sách trắng và danh sách đen. Trong bài đăng blog này, chúng tôi muốn cho bạn thấy một số ví dụ về cách bạn có thể tác động đến thuật toán của ClusterControl để chọn các ứng cử viên chính.
Cấu hình danh sách trắng và danh sách đen
ClusterControl cung cấp cho bạn một tùy chọn để xác định cả danh sách trắng và danh sách đen của các bản sao. Danh sách trắng là danh sách các bản sao được dự định trở thành ứng cử viên chính. Nếu không có phương thức nào trong số chúng khả dụng (hoặc do chúng bị ngừng hoạt động, hoặc có các giao dịch sai sót, hoặc có các trở ngại khác ngăn cản việc quảng cáo bất kỳ phương thức nào trong số chúng), chuyển đổi dự phòng sẽ không được thực hiện. Bằng cách này, bạn có thể xác định máy chủ nào có sẵn để trở thành ứng cử viên chính. Mặt khác, danh sách đen xác định bản sao nào không phù hợp để trở thành ứng cử viên chính.
Cả hai danh sách đó đều có thể được xác định trong tệp cấu hình cmon cho một cụm nhất định. Ví dụ:nếu cụm của bạn có id là ‘1’, bạn muốn chỉnh sửa ‘/etc/cmon.d/cmon_1.cnf’. Đối với danh sách trắng, bạn sẽ sử dụng biến ‘replication_failover_whitelist’, đối với danh sách đen, nó sẽ là ‘replication_failover_blacklist’. Cả hai đều chấp nhận danh sách ‘host:port’ được phân tách bằng dấu phẩy.
Hãy xem xét thiết lập sao chép sau đây. Chúng tôi có một bản chính đang hoạt động (10.0.0.141) có hai bản sao (10.0.0.142 và 10.0.0.143), cả hai đều hoạt động như bản chính trung gian và mỗi bản có một bản sao (10.0.0.144 và 10.0.0.147). Chúng tôi cũng có một master dự phòng trong một trung tâm dữ liệu riêng biệt (10.0.0.145) có một bản sao (10.0.0.146). Những máy chủ này được thiết kế để sử dụng trong trường hợp xảy ra thảm họa. Bản sao 10.0.0.146 và 10.0.0.147 hoạt động như máy chủ lưu trữ dự phòng. Xem ảnh chụp màn hình bên dưới.
Do trung tâm dữ liệu thứ hai chỉ nhằm mục đích khôi phục sau thảm họa, chúng tôi không muốn bất kỳ máy chủ nào trong số đó được thăng cấp là máy chủ. Trong trường hợp xấu nhất, chúng tôi sẽ thực hiện các thao tác thủ công. Cơ sở hạ tầng của trung tâm dữ liệu thứ hai không được chia tỷ lệ với kích thước của trung tâm dữ liệu sản xuất (có ít hơn ba bản sao trong trung tâm dữ liệu DR), vì vậy, dù sao thì cũng cần phải thực hiện các thao tác thủ công trước khi chúng tôi có thể quảng bá máy chủ lưu trữ trong trung tâm dữ liệu DR. Chúng tôi cũng không muốn quảng cáo một bản sao dự phòng (10.0.0.147). Chúng tôi đều không muốn bản sao thứ ba trong chuỗi được chọn làm bản chính (mặc dù nó có thể được thực hiện với GTID).
Cấu hình danh sách trắng
Chúng tôi có thể cấu hình danh sách trắng hoặc danh sách đen để đảm bảo rằng chuyển đổi dự phòng sẽ được xử lý theo ý muốn của chúng tôi. Trong thiết lập cụ thể này, sử dụng danh sách trắng có thể phù hợp hơn - chúng tôi sẽ xác định máy chủ nào có thể được sử dụng để chuyển đổi dự phòng và nếu ai đó thêm máy chủ mới vào thiết lập, máy chủ đó sẽ không được coi là ứng cử viên chính cho đến khi ai đó sẽ quyết định theo cách thủ công được sử dụng nó và thêm nó vào danh sách trắng. Nếu chúng tôi sử dụng danh sách đen, việc thêm một bản sao mới ở đâu đó trong chuỗi có thể có nghĩa là bản sao đó về mặt lý thuyết có thể được tự động sử dụng để chuyển đổi dự phòng trừ khi ai đó nói rõ ràng rằng nó không thể được sử dụng. Hãy ở bên an toàn và xác định danh sách trắng trong tệp cấu hình cụm của chúng tôi (trong trường hợp này là /etc/cmon.d/cmon_1.cnf vì chúng ta chỉ có một cụm):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Chúng tôi phải đảm bảo rằng quá trình cmon đã được khởi động lại để áp dụng các thay đổi:
service cmon restartGiả sử rằng thiết bị của chúng ta đã gặp sự cố và không thể liên lạc được với ClusterControl. Một công việc chuyển đổi dự phòng sẽ được bắt đầu:
Cấu trúc liên kết sẽ giống như bên dưới:
Như bạn có thể thấy, bản gốc cũ đã bị vô hiệu hóa và ClusterControl sẽ không cố gắng tự động khôi phục nó. Người dùng tùy thuộc vào việc kiểm tra điều gì đã xảy ra, sao chép bất kỳ dữ liệu nào có thể chưa được sao chép sang ứng cử viên chính và xây dựng lại dữ liệu chính cũ:
Sau đó, đó là vấn đề của một vài thay đổi về cấu trúc liên kết và chúng tôi có thể đưa cấu trúc liên kết về trạng thái ban đầu, chỉ cần thay thế 10.0.0.141 bằng 10.0.0.142:
Cấu hình danh sách cấm
Bây giờ chúng ta sẽ xem danh sách đen hoạt động như thế nào. Chúng tôi đã đề cập rằng, trong ví dụ của chúng tôi, nó có thể không phải là lựa chọn tốt nhất nhưng chúng tôi sẽ thử nó để minh họa. Chúng tôi sẽ đưa vào danh sách đen mọi máy chủ ngoại trừ 10.0.0.141, 10.0.0.142 và 10.0.0.143 vì đó là những máy chủ mà chúng tôi muốn xem là ứng cử viên chính.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Chúng tôi cũng sẽ khởi động lại quá trình cmon để áp dụng các thay đổi cấu hình:
service cmon restartQuá trình chuyển đổi dự phòng cũng tương tự. Một lần nữa, khi sự cố chính được phát hiện, ClusterControl sẽ bắt đầu công việc chuyển đổi dự phòng.
Khi một bản sao có thể không phải là ứng cử viên chính tốt
Trong phần ngắn này, chúng tôi muốn thảo luận chi tiết hơn về một số trường hợp mà bạn có thể không muốn quảng bá một bản sao đã cho để trở thành một bản sao mới. Hy vọng rằng điều này sẽ cung cấp cho bạn một số ý tưởng về các trường hợp mà bạn có thể cần phải xem xét đến việc kiểm soát thủ công hơn quy trình chuyển đổi dự phòng.
Phiên bản MySQL khác nhau
Đầu tiên, nếu bản sao của bạn sử dụng phiên bản MySQL khác với bản chính, thì bạn không nên quảng bá nó. Nói chung, phiên bản mới hơn luôn là điều không nên vì sao chép từ phiên bản MySQL mới sang phiên bản cũ không được hỗ trợ và có thể không hoạt động chính xác. Điều này hầu hết liên quan đến các phiên bản chính (ví dụ:8.0 sao chép thành 5.7) nhưng cách tốt là tránh hoàn toàn thiết lập này, ngay cả khi chúng ta đang nói về sự khác biệt nhỏ của phiên bản (5.7.x + 1 -> 5.7.x). Việc sao chép từ phiên bản thấp hơn lên cao hơn / mới hơn được hỗ trợ vì đây là điều bắt buộc đối với quá trình nâng cấp, tuy nhiên, bạn vẫn muốn tránh điều này (ví dụ:nếu phiên bản chính của bạn là 5.7.x + 1, bạn không muốn thay thế nó với bản sao trên 5.7.x).
Các vai trò khác nhau
Bạn có thể chỉ định các vai trò khác nhau cho các bản sao của mình. Bạn có thể chọn một trong số chúng có sẵn để các nhà phát triển kiểm tra các truy vấn của họ trên tập dữ liệu sản xuất. Bạn có thể sử dụng một trong số chúng cho khối lượng công việc OLAP. Bạn có thể sử dụng một trong số chúng để sao lưu. Bất kể nó là gì, thông thường bạn sẽ không muốn quảng bá bản sao như vậy để làm chủ. Tất cả các khối lượng công việc bổ sung, không theo tiêu chuẩn đó có thể gây ra các vấn đề về hiệu suất do chi phí bổ sung. Một lựa chọn tốt cho ứng cử viên chính là một bản sao đang xử lý tải “bình thường”, nhiều hơn hoặc ít hơn cùng loại tải với bản chính hiện tại. Sau đó, bạn có thể chắc chắn rằng nó sẽ xử lý tải chính sau khi chuyển đổi dự phòng nếu nó đã xử lý nó trước đó.
Các thông số kỹ thuật phần cứng khác nhau
Chúng tôi đã đề cập đến các vai trò khác nhau cho các bản sao. Không có gì lạ khi thấy các thông số kỹ thuật phần cứng khác nhau, đặc biệt là khi kết hợp với các vai trò khác nhau. Ví dụ:một nô lệ dự phòng rất có thể không cần phải mạnh mẽ như một bản sao thông thường. Các nhà phát triển cũng có thể kiểm tra các truy vấn của họ trên cơ sở dữ liệu chậm hơn so với sản xuất (chủ yếu là vì bạn sẽ không mong đợi cùng một mức độ đồng thời trên cơ sở dữ liệu phát triển và sản xuất) và ví dụ:số lượng lõi CPU có thể giảm xuống. Các thiết lập khôi phục sau thảm họa cũng có thể bị giảm kích thước nếu vai trò chính của chúng là theo kịp bản sao và dự kiến rằng thiết lập DR sẽ phải được mở rộng (cả theo chiều dọc, bằng cách tăng kích thước bản sao và theo chiều ngang, bằng cách thêm nhiều bản sao hơn) trước khi lưu lượng truy cập có thể được chuyển hướng đến nó.
Bản sao bị trì hoãn
Một số bản sao có thể bị trì hoãn - đó là một cách rất tốt để giảm thời gian khôi phục nếu dữ liệu bị mất, nhưng nó khiến chúng trở thành ứng cử viên chính rất tệ. Nếu một bản sao bị trì hoãn 30 phút, bạn sẽ mất 30 phút giao dịch đó hoặc bạn sẽ phải đợi (có lẽ không phải 30 phút vì rất có thể, bản sao có thể bắt kịp nhanh hơn) để bản sao áp dụng tất cả các giao dịch bị trì hoãn. ClusterControl cho phép bạn chọn nếu bạn muốn đợi hoặc nếu bạn muốn chuyển đổi dự phòng ngay lập tức, nhưng điều này sẽ hoạt động tốt với độ trễ rất nhỏ - tối đa là hàng chục giây. Nếu quá trình chuyển đổi dự phòng được cho là mất vài phút, thì việc sử dụng một bản sao như vậy cũng chẳng ích lợi gì và do đó bạn nên đưa vào danh sách đen.
Trung tâm dữ liệu khác nhau
Chúng tôi đã đề cập đến thiết lập DR thu nhỏ nhưng ngay cả khi trung tâm dữ liệu thứ hai của bạn được thu nhỏ theo quy mô sản xuất, thì vẫn có thể là một ý tưởng hay nếu chỉ giữ các dự phòng trong một DC duy nhất. Đối với người mới bắt đầu, các máy chủ ứng dụng đang hoạt động của bạn có thể được đặt trong trung tâm dữ liệu chính, do đó việc di chuyển máy chủ sang DC dự phòng sẽ làm tăng đáng kể độ trễ cho các truy vấn ghi. Ngoài ra, trong trường hợp bị tách mạng, bạn có thể muốn xử lý tình huống này theo cách thủ công. MySQL không có cơ chế túc số được tích hợp sẵn, do đó rất khó để xử lý chính xác (theo cách tự động) việc mất mạng giữa hai trung tâm dữ liệu.
