[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993573#comment-13993573 ] ASF subversion and git services commented on QPID-5409: --- Commit 1593538 from oru...@apache.org in branch 'qpid/trunk' [ https://svn.apache.org/r1593538 ] QPID-5409 : Change BDB HA MBean to delegate operations to BDB HA node instance [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 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13905648#comment-13905648 ] ASF subversion and git services commented on QPID-5409: --- Commit 1569814 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1569814 ] QPID-5409: Restart the former master environment on MASTER transfer [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13905647#comment-13905647 ] ASF subversion and git services commented on QPID-5409: --- Commit 1569813 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1569813 ] QPID-5409: Fix failing unit test LocalReplicationNodeWithReplicatedEnvironmentFacadeTest#testSetRole [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903110#comment-13903110 ] ASF subversion and git services commented on QPID-5409: --- Commit 1568923 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1568923 ] QPID-5409: Add UI for editing node attributes [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900381#comment-13900381 ] ASF subversion and git services commented on QPID-5409: --- Commit 1567942 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1567942 ] QPID-5409: Add basic state management on local replication node and add ability to set the node state [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13898947#comment-13898947 ] ASF subversion and git services commented on QPID-5409: --- Commit 1567576 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1567576 ] QPID-5409: Save virtual host state in the virtual host configuration store. Restore VH state from the store. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893439#comment-13893439 ] ASF subversion and git services commented on QPID-5409: --- Commit 1565308 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1565308 ] QPID-5409: Refactor BDB HA MBean to delegate the operations to the underlying node configured object. Unregister BDB HA MBean on virtual host deletion or replication node removal [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893565#comment-13893565 ] ASF subversion and git services commented on QPID-5409: --- Commit 1565370 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1565370 ] QPID-5409: Environment thread is now used to perform set designated primary/set electable group override/set node prioriy [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893564#comment-13893564 ] ASF subversion and git services commented on QPID-5409: --- Commit 1565369 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1565369 ] QPID-5409: Fix LocalReplicationNode#setAttribute, ignore exception thrown by ReplicatedEnvironmentFacade in LocalReplicationNode#getAttribute [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892239#comment-13892239 ] ASF subversion and git services commented on QPID-5409: --- Commit 1564813 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1564813 ] QPID-5409: Add functionality into RemoteReplicationNode to change role attribute from REPLICA to MASTER [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892240#comment-13892240 ] ASF subversion and git services commented on QPID-5409: --- Commit 1564814 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1564814 ] QPID-5409: Add functionality to delete remote node [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892241#comment-13892241 ] ASF subversion and git services commented on QPID-5409: --- Commit 1564815 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1564815 ] QPID-5409: Refactor RemoteReplicationNode to delegate je calls to ReplicatedEnvironmentFacade [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890547#comment-13890547 ] ASF subversion and git services commented on QPID-5409: --- Commit 1564250 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1564250 ] QPID-5409: Refactor BDB HA system tests to use management REST interfaces instead of JMX. Add new system tests for setting priority, quorum override and role [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887720#comment-13887720 ] ASF subversion and git services commented on QPID-5409: --- Commit 1563131 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1563131 ] QPID-5409: Setting attributes on LocalReplicationNode now causes the corresponding update to the facade. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878595#comment-13878595 ] ASF subversion and git services commented on QPID-5409: --- Commit 1560333 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1560333 ] QPID-5409: Refactoring to move commit thread back to BDBMessageStore. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878797#comment-13878797 ] ASF subversion and git services commented on QPID-5409: --- Commit 1560400 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1560400 ] QPID-5409: Refactring of bdb ha replication functionality and fixing tests [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877608#comment-13877608 ] ASF subversion and git services commented on QPID-5409: --- Commit 1560094 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1560094 ] QPID-5409: Add functionality to automatically detect that master is isolated from majority and restart environment. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877617#comment-13877617 ] ASF subversion and git services commented on QPID-5409: --- Commit 1560101 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1560101 ] QPID-5409: Correct whitespace and a few other minor errors. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874709#comment-13874709 ] ASF subversion and git services commented on QPID-5409: --- Commit 1559084 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1559084 ] QPID-5409: Make replication node monitor interval/timeout configurable from the vhost level. Eliminate thread pool per remote replication node. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873552#comment-13873552 ] ASF subversion and git services commented on QPID-5409: --- Commit 1558844 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1558844 ] QPID-5409: Add functionality to monitor for additions/removals from the group. Add functionality for RemoteReplicationNodes to montior themselves in order that their attributes reflect the state. Also changed commit thread wrapper to abort any remaining commit futures on stop. [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844291#comment-13844291 ] ASF subversion and git services commented on QPID-5409: --- Commit 1549845 from oru...@apache.org in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1549845 ] QPID-5409: Createbranch to add HA multi-node support into BDB message store [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844421#comment-13844421 ] ASF subversion and git services commented on QPID-5409: --- Commit 1549893 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1549893 ] QPID-5409: Recreating branch (created from wrong level) [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5409) [Java Broker] Add support for multi-node HA cluster into BDB JE HA message store
[ https://issues.apache.org/jira/browse/QPID-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844423#comment-13844423 ] ASF subversion and git services commented on QPID-5409: --- Commit 1549894 from [~k-wall] in branch 'qpid/branches/java-broker-bdb-ha' [ https://svn.apache.org/r1549894 ] QPID-5409: Recreating branch [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.27 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 failover. # 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 interface. # 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 situation. # 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 ACL. -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
