<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h2 class="title">
      <a name="group-replication-frequently-asked-questions">
      </a>
      20.10 Frequently Asked Questions
     </h2>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045128294032">
  </a>
  <p>
   This section provides answers to frequently asked questions.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-maximum-number-servers">
       </a>
       What is the maximum number of MySQL servers in a group?
      </h3>
     </div>
    </div>
   </div>
   <p>
    A group can consist of maximum 9 servers. Attempting to add
      another server to a group with 9 members causes the request to
      join to be refused. This limit has been identified from testing
      and benchmarking as a safe boundary where the group performs
      reliably on a stable local area network.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-servers-in-a-group-connected">
       </a>
       How are servers in a group connected?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Servers in a group connect to the other servers in the group by
      opening a peer-to-peer TCP connection. These connections are only
      used for internal communication and message passing between
      servers in the group. This address is configured by the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
     <code class="literal">
      group_replication_local_address
     </code>
    </a>
    variable.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-what-is-the-group-replication-bootstrap-group-option-used-for">
       </a>
       What is the group_replication_bootstrap_group option used for?
      </h3>
     </div>
    </div>
   </div>
   <p>
    The bootstrap flag instructs a member to
    <span class="emphasis">
     <em>
      create
     </em>
    </span>
    a group and act as the initial seed
      server. The second member joining the group needs to ask the
      member that bootstrapped the group to dynamically change the
      configuration in order for it to be added to the group.
   </p>
   <p>
    A member needs to bootstrap the group in two scenarios. When the
      group is originally created, or when shutting down and restarting
      the entire group.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-credentials-for-recovery">
       </a>
       How do I set credentials for the distributed recovery process?
      </h3>
     </div>
    </div>
   </div>
   <p>
    You can set the user credentials permanently as the credentials
      for the
    <code class="literal">
     group_replication_recovery
    </code>
    channel,
      using a
    <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
     <code class="literal">
      CHANGE REPLICATION SOURCE
      TO
     </code>
    </a>
    statement. You can specify them in the
    <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
     <code class="literal">
      START GROUP_REPLICATION
     </code>
    </a>
    statement
      each time Group Replication is started.
   </p>
   <p>
    User credentials set using
    <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
     <code class="literal">
      CHANGE REPLICATION
      SOURCE TO
     </code>
    </a>
    are stored in plain text in the replication
      metadata repositories on the server, but user credentials
      specified on
    <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
     <code class="literal">
      START
      GROUP_REPLICATION
     </code>
    </a>
    are saved in memory only, and are
      removed by a
    <a class="link" href="stop-group-replication.html" title="15.4.3.2 STOP GROUP_REPLICATION Statement">
     <code class="literal">
      STOP GROUP_REPLICATION
     </code>
    </a>
    statement or server shutdown. Using
    <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
     <code class="literal">
      START
      GROUP_REPLICATION
     </code>
    </a>
    to specify the user credentials
      therefore helps to secure the Group Replication servers against
      unauthorized access. However, this method is not compatible with
      starting Group Replication automatically, as specified by the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_start_on_boot">
     <code class="literal">
      group_replication_start_on_boot
     </code>
    </a>
    system variable. For more information, see
    <a class="xref" href="group-replication-secure-user.html" title="20.6.3.1 Secure User Credentials for Distributed Recovery">
     Section 20.6.3.1, “Secure User Credentials for Distributed Recovery”
    </a>
    .
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-scale-out-write-load">
       </a>
       Can I scale-out my write-load using Group Replication?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Not directly, but MySQL Group replication is a shared nothing full
      replication solution, where all servers in the group replicate the
      same amount of data. Therefore if one member in the group writes N
      bytes to storage as the result of a transaction commit operation,
      then roughly N bytes are written to storage on other members as
      well, because the transaction is replicated everywhere.
   </p>
   <p>
    However, given that other members do not have to do the same
      amount of processing that the original member had to do when it
      originally executed the transaction, they apply the changes
      faster. Transactions are replicated in a format that is used to
      apply row transformations only, without having to re-execute
      transactions again (row-based format).
   </p>
   <p>
    Furthermore, given that changes are propagated and applied in
      row-based format, this means that they are received in an
      optimized and compact format, and likely reducing the number of IO
      operations required when compared to the originating member.
   </p>
   <p>
    To summarize, you can scale-out processing, by spreading conflict
      free transactions throughout different members in the group. And
      you can likely scale-out a small fraction of your IO operations,
      since remote servers receive only the necessary changes to
      read-modify-write changes to stable storage.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-performance-compared">
       </a>
       Does Group Replication require more network bandwidth and CPU, when
