tôi đang khám phá Hàng đợi đại biểu RabbitMQ để cải thiện HA cho một số dịch vụ trong cụm Kubernetes. Khi tôi đang đọc, chúng được thiết kế có tính đến an toàn dữ liệu.
Tuy nhiên, các chương "Quản lý bản sao" Những trạng thái:
Bản sao của hàng đợi đại biểu được quản lý rõ ràng bởi người vận hành.
Khi một nút mới được thêm vào cụm, nó sẽ lưu trữ không có hàng đợi túc số
bản sao trừ khi toán tử thêm nó vào thành viên một cách rõ ràng (bản sao)
danh sách một hàng đợi đại biểu hoặc một tập hợp các hàng đợi đại biểu.
Do đó, có vẻ như, trong trường hợp gián đoạn (đặc biệt là không tự nguyện), tình huống sau có thể phát sinh (đối với cụm 3 nút):
- sau khi gián đoạn, một nút sẽ ngừng hoạt động: hai nút còn lại vẫn chiếm đa số và sẽ "giữ cho hàng đợi tồn tại", có thể bầu ra một thủ lĩnh mới;
- kubernetes sẽ cung cấp một nút (pod) mới để thay thế nút bị lỗi; nút mới sẽ tự động tham gia lại cụm RabbitMQ, nhưng
- trừ khi người điều hành can thiệp thủ công, nút mới sẽ không phải đóng góp vào hàng đợi đại biểu hiện có;
- đối với cụm 3 nút, điều này có nghĩa là không còn HA nữa: nếu một lúc nào đó trong tương lai, một trong các nút khác bị lỗi, thì hàng đợi sẽ bị mất;
Có cách nào để giảm thiểu kịch bản này? Chẳng hạn, có thể có các nút tự động tham gia lại tất cả các cụm hàng đợi đại biểu hiện có không? Có thể bằng cách duy trì một danh sách "lệnh khởi động" (chạy sau khi RabbitMQ bắt đầu) mà chúng ta có thể thêm tham gia lại các lệnh?
