Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/1747
I think it's a good idea to understand what we failures we can recover from
and which ones we can not in the context of consistency and availability.
Note, I'm not including network issues here.
Availability: This PR doesn't really concern availability but for context:
A single live/backup pair setup can recover from a *single* machine failure.
In the event of a live failure, the backup takes over, (it may have some data
in memory at this point). In the event of a backup failure, availability is
preserved.
Consistency: Consistency is preserved even if both machines fail. The ack
isn't sent back to the client unless it's persisted on the live. Should live
fail, the backup is still consistent, (though there is a small window where
data is in memory). Should the backup fail before it syncs to disk, it will
not have consistency, however, the live still has the copy of it's journal
which is up to date.
There is a known issue here in that the broker with the most recent journal
must be started first after a live and backup failure (this goes beyond this
case) and required manual intervention to deal with. We will be addressing
this soon.
There is however still a use case for this patch. In that it does allow
recovery from a disk failure should both live and backup fail. The probability
is likely very small, but I can see a case for ensuring data is persisted in
two places, but not at the expense of performance for other use cases.
This could be a configuration option. However, for this use case I would
recommend using a shared store solution as dedicated shared storage solutions
can already address these issues.
---
