[
https://issues.apache.org/jira/browse/ARTEMIS-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362898#comment-17362898
]
Francesco Nigro edited comment on ARTEMIS-2716 at 6/14/21, 11:02 AM:
---------------------------------------------------------------------
I'm going to:
# *remove the initial loop on primary start*: a primary start should succeed or
fail (with errors) and it's key for admin purposes. Admin are supposed to check
broker state before restarting, so it's not just an automated operation.
ie start broker and await failback (or just become a backup) to happen
# *deprecate/document allow-failback*: allow-failback == false turn a
failing-back primary into a backup that can just error out on failover errors
NOTE:
For the latter, in the classic replication a master acting as a backup just
forget its Node ID if any error happen during a failover and restart as an
empty backup.
It's dangerous because on broker restart, the broker got a different NodeID and
can always succeed to become live (!!).
was (Author: nigrofranz):
I'm going to:
# *remove the initial loop on primary start*: a primary start should succeed or
fail (with errors) and it's key for admin purposes: an admin primary restart
with fail-back shouldn't retry again and again, especially if there is a
network partition. Admin are supposed to check broker state before restarting,
so it's not just an automated operation.
ie start broker and await failback (or just become a backup) to happen
# *deprecate/document allow-failback*: allow-failback == false turn a
failing-back primary into a backup that can just error out on failover errors
NOTE:
For the latter, in the classic replication a master acting as a backup just
forget its Node ID if any error happen during a failover and restart as an
empty backup.
It's dangerous because on broker restart, the broker got a different NodeID and
can always succeed to become live (!!).
> Implements pluggable Quorum Vote
> --------------------------------
>
> Key: ARTEMIS-2716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2716
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Attachments: backup.png, primary.png
>
> Time Spent: 16h
> Remaining Estimate: 0h
>
> This task aim to ideliver a new Quorum Vote mechanism for artemis with the
> objectives:
> # to make it pluggable
> # to cleanly separate the election phase and the cluster member states
> # to simplify most common setups in both amount of configuration and
> requirements (eg "witness" nodes could be implemented to support single
> master-slave pairs)
> Post-actions to help people adopt it, but need to be thought upfront:
> # a clean upgrade path for current HA replication users
> # deprecate or integrate the current HA replication into the new version
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
