Tại CityMobil, chúng tôi sử dụng cơ sở dữ liệu MySQL làm nơi lưu trữ dữ liệu liên tục chính. Chúng tôi có một số cụm cơ sở dữ liệu cho các dịch vụ và mục đích khác nhau.

Tính khả dụng liên tục của bản gốc là một chỉ số quan trọng về hiệu suất của toàn bộ hệ thống và các bộ phận riêng lẻ của nó. Tự động khôi phục cụm trong trường hợp xảy ra lỗi chính giúp giảm đáng kể thời gian phản hồi sự cố và thời gian ngừng hoạt động của hệ thống. Trong bài viết này, tôi sẽ xem xét thiết kế có tính sẵn sàng cao (HA) cho cụm MySQL dựa trên Trình soạn thảo MySQL và địa chỉ IP ảo (VIP).

Giải pháp HA dựa trên VIP

Đầu tiên, tôi sẽ cho bạn biết ngắn gọn hệ thống lưu trữ dữ liệu của chúng tôi là gì.

Chúng tôi sử dụng sơ đồ sao chép cổ điển với một bản gốc có thể truy cập ghi và nhiều bản sao chỉ đọc. Một cụm có thể chứa một nút chính trung gian - một nút vừa là bản sao vừa là nút chính cho nút khác. Khách hàng truy cập các bản sao thông qua HAProxy, cho phép phân phối tải đồng đều và dễ dàng mở rộng quy mô. Việc sử dụng HAProxy là vì lý do lịch sử và chúng tôi hiện đang trong quá trình chuyển sang ProxySQL.

Việc sao chép được thực hiện ở chế độ bán đồng bộ dựa trên GTID. Điều này có nghĩa là ít nhất một bản sao phải ghi lại giao dịch trước khi nó được coi là thành công. Chế độ sao chép này cung cấp sự cân bằng tối ưu giữa hiệu suất và an toàn dữ liệu trong trường hợp nút chính bị lỗi. Về cơ bản tất cả các thay đổi được chuyển từ bản gốc sang bản sao bằng cách sử dụng Row Based Replication (RBR), nhưng một số nút có thể có mixed binlog format.

Bộ điều phối cập nhật định kỳ trạng thái của cấu trúc liên kết cụm, phân tích thông tin nhận được và nếu có vấn đề phát sinh, nó có thể khởi chạy quy trình khôi phục tự động. Nhà phát triển chịu trách nhiệm về chính quy trình này vì nó có thể được triển khai theo nhiều cách khác nhau: dựa trên VIP, DNS, sử dụng dịch vụ khám phá dịch vụ hoặc cơ chế tự viết.

Một cách đơn giản để khôi phục bản gốc nếu thất bại là sử dụng địa chỉ VIP nổi.

Những điều bạn cần biết về giải pháp này trước khi tiếp tục:

VIP là địa chỉ IP không được liên kết với giao diện mạng vật lý cụ thể. Nếu một nút bị lỗi hoặc trong quá trình bảo trì theo lịch trình, chúng tôi có thể chuyển VIP sang tài nguyên khác với thời gian ngừng hoạt động tối thiểu.
Giải phóng và cấp địa chỉ IP ảo là một hoạt động rẻ và nhanh chóng.
Để làm việc với VIP, bạn cần truy cập vào máy chủ thông qua SSH hoặc sử dụng các tiện ích đặc biệt, chẳng hạn như keepalived.

Hãy xem xét các vấn đề có thể xảy ra với trình hướng dẫn của chúng tôi và tưởng tượng cơ chế khôi phục tự động sẽ hoạt động như thế nào.

Kết nối mạng với máy chủ đã biến mất hoặc đã phát sinh sự cố ở cấp độ phần cứng và máy chủ không khả dụng

Bộ điều phối cập nhật cấu trúc liên kết cụm, mỗi bản sao báo cáo rằng bản gốc không khả dụng. Người điều phối bắt đầu quá trình chọn bản sao phù hợp với vai trò của người chủ mới và bắt đầu quá trình khôi phục.
Chúng tôi đang cố gắng loại bỏ VIP khỏi chủ cũ - nhưng không thành công.
Bản sao chuyển sang vai trò chủ. Cấu trúc liên kết đang được xây dựng lại.
Thêm giao diện mạng mới với VIP. Vì không thể xóa VIP nên chúng tôi bắt đầu gửi yêu cầu định kỳ ở chế độ nền ARP miễn phí. Loại yêu cầu/phản hồi này cho phép bạn cập nhật bảng ánh xạ địa chỉ IP và MAC trên các thiết bị chuyển mạch được kết nối, từ đó thông báo cho bạn rằng VIP của chúng tôi đã di chuyển. Điều này giảm thiểu khả năng split brain khi trả lại chủ cũ.
Tất cả các kết nối mới ngay lập tức được chuyển hướng đến chủ mới. Các kết nối cũ không thành công và các cuộc gọi lặp lại tới cơ sở dữ liệu được thực hiện ở cấp ứng dụng.