compared to simple replication and under the same workload?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Some additional load is expected because servers need to be
      constantly interacting with each other for synchronization
      purposes. It is difficult to quantify how much more data. It also
      depends on the size of the group (three servers puts less stress
      on the bandwidth requirements than nine servers in the group).
   </p>
   <p>
    Also the memory and CPU footprint are larger, because more complex
      work is done for the server synchronization part and for the group
      messaging.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-deploy-across-wide-area-network">
       </a>
       Can I deploy Group Replication across wide-area networks?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Yes, but the network connection between each member
    <span class="emphasis">
     <em>
      must
     </em>
    </span>
    be reliable and have suitable
      performance. Low latency, high bandwidth network connections are a
      requirement for optimal performance.
   </p>
   <p>
    If network bandwidth alone is an issue, then
    <a class="xref" href="group-replication-message-compression.html" title="20.7.4 Message Compression">
     Section 20.7.4, “Message Compression”
    </a>
    can be
      used to lower the bandwidth required. However, if the network
      drops packets, leading to re-transmissions and higher end-to-end
      latency, throughput and latency are both negatively affected.
   </p>
   <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
    <div class="admon-title">
     Warning
    </div>
    <p>
     When the network round-trip time (RTT) between any group members
        is 5 seconds or more you could encounter problems as the
        built-in failure detection mechanism could be incorrectly
        triggered.
    </p>
   </div>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-automatically-rejoin-temporary-problems">
       </a>
       Do members automatically rejoin a group in case of temporary
connectivity problems?
      </h3>
     </div>
    </div>
   </div>
   <p>
    This depends on the reason for the connectivity problem. If the
      connectivity problem is transient and the reconnection is quick
      enough that the failure detector is not aware of it, then the
      server may not be removed from the group. If it is a
      "long" connectivity problem, then the failure detector
      eventually suspects a problem and the server is removed from the
      group.
   </p>
   <p>
    Two settings are available to increase the chances of a member
      remaining in or rejoining a group:
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_member_expel_timeout">
        <code class="literal">
         group_replication_member_expel_timeout
        </code>
       </a>
       increases the time between the creation of a suspicion (which
          happens after an initial 5-second detection period) and the
          expulsion of the member. You can set a waiting period of up to
          1 hour. A waiting period of 5 seconds is set by default.
      </p>
     </li>
     <li class="listitem">
      <p>
       <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_autorejoin_tries">
        <code class="literal">
         group_replication_autorejoin_tries
        </code>
       </a>
       makes a member try to rejoin the group after an expulsion or
          unreachable majority timeout. The member makes the specified
          number of auto-rejoin attempts five minutes apart. This
          feature is active by default; the member makes three
          auto-rejoin attempts.
      </p>
     </li>
    </ul>
   </div>
   <p>
    If a server is expelled from the group and any auto-rejoin
      attempts do not succeed, you need to join it back again. In other
      words, after a server is removed explicitly from the group you
      need to rejoin it manually (or have a script doing it
      automatically).
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-member-excluded">
       </a>
       When is a member excluded from a group?
      </h3>
     </div>
    </div>
   </div>
   <p>
    If the member becomes silent, the other members remove it from the
      group configuration. In practice this may happen when the member
      has crashed or there is a network disconnection.
   </p>
   <p>
    The failure is detected after a given timeout elapses for a given
      member and a new configuration without the silent member in it is
      created.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-node-lag">
       </a>
       What happens when one node is significantly lagging behind?
      </h3>
     </div>
    </div>
   </div>
   <p>
    There is no method for defining policies for when to expel members
      automatically from the group. You need to find out why a member is
      lagging behind and fix that or remove the member from the group.
      Otherwise, if the server is so slow that it triggers the flow
      control, then the entire group slows down as well. The flow
      control can be configured according to the your needs.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-member-responsible-reconfiguration">
       </a>
       Upon suspicion of a problem in the group, is there a special member
