Назва говорить все це.
Хтось знає про спосіб копіювання beanstalkd таким, що якщо сервер beanstalk зійшов, інші раби могли взяти на себе власність?
Ось один із підходів, про який я подумав: я міг би змусити beanstalk написати свій бінлог (з -b) у спільне місце розташування, а потім якось мати вторинний / резервний сервер запустити beanstalkd, якщо первинна не вдасться.
Має бути, кращий спосіб.
Відповіді:
Оскільки він пише на диск через binlog, я б подумав, що ви можете зробити щось подібне до того, що зазвичай роблять адміністратори MySQL: серцебиття w / DRBD ( приклад тут).
Востаннє, коли я намагався використовувати серцебиття, він не підтримував не багатоадресну перевірку між вузлами, це означає, що це було більш-менш неможливо запустити на хмарній / VPS-інфраструктурі (AWS, Linode, Slicehost тощо). Насправді, більшість кластерних сервісів використовують багатоадресову передачу. Це може бути вже не так, але варто пам’ятати про щось. Ви можете використовувати keepalived для надання відмови на базі ip, яка також підтримує лише багатоадресову передачу, але має патч, доступний через Віллі Тарро (автор HAProxy ) для додавання одноадресної підтримки . Я особисто перевірив це на парі серверів Linode VPS і keepalived здатний змінити загальну IP-адресу у разі відмови головного сервера.
Одне, що ви можете зробити, що, мабуть, менш оптимально - це писати завдання на ряд серверів beanstalkd (він же розділення). Якщо одна з них виходить з ладу, запропонуйте вашій програмі виявити це і напишіть натомість іншим екземплярам. Вашим працівникам доведеться інтелектуально опитувати кожен із примірників beanstalkd і мати можливість ігнорувати мертві екземпляри. Оскільки ви бінінгуєте, відновлення копії екземпляра повинно бути таким же простим, як і його перезапуск, і програма / працівники виявлять це і продовжать як завжди (і почнуть обробляти завдання в новоствореному екземплярі). Я, очевидно, спрощую процес, але це ще один спосіб впоратися з ним.