<commit_before><?xml-stylesheet type="text/xml" href="page.xsl"?>
<!--
Copyright (C) 2007-2015 Pivotal Software, Inc.

All rights reserved. This program and the accompanying materials
are made available under the terms of the under the Apache License,
Version 2.0 (the "License”); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:doc="http://www.rabbitmq.com/namespaces/ad-hoc/doc"
      xmlns:x="http://www.rabbitmq.com/2011/extensions">
  <head>
    <title>Highly Available Queues</title>
  </head>
  <body show-in-this-page="true">
      <doc:section name="overview">
        <p>
          By default, queues within a RabbitMQ cluster are located on
          a single node (the node on which they were first
          declared). This is in contrast to exchanges and bindings,
          which can always be considered to be on all nodes. Queues
          can optionally be made <i>mirrored</i> across multiple
          nodes. Each mirrored queue consists of one <i>master</i> and
          one or more <i>slaves</i>, with the oldest slave being
          promoted to the new master if the old master disappears for
          any reason.
        </p>
        <p>
          Messages published to the queue are replicated to all
          slaves. Consumers are connected to the master regardless of
          which node they connect to, with slaves dropping messages
          that have been acknowledged at the master. Queue mirroring
          therefore enhances availability, but does not distribute
          load across nodes (all participating nodes each do all the
          work).
        </p>
        <p>
          This solution requires a RabbitMQ cluster, which means that
          it will not cope seamlessly with network partitions within
          the cluster and, for that reason, is not recommended for use
          across a WAN (though of course, clients can still connect
          from as near and as far as needed).
        </p>
      </doc:section>

      <doc:section name="genesis">
        <doc:heading>Configuring Mirroring</doc:heading>
        <p>
          Queues have mirroring enabled
          via <a href="parameters.html#policies">policy</a>. Policies
          can change at any time; it is valid to create a non-mirrored
          queue, and then make it mirrored at some later point (and
          vice versa). There is a difference between a non-mirrored
          queue and a mirrored queue which does not have any slaves -
          the former lacks the extra mirroring infrastructure and will
          run faster.
        </p>
        <p>
          You should be aware of the behaviour
          of <a href="#unsynchronised-slaves">adding mirrors to a
          queue</a>.
        </p>
        <p>
          To cause queues to become mirrored, you should create a
          policy which matches them and sets policy
          keys <code>ha-mode</code> and
          (optionally) <code>ha-params</code>. The following table
          explains the options for these keys:
        </p>

        <table>
          <tr>
            <th><code>ha-mode</code></th>
            <th><code>ha-params</code></th>
            <th>Result</th>
          </tr>
          <tr>
            <td><code>all</code></td>
            <td>(absent)</td>
            <td>
              Queue is mirrored across all nodes in the
              cluster. When a new node is added to the cluster, the
              queue will be mirrored to that node.
            </td>
          </tr>
          <tr>
            <td><code>exactly</code></td>
            <td><i>count</i></td>
            <td>
              Queue is mirrored to <i>count</i> nodes in the
              cluster. If there are less than <i>count</i> nodes in
              the cluster, the queue is mirrored to all nodes. If
              there are more than <i>count</i> nodes in the cluster,
              and a node containing a mirror goes down, then a new
              mirror will be created on another node. Use of
              <code>exactly</code> mode with <a
              href="#cluster-shutdown"><code>"ha-promote-on-shutdown":
              "always"</code></a> can be dangerous since queues can
              migrate across a cluster and become unsynced as it is
              brought down.
            </td>
          </tr>
          <tr>
            <td><code>nodes</code></td>
            <td><i>node names</i></td>
            <td>
              Queue is mirrored to the nodes listed in <i>node
              names</i>. If any of those node names are not a part of
              the cluster, this does not constitute an error. If none
              of the nodes in the list are online at the time when the
              queue is declared then the queue will be created on the
              node that the declaring client is connected to.
            </td>
          </tr>
        </table>

        <p>
          Whenever the HA policy for a queue changes it will endeavour
          to keep its existing mirrors as far as this fits with the new
          policy.
        </p>

        <h3>Queue Master Location</h3>
        <p>
          Every queue in RabbitMQ has a home node. That node is called
          <em>queue master</em>. All queue operations go through the master
          first and then are replicated to mirrors. This is necessary to
          guarantee FIFO ordering of messages.
        </p>
        <p>
          Queue masters can be distributed between nodes using several
          strategies. Which strategy is used is controlled using the
          <code>x-queue-master-locator</code> queue declare argument,
          or by setting the <code>queue-master-locator</code> policy
          key. Here are the possible strategies and how to set them:

          <ul>
            <li>Pick the node hosting the minimum number of masters:
            <code>min-masters</code></li>
            <li>Pick the node the client that declares the queue is
            connected to: <code>client-local</code></li>
            <li>Pick a random node: <code>random</code></li><commit_msg>Adds procedure of setting queue-master-locator strategy in rabbit.config.<commit_after><?xml-stylesheet type="text/xml" href="page.xsl"?>
<!--
Copyright (C) 2007-2015 Pivotal Software, Inc.

All rights reserved. This program and the accompanying materials
are made available under the terms of the under the Apache License,
Version 2.0 (the "License”); you may not use this file except in compliance
with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:doc="http://www.rabbitmq.com/namespaces/ad-hoc/doc"
      xmlns:x="http://www.rabbitmq.com/2011/extensions">
  <head>
    <title>Highly Available Queues</title>
  </head>
  <body show-in-this-page="true">
      <doc:section name="overview">
        <p>
          By default, queues within a RabbitMQ cluster are located on
          a single node (the node on which they were first
          declared). This is in contrast to exchanges and bindings,
          which can always be considered to be on all nodes. Queues
          can optionally be made <i>mirrored</i> across multiple
          nodes. Each mirrored queue consists of one <i>master</i> and
          one or more <i>slaves</i>, with the oldest slave being
          promoted to the new master if the old master disappears for
          any reason.
        </p>
        <p>
          Messages published to the queue are replicated to all
          slaves. Consumers are connected to the master regardless of
          which node they connect to, with slaves dropping messages
          that have been acknowledged at the master. Queue mirroring
          therefore enhances availability, but does not distribute
          load across nodes (all participating nodes each do all the
          work).
        </p>
        <p>
          This solution requires a RabbitMQ cluster, which means that
          it will not cope seamlessly with network partitions within
          the cluster and, for that reason, is not recommended for use
          across a WAN (though of course, clients can still connect
          from as near and as far as needed).
        </p>
      </doc:section>

      <doc:section name="genesis">
        <doc:heading>Configuring Mirroring</doc:heading>
        <p>
          Queues have mirroring enabled
          via <a href="parameters.html#policies">policy</a>. Policies
          can change at any time; it is valid to create a non-mirrored
          queue, and then make it mirrored at some later point (and
          vice versa). There is a difference between a non-mirrored
          queue and a mirrored queue which does not have any slaves -
          the former lacks the extra mirroring infrastructure and will
          run faster.
        </p>
        <p>
          You should be aware of the behaviour
          of <a href="#unsynchronised-slaves">adding mirrors to a
          queue</a>.
        </p>
        <p>
          To cause queues to become mirrored, you should create a
          policy which matches them and sets policy
          keys <code>ha-mode</code> and
          (optionally) <code>ha-params</code>. The following table
          explains the options for these keys:
        </p>

        <table>
          <tr>
            <th><code>ha-mode</code></th>
            <th><code>ha-params</code></th>
            <th>Result</th>
          </tr>
          <tr>
            <td><code>all</code></td>
            <td>(absent)</td>
            <td>
              Queue is mirrored across all nodes in the
              cluster. When a new node is added to the cluster, the
              queue will be mirrored to that node.
            </td>
          </tr>
          <tr>
            <td><code>exactly</code></td>
            <td><i>count</i></td>
            <td>
              Queue is mirrored to <i>count</i> nodes in the
              cluster. If there are less than <i>count</i> nodes in
              the cluster, the queue is mirrored to all nodes. If
              there are more than <i>count</i> nodes in the cluster,
              and a node containing a mirror goes down, then a new
              mirror will be created on another node. Use of
              <code>exactly</code> mode with <a
              href="#cluster-shutdown"><code>"ha-promote-on-shutdown":
              "always"</code></a> can be dangerous since queues can
              migrate across a cluster and become unsynced as it is
              brought down.
            </td>
          </tr>
          <tr>
            <td><code>nodes</code></td>
            <td><i>node names</i></td>
            <td>
              Queue is mirrored to the nodes listed in <i>node
              names</i>. If any of those node names are not a part of
              the cluster, this does not constitute an error. If none
              of the nodes in the list are online at the time when the
              queue is declared then the queue will be created on the
              node that the declaring client is connected to.
            </td>
          </tr>
        </table>

        <p>
          Whenever the HA policy for a queue changes it will endeavour
          to keep its existing mirrors as far as this fits with the new
          policy.
        </p>

        <h3 id="queue-master-location">Queue Master Location</h3>
        <p>
          Every queue in RabbitMQ has a home node. That node is called
          <em>queue master</em>. All queue operations go through the master
          first and then are replicated to mirrors. This is necessary to
          guarantee FIFO ordering of messages.
        </p>
        <p>
          Queue masters can be distributed between nodes using several
          strategies. Which strategy is used is controlled in three ways,
          namely, using the <code>x-queue-master-locator</code> queue
          declare argument, setting the <code>queue-master-locator</code>
          policy key or by defining the <code>queue_master_locator<code>
          key in <code>rabbit.config<code>. Here are the
          possible strategies and how to set them:

          <ul>
            <li>Pick the node hosting the minimum number of masters:
            <code>min-masters</code></li>
            <li>Pick the node the client that declares the queue is
            connected to: <code>client-local</code></li>
            <li>Pick a random node: <code>random</code></li>
{'fraction_non_alphanumeric': 0.07887027717268835, 'fraction_numerical': 0.0034552692856606323, 'mean_word_length': 1.9626168224299065, 'pattern_counts': {'":': 2, '<': 261, '<?xml version=': 0, '>': 261, 'https://': 0, 'lorem ipsum': 0, 'www.': 8, 'xml': 10}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1814634', 'n_tokens_mistral': 3482, 'n_tokens_neox': 3355, 'n_words': 1521}