responsible for triggering a reconfiguration?
      </h3>
     </div>
    </div>
   </div>
   <p>
    No, there is no special member in the group in charge of
      triggering a reconfiguration.
   </p>
   <p>
    Any member can suspect that there is a problem. All members need
      to (automatically) agree that a given member has failed. One
      member is in charge of expelling it from the group, by triggering
      a reconfiguration. Which member is responsible for expelling the
      member is not something you can control or set.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-provide-sharding">
       </a>
       Can I use Group Replication for sharding?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Group Replication is designed to provide highly available replica
      sets; data and writes are duplicated on each member in the group.
      For scaling beyond what a single system can provide, you need an
      orchestration and sharding framework built around a number of
      Group Replication sets, where each replica set maintains and
      manages a given shard or partition of your total dataset. This
      type of setup, often called a
    <span class="quote">
     “
     <span class="quote">
      sharded cluster
     </span>
     ”
    </span>
    ,
      allows you to scale reads and writes linearly and without limit.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-using-selinux">
       </a>
       How do I use Group Replication with SELinux?
      </h3>
     </div>
    </div>
   </div>
   <p>
    If SELinux is enabled, which you can verify using
    <span class="command">
     <strong>
      sestatus -v
     </strong>
    </span>
    , then you need to enable the use of
      the Group Replication communication port. See
    <a class="xref" href="selinux-context-mysql-feature-ports.html#selinux-context-group-replication-port" title="Setting the TCP Port Context for Group Replication">
     Setting the TCP Port Context for Group Replication
    </a>
    .
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-using-iptables">
       </a>
       How do I use Group Replication with iptables?
      </h3>
     </div>
    </div>
   </div>
   <p>
    If
    <span class="command">
     <strong>
      iptables
     </strong>
    </span>
    is enabled, then you need to open
      up the Group Replication port for communication between the
      machines. To see the current rules in place on each machine, issue
    <span class="command">
     <strong>
      iptables -L
     </strong>
    </span>
    . Assuming the port configured is
      33061, enable communication over the necessary port by issuing
    <span class="command">
     <strong>
      iptables -A INPUT -p tcp --dport 33061 -j
      ACCEPT
     </strong>
    </span>
    .
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-recover-relay-log">
       </a>
       How do I recover the relay log for a replication channel used by a group
