#### 18.2.1.2 Configuring an Instance for Group Replication

[]()

 This section explains the configuration settings required for MySQL Server instances that you want to use for Group Replication. For background information, see [Section 18.3, “Requirements and Limitations”](group-replication-requirements-and-limitations.html).

* [Storage Engines](group-replication-configuring-instances.html#group-replication-storage-engines)

* [Replication Framework](group-replication-configuring-instances.html#group-replication-configure-replication-framework)

* [Group Replication Settings](group-replication-configuring-instances.html#group-replication-configure-plugin)

##### Storage Engines

 For Group Replication, data must be stored in the InnoDB transactional storage engine (for details of why, see [Section 18.3.1, “Group Replication Requirements”](group-replication-requirements.html)). The use of other storage engines, including the temporary [`MEMORY`](memory-storage-engine.html) storage engine, might cause errors in Group Replication. Set the [`disabled_storage_engines`](server-system-variables.html#sysvar_disabled_storage_engines) system variable as follows to prevent their use:

```
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
```

 Note that with the [`MyISAM`](myisam-storage-engine.html) storage engine disabled, when you are upgrading a MySQL instance to a release where [**mysql\_upgrade**](mysql-upgrade.html) is still used (before MySQL 8.0.16), [**mysql\_upgrade**](mysql-upgrade.html) might fail with an error. To handle this, you can re-enable that storage engine while you run [**mysql\_upgrade**](mysql-upgrade.html), then disable it again when you restart the server. For more information, see [Section 4.4.5, “mysql\_upgrade — Check and Upgrade MySQL Tables”](mysql-upgrade.html).

##### Replication Framework

 The following settings configure replication according to the MySQL Group Replication requirements.

```
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
```

 These settings configure the server to use the unique identifier number 1, to enable [Section 17.1.3, “Replication with Global Transaction Identifiers”](replication-gtids.html), and to allow execution of only statements that can be safely logged using a GTID.

 Up to and including MySQL 8.0.20, the following setting is also required:

```
binlog_checksum=NONE
```

 This setting disables checksums for events written to the binary log, which default to being enabled. From MySQL 8.0.21, Group Replication supports the presence of checksums in the binary log and can use them to verify the integrity of events on some channels, so you can use the default setting. For more details, see [Section 18.3.2, “Group Replication Limitations”](group-replication-limitations.html).

 If you are using a version of MySQL earlier than 8.0.3, where the defaults were improved for replication, you also need to add these lines to the member's option file. If you have any of these system variables in the option file in later versions, ensure that they are set as shown. For more details see [Section 18.3.1, “Group Replication Requirements”](group-replication-requirements.html).

```
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction_write_set_extraction=XXHASH64
```

##### Group Replication Settings

 At this point the option file ensures that the server is configured and is instructed to instantiate the replication infrastructure under a given configuration. The following section configures the Group Replication settings for the server.

```
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s1:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group=off
```

* `plugin-load-add` adds the Group Replication plugin to the list of plugins which the server loads at startup. This is preferable in a production deployment to installing the plugin manually.

* Configuring [`group_replication_group_name`](group-replication-options.html#sysvar_group_replication_group_name) tells the plugin that the group that it is joining, or creating, is named "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa".

   The value of [`group_replication_group_name`](group-replication-options.html#sysvar_group_replication_group_name) must be a valid UUID. You can use `SELECT UUID()` to generate one. This UUID forms part of the GTIDs that are used when transactions received by group members from clients, and view change events that are generated internally by the group members, are written to the binary log.

* Configuring the [`group_replication_start_on_boot`](group-replication-options.html#sysvar_group_replication_start_on_boot) variable to `off` instructs the plugin to not start operations automatically when the server starts. This is important when setting up Group Replication as it ensures you can configure the server before manually starting the plugin. Once the member is configured you can set [`group_replication_start_on_boot`](group-replication-options.html#sysvar_group_replication_start_on_boot) to `on` so that Group Replication starts automatically upon server boot.

* Configuring [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) sets the network address and port which the member uses for internal communication with other members in the group. Group Replication uses this address for internal member-to-member connections involving remote instances of the group communication engine (XCom, a Paxos variant).

  Important

   The group replication local address must be different to the host name and port used for SQL client connections, which are defined by MySQL Server's [`hostname`](server-system-variables.html#sysvar_hostname) and [`port`](server-system-variables.html#sysvar_port) system variables. It must not be used for client applications. It must be only be used for internal communication between the members of the group while running Group Replication.

   The network address configured by [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) must be resolvable by all group members. For example, if each server instance is on a different machine with a fixed network address, you could use the IP address of the machine, such as 10.0.0.1. If you use a host name, you must use a fully qualified name, and ensure it is resolvable through DNS, correctly configured `/etc/hosts` files, or other name resolution processes. From MySQL 8.0.14, IPv6 addresses (or host names that resolve to them) can be used as well as IPv4 addresses. A group can contain a mix of members using IPv6 and members using IPv4. For more information on Group Replication support for IPv6 networks and on mixed IPv4 and IPv6 groups, see [Section 18.5.5, “Support For IPv6 And For Mixed IPv6 And IPv4 Groups”](group-replication-ipv6.html).

   The recommended port for [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) is 33061. [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) is used by Group Replication as the unique identifier for a group member within the replication group. You can use the same port for all members of a replication group as long as the host names or IP addresses are all different, as demonstrated in this tutorial. Alternatively you can use the same host name or IP address for all members as long as the ports are all different, for example as shown in [Section 18.2.2, “Deploying Group Replication Locally”](group-replication-deploying-locally.html).

   The connection that an existing member offers to a joining member for Group Replication's distributed recovery process is not the network address configured by [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address). Up to MySQL 8.0.20, group members offer their standard SQL client connection to joining members for distributed recovery, as specified by MySQL Server's [`hostname`](server-system-variables.html#sysvar_hostname) and [`port`](server-system-variables.html#sysvar_port) system variables. From MySQL 8.0.21, group members may advertise an alternative list of distributed recovery endpoints as dedicated client connections for joining members. For more details, see [Section 18.5.4.1, “Connections for Distributed Recovery”](group-replication-distributed-recovery-connections.html).

  Important

   Distributed recovery can fail if a joining member cannot correctly identify the other members using the host name as defined by MySQL Server's [`hostname`](server-system-variables.html#sysvar_hostname) system variable. It is recommended that operating systems running MySQL have a properly configured unique host name, either using DNS or local settings. The host name that the server is using for SQL client connections can be verified in the `Member_host` column of the Performance Schema table [`replication_group_members`](performance-schema-replication-group-members-table.html). If multiple group members externalize a default host name set by the operating system, there is a chance of the joining member not resolving it to the correct member address and not being able to connect for distributed recovery. In this situation you can use MySQL Server's [`report_host`](replication-options-replica.html#sysvar_report_host) system variable to configure a unique host name to be externalized by each of the servers.

* Configuring [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds) sets the hostname and port of the group members which are used by the new member to establish its connection to the group. These members are called the seed members. Once the connection is established, the group membership information is listed in the Performance Schema table [`replication_group_members`](performance-schema-replication-group-members-table.html). Usually the [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds) list contains the `hostname:port` of each of the group member's [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address), but this is not obligatory and a subset of the group members can be chosen as seeds.

  Important

   The `hostname:port` listed in [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds) is the seed member's internal network address, configured by [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) and not the `hostname:port` used for SQL client connections, which is shown for example in the Performance Schema table [`replication_group_members`](performance-schema-replication-group-members-table.html).

   The server that starts the group does not make use of this option, since it is the initial server and as such, it is in charge of bootstrapping the group. In other words, any existing data which is on the server bootstrapping the group is what is used as the data for the next joining member. The second server joining asks the one and only member in the group to join, any missing data on the second server is replicated from the donor data on the bootstrapping member, and then the group expands. The third server joining can ask any of these two to join, data is synchronized to the new member, and then the group expands again. Subsequent servers repeat this procedure when joining.

  Warning

   When joining multiple servers at the same time, make sure that they point to seed members that are already in the group. Do not use members that are also joining the group as seeds, because they might not yet be in the group when contacted.

   It is good practice to start the bootstrap member first, and let it create the group. Then make it the seed member for the rest of the members that are joining. This ensures that there is a group formed when joining the rest of the members.

   Creating a group and joining multiple members at the same time is not supported. It might work, but chances are that the operations race and then the act of joining the group ends up in an error or a time out.

   A joining member must communicate with a seed member using the same protocol (IPv4 or IPv6) that the seed member advertises in the [`group_replication_group_seeds`](group-replication-options.html#sysvar_group_replication_group_seeds) option. For the purpose of IP address permissions for Group Replication, the allowlist on the seed member must include an IP address for the joining member for the protocol offered by the seed member, or a host name that resolves to an address for that protocol. This address or host name must be set up and permitted in addition to the joining member's [`group_replication_local_address`](group-replication-options.html#sysvar_group_replication_local_address) if the protocol for that address does not match the seed member's advertised protocol. If a joining member does not have a permitted address for the appropriate protocol, its connection attempt is refused. For more information, see [Section 18.6.4, “Group Replication IP Address Permissions”](group-replication-ip-address-permissions.html).

* Configuring [`group_replication_bootstrap_group`](group-replication-options.html#sysvar_group_replication_bootstrap_group) instructs the plugin whether to bootstrap the group or not. In this case, even though s1 is the first member of the group we set this variable to off in the option file. Instead we configure [`group_replication_bootstrap_group`](group-replication-options.html#sysvar_group_replication_bootstrap_group) when the instance is running, to ensure that only one member actually bootstraps the group.

  Important

   The [`group_replication_bootstrap_group`](group-replication-options.html#sysvar_group_replication_bootstrap_group) variable must only be enabled on one server instance belonging to a group at any time, usually the first time you bootstrap the group (or in case the entire group is brought down and back up again). If you bootstrap the group multiple times, for example when multiple server instances have this option set, then they could create an artificial split brain scenario, in which two distinct groups with the same name exist. Always set [`group_replication_bootstrap_group=off`](group-replication-options.html#sysvar_group_replication_bootstrap_group) after the first server instance comes online.

 The system variables described in this tutorial are the required configuration settings to start a new member, but further system variables are also available to configure group members. These are listed in [Section 18.9, “Group Replication System Variables”](group-replication-options.html).

Important

 A number of system variables, some specific to Group Replication and others not, are group-wide configuration settings that must have the same value on all group members. If the group members have a value set for one of these system variables, and a joining member has a different value set for it, the joining member cannot join the group and an error message is returned. If the group members have a value set for this system variable, and the joining member does not support the system variable, it cannot join the group. These system variables are all identified in [Section 18.9, “Group Replication System Variables”](group-replication-options.html).

