qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
Date Mon, 07 Jul 2014 07:46:34 GMT

     [ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Keith Wall resolved QPID-5409.

    Resolution: Fixed

> [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
> --------------------------------------------------------------------------------
>                 Key: QPID-5409
>                 URL: https://issues.apache.org/jira/browse/QPID-5409
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Alex Rudyy
>             Fix For: 0.29
> The Java Qpid Broker currently supports only 2-nodes HA cluster with  BDB JE message
store. This JIRA aims to extend the current HA functionality and add support for multi-node
HA cluster into BDB JE message store.
> Here is the list of high-level requirements for the HA multi-node support:
> # Only persistent messages are to be replicated.  Transient messages will be lost on
> # System must support clusters formed of an arbitrary number of nodes 
> # System must continue to support clusters formed of two nodes.  Existing public interfaces
(notably JMX and existing virtualhost.xml format) must be retained (though may be deprecated)
to allow existing users a convenient upgrade path.
> # System must allow a user to completely configure a new node via the web-management
> # System must allow a user to monitor the nodes of the cluster in order to ascertain
its health and perform day to day operations for via the web-management interface. 
> ## expose statistics to allow the health of the cluster to be established (exact details
to be determined: could be low level like DbPing or something more abstract)
> # System must be amenable to monitoring by third-party tools. The Broker should emit
clear operational log messages as it transitions between states.  These messages will be targeted
at the end-user. 
> # System must permit a mode of operation whereby the user (or other external agent) determines
which virtual host becomes active following a store failover. In this mode of operation, following
a failure, the store nodes in the cluster will elect a new master and the replica node will
still sync-up with the new master node, but the system will not automatically mark the virtual
host corresponding to the master as active.   The user will then transfer the master to the
desired location and make the virtualhost as active, allowing business traffic to recommence.

> # System must permit a mode of operation whereby the election of a store node as master
also causes the corresponding virtual host to become active. 
> # System must allow a user to influence a node's electability.  These features will allow
a customer whose cluster spans primary/DR sites to keep the active virtual hosts  on the primary
site in normal situations by favouring failover within the primary site.Specifically, this
will allow: 
> ## making a node unelectable  - the node, even though it remains part of the cluster,
will never be elected as master)
> ## making a node more likely to be elected master than other nodes  - that is, if two
or more nodes have an equally up to date set of transactions, the node with the highest priority
will be elected master
> ## node electability settings must survive restart,
> ## node electability settings must be alterable at run-time.
> # System must allow a user to alter quorum. This feature is required in extraordinary
situations where the system is required to continue to operate despite the loss of sufficient
nodes to mean there is no longer simple majority.
> # System must allow the user to move the active virtual host from one node to another.
This feature will help a user to restore a system to its BAU state following an extraordinary
> # System must provide a user with a read-only view Queue when the underlying store is
in a replica state.  This must provide at least queue name and queue depth. This feature will
allow a user to be able to see that replication is indeed functioning. 
> # System must allow all HA operations to be allowed/denied according to rules in the

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message