Der Titel sagt alles.
Kennt jemand eine Möglichkeit, Beanstalkd so zu replizieren, dass andere Slaves die Kontrolle übernehmen könnten, wenn ein Beanstalk-Server ausfällt?
Hier ist ein Ansatz, über den ich nachgedacht habe: Ich könnte dafür sorgen, dass Beanstalk sein Binlog (mit -b) an einen freigegebenen Speicherort schreibt und dann irgendwie einen sekundären / Backup-Server dazu bringt, Beanstalkd zu starten, wenn der primäre ausfällt.
Es muss aber einen besseren Weg geben.
Antworten:
Da über binlog auf die Festplatte geschrieben wird, könnte man etwas ähnliches tun, wie es MySQL-Administratoren normalerweise tun: Heartbeat mit DRBD ( Beispiel hier).
Das letzte Mal, als ich versuchte, Heartbeat zu verwenden, unterstützte es keine Non-Multicast-Prüfung zwischen Knoten, was bedeutete, dass die Ausführung in einer Cloud / VPS-Infrastruktur (AWS, Linode, Slicehost usw.) mehr oder weniger unmöglich war. Tatsächlich verwenden die meisten Clusterdienste Multicast. Dies ist möglicherweise nicht mehr der Fall, aber es ist etwas zu beachten. Möglicherweise können Sie keepalived verwenden , um ein IP-basiertes Failover bereitzustellen, das auch nur Multicast unterstützt. Es steht jedoch ein Patch über Willy Tarreau (Autor von HAProxy ) zur Verfügung, um Unicast-Unterstützung hinzuzufügen . Ich habe dies persönlich auf zwei Linode VPS-Servern getestet und keepalived kann ein Failover einer gemeinsam genutzten IP-Adresse durchführen, falls der Master-Server ausfällt.
Eine Sache, die Sie tun können und die wahrscheinlich weniger optimal ist, ist das Schreiben von Jobs auf eine Reihe von Beanstalkd-Servern (auch Partitionierung genannt). Wenn einer von ihnen ausfällt, lassen Sie Ihre App dies erkennen und schreiben Sie stattdessen auf die anderen Instanzen. Ihre Mitarbeiter müssen jede der Beanstalked-Instanzen intelligent abfragen und in der Lage sein, tote Instanzen zu ignorieren. Da Sie Binlogging ausführen, sollte das Wiederherstellen einer Instanz so einfach wie das Neustarten sein. Die App / Worker erkennen dies und fahren wie gewohnt fort (und beginnen mit der Verarbeitung der Jobs in der neu gestarteten Instanz). Ich vereinfache den Prozess offensichtlich, aber das ist eine andere Möglichkeit, damit umzugehen.