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>