The High Availablity docs at <a href="http://www.rabbitmq.com/pacemaker.html" target="_blank">http://www.rabbitmq.com/pacemaker.html</a> seem pretty thorough.  Are there any other approaches commonly used for HA? What about for syncing between data centers? Can anyone discuss their HA approach if it differs from the link above?<div>


<br></div><div>We are evaluating messaging systems and the question of HA has come up frequently.  The concern is that some items, once entered onto the queue, should never be lost -- even if the entire data center goes down.</div>


<div><br></div><div>We are comparing RabbitMQ with writing a system in-house.  The in-house queue system would use a Postgresql table for the queue with replication (currently via Slony) for hot-backup (it&#39;s not really HA).  We also replicate to a secondary data center with the eventual goal of reasonably fast tip-over between data centers.  We are not in the financial or medical industry so nobody&#39;s life is at risk if we drop a few jobs.  I suspect we only need to handle three to five million message a day -- nothing too big.  (Oddly, one argument against using RabbitMQ was it was overkill for our needs.)</div>


<div><br></div><div>Postgresql and replication is what we use for application data currently, so it is a familiar technology for us.  Another reason we are considering building a custom message queue system is to put more functionality into the broker -- such as scheduling and job routing that would be specific to our business.  And there&#39;s fear that nobody knows Erlang if something broke and we needed to try and resolve.</div>


<div><br></div><div>My opinion is AMQP is very flexible and we should be able to make it meet our needs.  We are not doing anything that unusual.  And I suspect building something as reliable as RabbitMQ is no easy task -- especially if the point is to make a system more complex than what RabbitMQ provides.  Scheduling, for example, seems like something a simple database table and cron could solve easily with RabbitMQ.</div>


<div><br></div><div>Another argument for a custom broker was to make better use of workers -- i.e. the broker would look at load and other factors when determining where to send jobs.  My feeling here is resources are limited so it&#39;s a matter of balancing the number and type of consumers with queue load -- and an external process can manage starting and stopping consumers easily as demand profile changes (by looking at queue sizes and rates) without having to be part of the broker.  Are there common approaches for dynamically adjusting workers?</div>


<div><br></div><div>Anyone go through this kind of discussion in your own organization?</div><div><br></div><div>Thanks,<br clear="all"><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>



</div>