Máy chủ đang hoạt động ở chế độ bình thường, xảy ra lỗi ở cấp DBMS

Thuật toán tương tự như trường hợp trước: cập nhật cấu trúc liên kết và bắt đầu quá trình khôi phục. Vì máy chủ đã khả dụng nên chúng tôi đã giải phóng thành công VIP trên máy chủ cũ, chuyển nó sang máy chủ mới và gửi một số yêu cầu ARP. Sự trở lại có thể của chủ cũ sẽ không ảnh hưởng đến cụm được xây dựng lại và hoạt động của ứng dụng.

Các vấn đề khác

Lỗi của bản sao hoặc bản gốc trung gian không dẫn đến các hành động tự động và yêu cầu sự can thiệp thủ công.

Giao diện mạng ảo luôn được thêm tạm thời, nghĩa là sau khi khởi động lại máy chủ, VIP sẽ không được tự động gán. Theo mặc định, mỗi phiên bản cơ sở dữ liệu bắt đầu ở chế độ chỉ đọc, bộ điều phối sẽ tự động chuyển bản gốc mới sang chế độ ghi và cố gắng cài đặt read only về chủ cũ. Những hành động này nhằm mục đích giảm khả năng split brain.

Các vấn đề có thể phát sinh trong quá trình khôi phục, vấn đề này cũng cần được thông báo thông qua giao diện người dùng của người điều phối bên cạnh các công cụ giám sát tiêu chuẩn. Chúng tôi đã mở rộng API REST bằng cách thêm tính năng này (PR hiện đang được xem xét).

Sơ đồ chung của giải pháp HA được trình bày dưới đây.

Lựa chọn chủ nhân mới

Người điều phối đủ thông minh và cố gắng chọn bản sao phù hợp nhất với tư cách là chủ nhân mới theo các tiêu chí sau:

bản sao tụt lại phía sau bản gốc;
Phiên bản MySQL của bản gốc và bản sao;
kiểu sao chép (RBR, SBR hoặc hỗn hợp);
vị trí trong cùng trung tâm dữ liệu hoặc khác nhau;
sẵn sàng errant GTID — các giao dịch được thực hiện trên bản sao và không phải trên bản gốc;
quy tắc lựa chọn tùy chỉnh cũng được tính đến.

Không phải mọi gợi ý đều là ứng cử viên lý tưởng cho vị trí bậc thầy. Ví dụ: một bản sao có thể được sử dụng để sao lưu dữ liệu hoặc máy chủ có cấu hình phần cứng yếu hơn. Người soạn nhạc ủng hộ các quy tắc thủ công mà bạn có thể tùy chỉnh các tùy chọn lựa chọn ứng viên của mình từ ưu tiên nhất đến bị bỏ qua.

Thời gian đáp ứng và phục hồi

Trong trường hợp xảy ra sự cố, điều quan trọng là giảm thiểu thời gian ngừng hoạt động của hệ thống, vì vậy hãy xem xét các tham số MySQL ảnh hưởng đến việc tạo và cập nhật cấu trúc liên kết cụm của người điều phối:

slave_net_timeout — số giây trong đó bản sao chờ dữ liệu mới hoặc tín hiệu nhịp tim đến từ bản gốc trước khi kết nối được nhận dạng là bị mất và được kết nối lại. Giá trị càng thấp thì bản sao có thể xác định rằng giao tiếp với bản gốc bị hỏng càng nhanh. Chúng tôi đặt giá trị này thành 5 giây.
MASTER_CONNECT_RETRY - số giây giữa các lần thử kết nối lại. Trong trường hợp xảy ra sự cố mạng, giá trị thấp của tham số này sẽ cho phép kết nối lại nhanh chóng và ngăn quá trình khôi phục cụm bắt đầu. Giá trị được đề xuất là 1 giây.
MASTER_RETRY_COUNT - số lần thử kết nối lại tối đa.
MASTER_HEARTBEAT_PERIOD — khoảng thời gian tính bằng giây sau đó chủ gửi tín hiệu nhịp tim. Mặc định là một nửa giá trị slave_net_timeout.

Tùy chọn người soạn nhạc:

DelayMasterPromotionIfSQLThreadNotUpToDate - nếu bằng true, thì vai trò chính sẽ không được áp dụng trên bản sao ứng viên cho đến khi chuỗi SQL của bản sao hoàn thành tất cả các giao dịch chưa được áp dụng từ Nhật ký chuyển tiếp. Chúng tôi sử dụng tùy chọn này để tránh mất giao dịch khi tất cả các bản sao ứng cử viên bị tụt lại phía sau.
InstancePollSeconds - tần suất xây dựng và cập nhật cấu trúc liên kết.
RecoveryPollSeconds - tần suất phân tích cấu trúc liên kết. Nếu một vấn đề được phát hiện, quá trình phục hồi cấu trúc liên kết sẽ được bắt đầu. Cái này không thay đổi, bằng 1 giây.