member?
      </h3>
     </div>
    </div>
   </div>
   <p>
    The replication channels used by Group Replication behave in the
      same way as replication channels used in asynchronous source to
      replica replication, and as such rely on the relay log. In the
      event of a change of the
    <a class="link" href="replication-options-replica.html#sysvar_relay_log">
     <code class="literal">
      relay_log
     </code>
    </a>
    variable, or when the
      option is not set and the host name changes, there is a chance of
      errors. See
    <a class="xref" href="replica-logs-relaylog.html" title="19.2.4.1 The Relay Log">
     Section 19.2.4.1, “The Relay Log”
    </a>
    for a recovery
      procedure in this situation. Alternatively, another way of fixing
      the issue specifically in Group Replication is to issue a
    <a class="link" href="stop-group-replication.html" title="15.4.3.2 STOP GROUP_REPLICATION Statement">
     <code class="literal">
      STOP GROUP_REPLICATION
     </code>
    </a>
    statement
      and then a
    <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
     <code class="literal">
      START GROUP_REPLICATION
     </code>
    </a>
    statement to restart the instance. The Group Replication plugin
      creates the
    <code class="literal">
     group_replication_applier
    </code>
    channel
      again.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-two-bind-addresses">
       </a>
       Why does Group Replication use two bind addresses?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Group Replication uses two bind addresses in order to split
      network traffic between the SQL address, used by clients to
      communicate with the member, and the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
     <code class="literal">
      group_replication_local_address
     </code>
    </a>
    ,
      used internally by the group members to communicate. For example,
      assume a server with two network interfaces assigned to the
      network addresses
    <code class="literal">
     203.0.113.1
    </code>
    and
    <code class="literal">
     198.51.100.179
    </code>
    . In such a situation you could
      use
    <code class="literal">
     203.0.113.1:33061
    </code>
    for the internal group
      network address by setting
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
     <code class="literal">
      group_replication_local_address=203.0.113.1:33061
     </code>
    </a>
    .
      Then you could use
    <code class="literal">
     198.51.100.179
    </code>
    for
    <a class="link" href="server-system-variables.html#sysvar_hostname">
     <code class="literal">
      hostname
     </code>
    </a>
    and
    <code class="literal">
     3306
    </code>
    for the
    <a class="link" href="server-system-variables.html#sysvar_port">
     <code class="literal">
      port
     </code>
    </a>
    . Client SQL applications
      would then connect to the member at
    <code class="literal">
     198.51.100.179:3306
    </code>
    . This enables you to
      configure different rules on the different networks. Similarly,
      the internal group communication can be separated from the network
      connection used for client applications, for increased security.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-hostnames">
       </a>
       How does Group Replication use network addresses and hostnames?
      </h3>
     </div>
    </div>
   </div>
   <p>
    Group Replication uses network connections between members and
      therefore its functionality is directly impacted by how you
      configure hostnames and ports. For example, Group Replication's
      distributed recovery process creates a connection to an existing
      group member using the server's hostname and port. When a member
      joins a group it receives the group membership information, using
      the network address information that is listed at
    <a class="link" href="performance-schema-replication-group-members-table.html" title="29.12.11.16 The replication_group_members Table">
     <code class="literal">
      performance_schema.replication_group_members
     </code>
    </a>
    .
      One of the members listed in that table is selected as the donor
      of the missing data from the group to the joining member.
   </p>
   <p>
    This means that any value you configure using a hostname, such as
      the SQL network address or the group seeds address, must be a
      fully qualified name and resolvable by each member of the group.
      You can ensure this for example through DNS, or correctly
      configured
    <code class="filename">
     /etc/hosts
    </code>
    files, or other local
      processes. If a you want to configure the
    <code class="literal">
     MEMBER_HOST
    </code>
    value on a server, specify it using
      the
    <a class="link" href="replication-options-replica.html#sysvar_report_host">
     <code class="option">
      --report-host
     </code>
    </a>
    option on the
      server before joining it to the group.
   </p>
   <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
    <div class="admon-title">
     Important
    </div>
    <p>
     The assigned value is used directly and is not affected by the
     <a class="link" href="server-system-variables.html#sysvar_skip_name_resolve">
      <code class="literal">
       skip_name_resolve
      </code>
     </a>
     system
        variable.
    </p>
   </div>
   <p>
    To configure
    <code class="literal">
     MEMBER_PORT
    </code>
    on a server, specify
      it using the
    <a class="link" href="replication-options-replica.html#sysvar_report_port">
     <code class="literal">
      report_port
     </code>
    </a>
    system
      variable.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-auto-increment-increment">
       </a>
       Why did the auto increment setting on the server change?
      </h3>
     </div>
    </div>
   </div>
   <p>
    When Group Replication is started on a server, the value of
    <a class="link" href="replication-options-source.html#sysvar_auto_increment_increment">
     <code class="literal">
      auto_increment_increment
     </code>
    </a>
    is
      changed to the value of
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_auto_increment_increment">
     <code class="literal">
      group_replication_auto_increment_increment
     </code>
    </a>
    ,
      which defaults to 7, and the value of
    <a class="link" href="replication-options-source.html#sysvar_auto_increment_offset">
     <code class="literal">
      auto_increment_offset
     </code>
    </a>
    is changed
      to the server ID. The changes are reverted when Group Replication
      is stopped. These settings avoid the selection of duplicate
      auto-increment values for writes on group members, which causes
      rollback of transactions. The default auto increment value of 7
      for Group Replication represents a balance between the number of
      usable values and the permitted maximum size of a replication
      group (9 members).
   </p>
   <p>
    The changes are made and reverted only if
    <a class="link" href="replication-options-source.html#sysvar_auto_increment_increment">
     <code class="literal">
      auto_increment_increment
     </code>
    </a>
    and
    <a class="link" href="replication-options-source.html#sysvar_auto_increment_offset">
     <code class="literal">
      auto_increment_offset
     </code>
    </a>
    each has
      its default value (1 in both cases). If their values have already
      been modified from the default, Group Replication does not alter
      them. The system variables are also not modified when Group
      Replication is in single-primary mode, where only one server
      writes.
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h3 class="title">
       <a name="group-replication-how-to-find-primary">
       </a>
       How do I find the primary?
      </h3>
     </div>
    </div>
   </div>
   <p>
    If the group is operating in single-primary mode, it can be useful
      to find out which member is the primary. See
    <a class="xref" href="group-replication-single-primary-mode.html#group-replication-find-primary" title="20.1.3.1.2 Finding the Primary">
     Section 20.1.3.1.2, “Finding the Primary”
    </a>
   </p>
  </div>
 </div>
 <br/>
</div>
