> RedHat AMQ 7 (which is using Artemis under the hood) in their "configuring broker" documentation recommend NOT using [HA replication] across data centers.What is the Artemis position (not on AMQ, but if using Artemis)?
Replication was designed to be used across a low-latency, high-performance network connection which generally is not the kind of connection you have between data centers. It doesn't matter whether you're using Artemis standalone or embedded into something else. > Is this HA replication always: synchronous/blocking or is there an asynchronous version too? Technically speaking, replication is asynchronous. However, the broker will not send a response to the client until it has received a reply from the slave that the data has been received. Therefore, once the client receives the response from the broker it is assured that both the master and the slave have the data. > If the network goes down between master and slave: what happens to the service the prod master brokers provide (does it block clients)? If the network between the master and slave goes down then by default the master continues like nothing happened. The master can be configured to initiate a quorum vote in this situation to determine whether or not it should remain alive or shut itself down (e.g. in the case that it's isolated). > For high performance scenarios: is it still the recommendation to use asynchronous DRBD ( https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device) across data centers? If you're referring to what I said in the original response on this thread then I think "recommendation" is too strong of a word. I was simply offering an idea of what I believed might work. For what it's worth, I've found that data integrity and high performance and generally at odds with each other. > Using asynchronous replication can lead to small message loss and imperfect replication of the journal. How resilient is Artemis to these small corruptions of the journal? Can it start the broker and ignore the "corrupt"/incomplete replica blocks? I'm not sure the kind of data loss you're describing has ever been tested. As far as I know, Artemis expects the data it writes to the journal to still be in the journal when it is re-loaded. In general, I would expect that any solution designed to ensure data integrity would consider message loss or imperfect replication an unacceptable failure. > Is there any existing documentation on this? I'm not aware of any. Justin On Wed, Jun 19, 2019 at 5:05 PM warm-sun <warm-...@tutanota.com> wrote: > I have a very similar scenario to the original post. (Multi data center > replication is required) > I have read all the documentation -- but am unclear about a couple of > points: > > 1) RedHat AMQ 7 (which is using Artemis under the hood) in their > "configuring broker" documentation recommend NOT using [HA replication] > across data centers. > What is the Artemis position (not on AMQ, but if using Artemis)? > Is this HA replication always: synchronous/blocking or is there an > asynchronous version too? > If the network goes down between master and slave: what happens to the > service the prod master brokers provide (does it block clients)? > > 2) For high performance scenarios: is it still the recommendation to use > asynchronous DRBD > (https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device) across > data centers? > > 3) Using asynchronous replication can lead to small message loss and > imperfect replication of the journal. How resilient is Artemis to these > small corruptions of the journal? Can it start the broker and ignore the > "corrupt"/incomplete replica blocks? > > 4) Is there any existing documentation on this? This is what I found: > > https://www.linbit.com/downloads/tech-guides/DRBD8_ActiveMQ_HA_and_DR_on_RHEL7.pdf > (ActiveMQ but not Artemis) > https://www.rabbitmq.com/pacemaker.html (DRBD as well) > > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
