[rabbitmq-discuss] Examining Queue Failover Behavior
dmitriy.samovskiy at cohesiveft.com
Wed Feb 11 16:01:49 GMT 2009
Ben Hood wrote:
> completely transparent to a client is not addressed. The modus
> operandi is to a) not lose messages and then b) give somebody the
> tools to recover a node. The reason why transparent failover has not
Speaking about tools. How doable/easy/difficult would it be to develop a tool to inspect
and/or replay persister log outside of the broker's erlang vm? Maybe not all of it but
only basic.publish methods. Such tool would be shipped with broker but will run as a
standalone process launched by user on demand.
With such tool, if a node crashes, one can get persister log, move it out of mnesia dir,
wipe out mnesia dir, start rabbit (which will recreate clean mnesia and persister log and
will get back in business quickly) and then essentially resend all messages that have been
sent and/or have been sent but have not been acked, or something along these lines.
And, down the road, such tool might offer some sort of filtering support (I am thinking
something like tcpdump's filtering language) to match against message headers and things
like publisher's IP, exchange, routing key, time when it arrived, etc.
More information about the rabbitmq-discuss