Comments 4
Делал то же самое, только через федерейшен: новый кластер брал сообщения у старого. Потом отключался федерейшен и старый кластер.
Ну а вообще, для упрощения — желательно иметь два отдельных кластера, связанных двухсторонним федерейшеном, под единым dns неймспейсом. И тогда можно прозрачно выключать/выводить один из них для обновления/обслуживания.
Ну а вообще, для упрощения — желательно иметь два отдельных кластера, связанных двухсторонним федерейшеном, под единым dns неймспейсом. И тогда можно прозрачно выключать/выводить один из них для обновления/обслуживания.
поскольку ходят легенды, насколько кролику свойственен сплит-брейн и прочие трудности при разрыве связи между кусочками кластера, хотелось бы каких-то деталей на этот счет.
У нас в обслуживании более 50 кластеров, ~20 из них продовых.
Кластера с разной нагруженностью.
Где-то по несколько сообщений за час, где-то тысячи, в нескольких проектах сотни тысяч.
В один момент пришлось все это обновлять, ни разу не вылезло проблем с split-brain.
И если чество за последние 6 месяцев во всех этих кластерах ни разу подобной проблемы не было.
Везде стоит кластер из 3 нод.
Кластера с разной нагруженностью.
Где-то по несколько сообщений за час, где-то тысячи, в нескольких проектах сотни тысяч.
В один момент пришлось все это обновлять, ни разу не вылезло проблем с split-brain.
И если чество за последние 6 месяцев во всех этих кластерах ни разу подобной проблемы не было.
Везде стоит кластер из 3 нод.
Да вроде бы ведёт себя как описано в документации. В зависимости от режимов — либо восстановится сам, либо потребует ручного вмешательства. Есть нюансы: при некоторых настройках и неправильном восстановлении можно убить целиком весь кластер.
Sign up to leave a comment.
Беспростойная миграция RabbitMQ в Kubernetes