Mỗi nút cụm được điều phối viên thăm dò một lần mỗi lần InstancePollSeconds giây Khi phát hiện sự cố, trạng thái cụm bị buộc cập nhật, và sau đó đưa ra quyết định cuối cùng về việc thực hiện khôi phục. Bằng cách thử nghiệm các tham số cơ sở dữ liệu và bộ điều phối khác nhau, chúng tôi có thể giảm thời gian phản hồi và khôi phục xuống còn 30 giây.

Kiểm tra đứng

Chúng tôi bắt đầu thử nghiệm kế hoạch HA với việc phát triển một chương trình địa phương băng ghế thử nghiệm và triển khai sâu hơn trong môi trường thử nghiệm và sản xuất. Giá đỡ cục bộ hoàn toàn tự động dựa trên Docker và cho phép bạn thử nghiệm cấu hình của bộ điều phối và mạng, mở rộng cụm từ 2-3 máy chủ lên vài chục máy chủ và thực hiện các bài tập trong môi trường an toàn.

Trong quá trình thực hiện, chúng tôi chọn một trong các phương pháp mô phỏng vấn đề: bắn ngay chủ nhân bằng cách sử dụng kill -9, nhẹ nhàng chấm dứt quá trình và dừng máy chủ (docker-compose stop), mô phỏng các sự cố mạng bằng cách sử dụng iptables -j REJECT hoặc iptables -j DROP. Chúng tôi mong đợi các kết quả sau:

người điều phối sẽ phát hiện các vấn đề với bản gốc và cập nhật cấu trúc liên kết trong không quá 10 giây;
quy trình khôi phục sẽ tự động bắt đầu: cấu hình mạng sẽ thay đổi, vai trò của máy chủ sẽ chuyển sang bản sao, cấu trúc liên kết sẽ được xây dựng lại;
bản gốc mới sẽ có thể ghi được, các bản sao trực tiếp sẽ không bị mất trong quá trình xây dựng lại;
dữ liệu sẽ bắt đầu được ghi vào bản gốc mới và được sao chép;
Tổng thời gian hồi phục sẽ không quá 30 giây.

Như bạn đã biết, hệ thống có thể hoạt động khác nhau trong môi trường thử nghiệm và sản xuất do cấu hình mạng và phần cứng khác nhau, sự khác biệt về tải tổng hợp và tải thực, v.v. Do đó, chúng tôi định kỳ tiến hành các bài tập trong điều kiện thực tế, kiểm tra cách hệ thống hoạt động khi mất kết nối mạng hoặc các bộ phận riêng lẻ của nó bị xuống cấp. Trong tương lai, chúng tôi muốn xây dựng cơ sở hạ tầng hoàn toàn giống nhau cho cả hai môi trường và tự động hóa quá trình thử nghiệm.

Những phát hiện

Tình trạng của nút hệ thống lưu trữ chính là một trong những nhiệm vụ chính của SRE và nhóm vận hành. Việc triển khai bộ điều phối và giải pháp HA dựa trên VIP cho phép chúng tôi đạt được những kết quả sau:

phát hiện đáng tin cậy các vấn đề với cấu trúc liên kết của cụm cơ sở dữ liệu;
phản ứng tự động và nhanh chóng đối với các sự cố liên quan đến chủ, giảm thời gian ngừng hoạt động của hệ thống.

Tuy nhiên, giải pháp có những hạn chế và nhược điểm:

mở rộng sơ đồ HA tới một số trung tâm dữ liệu sẽ yêu cầu một mạng L2 duy nhất giữa chúng;
Trước khi gán VIP cho chủ mới, chúng ta cần giải phóng VIP cho chủ cũ. Quá trình này diễn ra tuần tự, làm tăng thời gian phục hồi;
việc phát hành VIP yêu cầu quyền truy cập SSH vào máy chủ hoặc bất kỳ phương thức gọi thủ tục từ xa nào khác. Vì máy chủ hoặc cơ sở dữ liệu đang gặp sự cố gây ra quá trình khôi phục nên chúng tôi không thể chắc chắn rằng việc xóa VIP sẽ hoàn tất thành công. Và điều này có thể dẫn đến sự xuất hiện của hai máy chủ có cùng địa chỉ IP ảo và xảy ra sự cố split brain.

Tránh split brain, bạn có thể sử dụng phương pháp STONITH (“Bắn nút khác vào đầu”), cách ly hoàn toàn hoặc vô hiệu hóa nút có vấn đề. Có nhiều cách khác để triển khai tính sẵn sàng cao của cụm: kết hợp VIP và DNS, dịch vụ proxy và khám phá dịch vụ, sao chép đồng bộ và các phương pháp khác có nhược điểm và ưu điểm riêng.

Tôi đã nói về cách tiếp cận của chúng tôi để tạo cụm chuyển đổi dự phòng MySQL. Nó dễ thực hiện và cung cấp mức độ tin cậy chấp nhận được trong điều kiện hiện tại. Khi toàn bộ hệ thống nói chung và cơ sở hạ tầng nói riêng phát triển, cách tiếp cận này chắc chắn sẽ phát triển.

Nguồn: www.habr.com

Orchestrator và VIP là giải pháp HA cho cụm MySQL