[
https://issues.apache.org/jira/browse/ARTEMIS-2716?focusedWorklogId=605972&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-605972
]
ASF GitHub Bot logged work on ARTEMIS-2716:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 03/Jun/21 14:57
Start Date: 03/Jun/21 14:57
Worklog Time Spent: 10m
Work Description: gtully commented on pull request #3555:
URL: https://github.com/apache/activemq-artemis/pull/3555#issuecomment-853934741
> You should never become active unless you get the lock, there should be no
epoch about it, if you do that, you're asking for disaster.
what you want is to have the lock and the current data. The lock alone is
not sufficient.
Consider this:
primary starts, backup starts and becomes an in sync replica. Both die.
primary comes back up for a while, and dies. backup restarts, It gets the lock
but has stale data. boom!
The distributed lock only guards access to the journal, but something else
(the epoch counter) has to guard the singular valid transition from primary to
in sync backup. It is only valid if the lock is **next** held by the backup.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 605972)
Time Spent: 11h (was: 10h 50m)
> 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: 11h
> 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)
