-
Story
-
Resolution: Done
-
Major
-
None
-
AMQ 7.2.2.GA, AMQ 7.2.3.GA
-
-
+
-
Verified in a release
In a scenario where both master and slave are shutdown (shutdown order unknown), you need some manual intervention to identify which broker was the last “live” broker. Once the last “live" broker is identified; this broker needs to be started as the master broker, to ensure latest broker state is available after restart.
Customer wants to be able to restart the master broker and automatically ensure they have the latest broker state in the above scenario, regardless of which broker was live last.
Example scenario
Master and slave broker both running - master broker is "live".
1) producer sends 1000 messages to broker
./artemis queue stat --user admin --password admin --url tcp://localhost:61617
|NAME |ADDRESS |CONSUMER_COUNT |MESSAGE_COUNT |MESSAGES_ADDED |DELIVERING_COUNT |MESSAGES_ACKED |
|TEST |TEST |0 |1000 |1000 |0 |0 |
2) master broker shutdown
3) slave broker goes "live"
4) consumer consumes 1000 message from address "TEST"
5) producer sends 1000 messages to address "second_queue"
./artemis queue stat --user admin --password admin --url tcp://localhost:61617
|NAME |ADDRESS |CONSUMER_COUNT |MESSAGE_COUNT |MESSAGES_ADDED |DELIVERING_COUNT |MESSAGES_ACKED |
|second_queue |second_queue |0 |1000 |1000 |0 |0 |
7) slave broker is shutdown - both master and slave are both shutdown
8) master broker is restarted
RESULT: old message data used, broker using message state from before Master broker was shutdown (step 2 above).
./artemis queue stat --user admin --password admin --url tcp://localhost:61616
|NAME |ADDRESS |CONSUMER_COUNT |MESSAGE_COUNT |MESSAGES_ADDED |DELIVERING_COUNT |MESSAGES_ACKED |
|TEST |TEST |0 |1000 |1000 |0 |0 |
- is cloned by
-
ENTMQBR-4630 Doc: [AMQ7, replicated master slave, restart] potential for message loss if restarted in wrong order
- New
- is related to
-
ENTMQBR-3391 Implement pluggable Quorum Vote
- Closed