Virtualhost nodes can be stopped, started and deleted.
Stop
Stopping a master node will cause the node to temporarily leave the group. Any messaging clients will be disconnected and any in-flight transaction rollbacked. The remaining nodes will elect a new master if quorum number of nodes still remains.
Stopping a replica node will cause the node to temporarily leave the group too. Providing quorum still exists, the current master will continue without interruption. If by leaving the group, quorum no longer exists, all the nodes will begin waiting, disconnecting any messaging clients, and the virtualhost will become unavailable.
A stopped virtualhost node is still considered to be a member of the group.
Start
Starting a virtualhost node allows it to rejoin the group.
If the group already has a master, the node will catch up from the master and then become a replica once it has done so.
If the group did not have quorum and so had no master, but the rejoining of this node means quorum now exists, an election will take place. The node with the most up to date transaction will become master unless influenced by the priority rules described above.
Note
The length of time taken to catch up will depend on how long the node has been stopped. The worst case is where the node has been stopped for more than one hour. In this case, the master will perform an automated
network restore. This involves streaming all the data held by the master over to the replica. This could take considerable time.Delete
A virtualhost node can be deleted. Deleting a node permanently removes the node from the group. The data stored locally is removed but this does not affect the data held by the remainder of the group.
Note
The names of deleted virtualhost node cannot be reused within a group.
It is also possible to add nodes to an existing group using the procedure described above.
This operation allows the mastership to be moved from node to node. This is useful for restoring a business as usual state after a failure.
When using this function, the following occurs.
The system first gives time for the chosen new master to become reasonable up to date.
It then suspends transactions on the old master and allows the chosen node to become up to date.
The suspended transactions are aborted and any messaging clients connected to the old master are disconnected.
The chosen master becomes the new master. The old master becomes a replica.
Messaging clients reconnect the new master.
Apache Qpid, Messaging built on AMQP; Copyright © 2015 The Apache Software Foundation; Licensed under the Apache License, Version 2.0; Apache Qpid, Qpid, Qpid Proton, Proton, Apache, the Apache feather logo, and the Apache Qpid project logo are trademarks of The Apache Software Foundation; All other marks mentioned may be trademarks or registered trademarks of their respective owners