Bất kỳ dự án lớn nào cũng bắt đầu với một vài máy chủ. Lúc đầu chỉ có một máy chủ DB, sau đó các máy chủ nô lệ được thêm vào đó để mở rộng quy mô đọc. Và sau đó - dừng lại! Có một ông chủ nhưng có nhiều nô lệ; nếu một trong những nô lệ rời đi thì mọi thứ sẽ ổn, nhưng nếu chủ nhân rời đi thì sẽ rất tệ: thời gian ngừng hoạt động, quản trị viên đang cố gắng nâng cấp máy chủ. Phải làm gì? Dự trữ một bậc thầy. Đồng nghiệp Pavel của tôi đã viết về điều này , Tôi sẽ không lặp lại nó. Thay vào đó, tôi sẽ cho bạn biết lý do tại sao bạn chắc chắn cần Orchestrator cho MySQL!
Hãy bắt đầu với câu hỏi chính: “Làm cách nào để chuyển mã sang máy mới khi chủ rời đi?”
- Tôi thích chương trình VIP (IP ảo) nhất, chúng ta sẽ nói về nó bên dưới. Đó là cách đơn giản và rõ ràng nhất, mặc dù nó có một hạn chế rõ ràng: bản gốc mà chúng ta dự trữ phải nằm trong phân khúc L2 với máy mới, tức là chúng ta có thể quên DC thứ hai. Và, nói một cách thân thiện, nếu bạn tuân theo quy tắc rằng L2 lớn là xấu, bởi vì L2 chỉ nằm trên mỗi giá, còn L3 nằm giữa các giá, và sơ đồ như vậy thậm chí còn có nhiều hạn chế hơn.
- Bạn có thể viết tên DNS vào mã và phân giải nó thông qua /etc/hosts. Trên thực tế, sẽ không có giải pháp nào cả. Ưu điểm của sơ đồ: không có đặc điểm hạn chế của phương pháp đầu tiên, nghĩa là có thể tổ chức một DC chéo. Nhưng sau đó, câu hỏi hiển nhiên được đặt ra: chúng tôi có thể chuyển giao thay đổi tới /etc/hosts thông qua Puppet-Ansible nhanh đến mức nào?
- Bạn có thể thay đổi phương pháp thứ hai một chút: cài đặt bộ đệm DNS trên tất cả các máy chủ web, qua đó mã sẽ đi đến cơ sở dữ liệu chính. Bạn có thể đặt TTL 60 cho mục này trong DNS. Có vẻ như nếu thực hiện đúng thì phương pháp này là tốt.
- Một kế hoạch khám phá dịch vụ, ngụ ý việc sử dụng Lãnh sự và v.v.
- Một lựa chọn thú vị với . Bạn cần định tuyến tất cả lưu lượng truy cập đến MySQL thông qua ProxySQL; Bản thân ProxySQL có thể xác định ai là chủ. Nhân tiện, bạn có thể đọc về một trong các tùy chọn sử dụng sản phẩm này trong tài liệu của tôi .
Tác giả của Orchestrator, làm việc tại Github, lần đầu tiên triển khai kế hoạch đầu tiên với VIP, sau đó chuyển đổi nó thành kế hoạch với lãnh sự.
Sơ đồ hạ tầng điển hình:
Tôi sẽ mô tả ngay các tình huống rõ ràng cần được tính đến:
- Địa chỉ VIP không được đăng ký trong cấu hình trên bất kỳ máy chủ nào. Hãy tưởng tượng một tình huống: bản gốc khởi động lại và trong khi nó đang tải, Orchestrator chuyển sang chế độ chuyển đổi dự phòng và biến một trong những nô lệ thành bản chính; rồi ông chủ già đứng dậy, còn bây giờ VIP ngồi trên hai chiếc xe. Thật tệ.
- Đối với người điều phối dàn nhạc, bạn sẽ cần viết kịch bản để gọi chủ cũ và chủ mới. Trên bản gốc cũ, bạn cần chạy ifdown và trên bản gốc mới – ifup vip. Sẽ rất tuyệt nếu thêm vào tập lệnh này rằng trong trường hợp chuyển đổi dự phòng, cổng trên công tắc chính cũ sẽ bị tắt để tránh bất kỳ sự phân tách nào.
- Sau khi Orchestrator gọi tập lệnh của bạn để xóa VIP và/hoặc tắt cổng trên switch, sau đó gọi tập lệnh tăng VIP trên bản chính mới, đừng quên sử dụng lệnh arping để thông báo cho mọi người rằng VIP mới hiện đã có đây.
- Tất cả nô lệ phải có read_only=1 và ngay sau khi bạn thăng cấp nô lệ lên chủ, nó sẽ có read_only=0.
- Đừng quên rằng bất kỳ nô lệ nào mà chúng tôi đã chọn cho việc này đều có thể trở thành chủ nhân (Người dàn nhạc có toàn bộ cơ chế ưu tiên để xem nô lệ nào là ứng cử viên cho chủ mới ngay từ đầu, cái nào ở vị trí thứ hai và nô lệ nào nên hoàn toàn không được chọn trong bất kỳ trường hợp nào chủ nhân). Nếu nô lệ trở thành chủ thì tải của nô lệ sẽ vẫn đè lên người đó và tải của chủ sẽ tăng thêm, điều này phải được tính đến.
Tại sao bạn cần Orchestrator nếu bạn không có?
- Orchestrator có giao diện đồ họa rất thân thiện với người dùng, hiển thị toàn bộ cấu trúc liên kết (xem ảnh chụp màn hình bên dưới).
- Orchestrator có thể theo dõi những Slave nào bị tụt lại phía sau và nơi sao chép thường bị hỏng (chúng tôi có các tập lệnh được đính kèm với Orchestrator để gửi SMS).
- Người điều phối sẽ cho bạn biết nô lệ nào có lỗi GTID.
Giao diện soạn nhạc:
Lỗi GTID là gì?
Có hai yêu cầu chính để Orchestrator hoạt động:
- Điều cần thiết là phải kích hoạt GTID giả trên tất cả các máy trong cụm MySQL; chúng tôi đã kích hoạt GTID.
- Điều cần thiết là phải có một loại binlog ở khắp mọi nơi, bạn có thể sử dụng câu lệnh. Chúng tôi có một cấu hình trong đó chủ và hầu hết nô lệ có Hàng và hai người trước đây vẫn ở chế độ Hỗn hợp. Kết quả là, Orchestrator đơn giản là không muốn kết nối những nô lệ này với chủ nhân mới.
Hãy nhớ rằng điều quan trọng nhất ở nô lệ sản xuất là tính nhất quán của nó với chủ! Nếu bạn đã bật ID giao dịch toàn cầu (GTID) trên cả máy chính và máy phụ thì bạn có thể sử dụng hàm gtid_subset để tìm hiểu xem các yêu cầu thay đổi dữ liệu tương tự có thực sự được thực thi trên các máy này hay không. Bạn có thể đọc thêm về điều này .
Do đó, Orchestrator hiển thị cho bạn thông qua lỗi GTID rằng có các giao dịch trên phần phụ không có trên phần chính. Tại sao chuyện này đang xảy ra?
- Read_only=1 không được bật trên máy phụ, ai đó đã kết nối và hoàn thành yêu cầu thay đổi dữ liệu.
- Super_read_only=1 không được bật trên máy phụ, sau đó quản trị viên đã nhầm lẫn máy chủ nên đã truy cập và thực hiện yêu cầu ở đó.
- Nếu bạn đã tính đến cả hai điểm trước đó, thì còn một mẹo nữa: trong MySQL, yêu cầu xóa binlog cũng được chuyển đến binlog, vì vậy ở lần xóa đầu tiên, lỗi GTID sẽ xuất hiện trên máy chủ và tất cả máy phụ. Làm thế nào để tránh điều này? Perona-5.7.25-28 đã giới thiệu cài đặt binlog_skip_flush_commands=1, cấm ghi tuôn ra vào binlog. Có một cái được thành lập trên trang web mysql.com .
Hãy để tôi tóm tắt tất cả những điều trên. Nếu bạn chưa muốn sử dụng Orchestrator ở chế độ chuyển đổi dự phòng, hãy đặt nó ở chế độ quan sát. Sau đó, bạn sẽ luôn có trước mắt bản đồ tương tác của các máy MySQL và thông tin trực quan về kiểu sao chép trên mỗi máy, liệu các máy nô lệ có bị tụt lại phía sau hay không và quan trọng nhất là chúng nhất quán như thế nào với máy chủ!
Câu hỏi rõ ràng là: “Người soạn nhạc nên làm việc như thế nào?” Anh ta phải chọn một chủ mới từ các nô lệ hiện tại, sau đó kết nối lại tất cả các nô lệ với nó (đây là điều cần có GTID; nếu bạn sử dụng cơ chế cũ với binlog_name và binlog_pos, thì hãy chuyển một nô lệ từ chủ hiện tại sang chủ mới đơn giản là không thể!). Trước khi chúng tôi có Orchestrator, tôi đã từng phải thực hiện tất cả những việc này một cách thủ công. Ông chủ cũ bị treo cổ do bộ điều khiển Adaptec bị lỗi, nó có khoảng 10 nô lệ. Tôi cần chuyển VIP từ chủ sang một trong các nô lệ và kết nối lại tất cả các nô lệ khác với nó. Tôi đã phải mở bao nhiêu bảng điều khiển, nhập bao nhiêu lệnh đồng thời... Tôi phải đợi đến 3 giờ sáng, gỡ tải khỏi tất cả nô lệ trừ hai, biến máy đầu tiên thành hai máy chính, gắn ngay máy thứ hai vào nó, vì vậy hãy gắn tất cả các nô lệ khác vào chủ mới và trả lại tải. Nói chung là khủng khiếp...
Orchestrator hoạt động như thế nào khi nó chuyển sang chế độ chuyển đổi dự phòng? Điều này được minh họa dễ dàng nhất bằng một ví dụ về tình huống mà chúng ta muốn biến người chủ thành một cỗ máy mạnh hơn, hiện đại hơn chúng ta có hiện nay.
Hình ảnh cho thấy phần giữa của quá trình. Những gì đã được thực hiện cho đến thời điểm này? Chúng tôi nói rằng chúng tôi muốn biến một số nô lệ thành chủ mới, Orchestrator bắt đầu chỉ cần kết nối lại tất cả các nô lệ khác với nó, với chủ mới hoạt động như một cỗ máy chuyển tuyến. Với sơ đồ này, không có lỗi xảy ra, tất cả các phần phụ đều hoạt động, Orchestrator xóa VIP khỏi bản chính cũ, chuyển nó sang bản gốc mới, tạo read_only=0 và quên mất bản gốc cũ. Tất cả! Thời gian ngừng hoạt động của dịch vụ của chúng tôi là thời gian chuyển VIP, là 2-3 giây.
Hôm nay chỉ vậy thôi, cảm ơn mọi người. Sẽ sớm có bài viết thứ hai về Orchestrator. Trong bộ phim nổi tiếng của Liên Xô “Garage”, một nhân vật đã nói: “Tôi sẽ không đi trinh sát với anh ta!” Vì vậy, Người soạn nhạc, tôi sẽ cùng bạn đi trinh sát!
Nguồn: www.habr.com