Назад | Перейти на главную страницу

Репликация beanstalkd для обеспечения высокой доступности

Название говорит само за себя.

Кто-нибудь знает способ реплицировать beanstalkd таким образом, чтобы, если сервер beanstalk вышел из строя, другие подчиненные могли взять его на себя?

Вот один подход, о котором я подумал: я мог бы заставить beanstalk записывать свой binlog (с параметром -b) в общую папку, а затем каким-то образом запустить beanstalkd на вторичном / резервном сервере, если первичный выйдет из строя.

Хотя должен быть способ получше.

Поскольку он записывает на диск через binlog, я думаю, вы могли бы сделать что-то похожее на то, что обычно делают администраторы MySQL: сердцебиение ж / DRBD (пример Вот).

Однако в последний раз, когда я пытался использовать Heartbeat, он не поддерживал проверку без многоадресной рассылки между узлами, а это означало, что его было более или менее невозможно запустить в инфраструктуре облака / VPS (AWS, Linode, Slicehost и т. Д.). Фактически, большинство служб кластеризации используют многоадресную рассылку. Возможно, это уже не так, но об этом нужно знать. Вы можете использовать оставайся живым для обеспечения аварийного переключения на основе IP, который также поддерживает только многоадресную рассылку, НО имеет исправление, доступное через Вилли Тарро (автор HAProxy) к добавить поддержку одноадресной рассылки. Я лично протестировал это на паре серверов Linode VPS, и keepalived может переключить общий IP-адрес в случае сбоя главного сервера.

Одна вещь, которую вы можете сделать, вероятно, менее оптимальна, - это писать задания на несколько серверов beanstalkd (также называемое секционированием). Если один из них выходит из строя, пусть ваше приложение обнаружит это и вместо этого напишет другим экземплярам. Ваши рабочие должны будут разумно опрашивать каждый из экземпляров beanstalkd и иметь возможность игнорировать мертвые экземпляры. Поскольку вы ведете ведение журнала, создание резервной копии экземпляра должно быть таким же простым, как его перезапуск, и приложение / рабочие обнаружат это и продолжат как обычно (и начнут обрабатывать задания во вновь запущенном экземпляре). Я, очевидно, упрощаю процесс, но это еще один способ справиться с этим.