18.7 Group Replication System Variables

group_replication_allow_local_disjoint_gtids_join

Removed in version 8.0.4. Allow the current server to join the group even if it has transactions not present in the group.

group_replication_allow_local_lower_version_join

Allow the current server to join the group even if it has a lower plugin version than the group.

group_replication_auto_increment_increment

Determines the interval between successive column values for transactions that execute on this server instance.

group_replication_bootstrap_group

Configure this server to bootstrap the group. This option must only be set on one server and only when starting the group for the first time or restarting the entire group. After the group has been bootstrapped, set this option to OFF. It should be set to OFF both dynamically and in the configuration files. Starting two servers or restarting one server with this option set while the group is running may lead to an artificial split brain situation, where two independent groups with the same name are bootstrapped.

group_replication_communication_debug_options

Configures the level of debugging messages to provide for the different Group Replication components, such as Group Communication System (GCS) and the group communication engine (XCom, a Paxos variant). The debug information is stored in the GCS_DEBUG_TRACE file in the data directory.

The set of available options, specified as strings, can be combined. The following options are available:

Setting the debug level to GCS_DEBUG_NONE only has an effect when provided without any other option. Setting the debug level to GCS_DEBUG_ALL overrides all other options.

group_replication_components_stop_timeout

Timeout, in seconds, that Group Replication waits for each of the components when shutting down.

group_replication_compression_threshold

The value in bytes above which (LZ4) compression is enforced. When set to zero, deactivates compression.

group_replication_consistency

Controls how newly elected primaries behave, and is relevant only in single-primary groups. When group_replication_consistency is set to EVENTUAL, a new primary responds to read requests even when there is a backlog which has not yet been applied, which comes with the risk that a client could read old values while any backlog is being applied. Writes to the new primary fail during this period because it is has super_read_only mode enabled. When group_replication_consistency is set to BEFORE_ON_PRIMARY_FAILOVER, any new read queries against a newly elected primary that is applying backlog from the old primary are held until the backlog is applied. This ensures that clients always read the newest value which they have written, but also means that clients might have to wait until the backlog has been applied before they can read from the new primary.

group_replication_enforce_update_everywhere_checks

Enable or disable strict consistency checks for multi-primary update everywhere.

group_replication_exit_state_action

Configures how Group Replication behaves when a server instance leaves the group unintentionally, for example after encountering an applier error, or when another member of the group expels it due to a suspicion timing out. The timeout period for suspicions is set by the group_replication_member_expel_timeout system variable.

When group_replication_exit_state_action is set to ABORT_SERVER, upon exiting the group unintentionally, the instance shuts down MySQL. When group_replication_exit_state_action is set to READ_ONLY, the instance switches MySQL to super read only mode instead.

group_replication_flow_control_applier_threshold

Specifies the number of waiting transactions in the applier queue that trigger flow control. This variable can be changed without resetting Group Replication.

group_replication_flow_control_certifier_threshold

Specifies the number of waiting transactions in the certifier queue that trigger flow control. This variable can be changed without resetting Group Replication.

group_replication_flow_control_hold_percent

Defines what percentage of the group quota remains unused to allow a cluster under flow control to catch up on backlog. A value of 0 implies that no part of the quota is reserved for catching up on the work backlog.

group_replication_flow_control_max_commit_quota

Defines the maximum flow control quota of the group, or the maximum available quota for any period while flow control is enabled. A value of 0 implies that there is no maximum quota set. Cannot be smaller than group_replication_flow_control_min_quota and group_replication_flow_control_min_recovery_quota.

group_replication_flow_control_member_quota_percent

Defines the percentage of the quota that a member should assume is available for itself when calculating the quotas. A value of 0 implies that the quota should be split equally between members that were writers in the last period.

group_replication_flow_control_min_quota

Controls the lowest flow control quota that can be assigned to a member, independently of the calculated minimum quota executed in the last period. A value of 0 implies that there is no minimum quota. Cannot be larger than group_replication_flow_control_max_commit_quota.

group_replication_flow_control_min_recovery_quota

Controls the lowest quota that can be assigned to a member because of another recovering member in the group, independently of the calculated minimum quota executed in the last period. A value of 0 implies that there is no minimum quota. Cannot be larger than group_replication_flow_control_max_commit_quota.

group_replication_flow_control_mode

Specifies the mode used for flow control. This variable can be changed without resetting Group Replication.

group_replication_flow_control_period

Defines how many seconds to wait between flow control iterations, in which flow control messages are sent and flow control management tasks are run.

group_replication_flow_control_release_percent

Defines how the group quota should be released when flow control no longer needs to throttle the writer members, with this percentage being the quota increase per flow control period. A value of 0 implies that once the flow control thresholds are within limits the quota is released in a single flow control iteration. The range allows the quota to be released at up to 10 times current quota, as that allows a greater degree of adaptation, mainly when the flow control period is large and the quotas are very small.

group_replication_force_members

A list of peer addresses as a comma separated list such as host1:port1,host2:port2. This option is used to force a new group membership, in which the excluded members do not receive a new view and are blocked. (You need to manually kill the excluded servers.) Any invalid host names in the list could cause this action to fail because they could block group membership. For a description of the procedure to follow, see Section 18.4.4, “Network Partitioning”.

You must specify the address or host name and port as they are given in the group_replication_local_address option for each member. An IPv6 address must be specified in square brackets. For example:

"198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061,example.org:33061"

After you have used the group_replication_force_members system variable to successfully force a new group membership and unblock the group, ensure that you clear the system variable. group_replication_force_members must be empty in order to issue a START GROUP_REPLICATION statement.

group_replication_group_name

The name of the group which this server instance belongs to. Must be a valid UUID. This UUID is used internally when setting GTIDs for Group Replication events in the binary log.

group_replication_group_seeds

A list of group members that provide a member which joins the group with the data required for the joining member to gain synchrony with the group. The list consists of a single internal network address or host name for each included seed member, as configured in the seed member's group_replication_local_address system variable (not the seed member's SQL hostname and port). The addresses of the seed members are specified as a comma separated list, such as host1:port1,host2:port2. An IPv6 address must be specified in square brackets. For example:

group_replication_group_seeds= "198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061, example.org:33061"

Note that the value you specify for this variable is not validated until a START GROUP_REPLICATION statement is issued and the Group Communication System (GCS) is available.

Usually this list consists of all members of the group, but you can choose a subset of the group members to be seeds. The list must contain at least one valid member address. Each address is validated when starting Group Replication. If the list does not contain any valid member addresses, issuing START GROUP_REPLICATION fails.

When a server is joining a replication group, it attempts to connect to the first seed member listed in its group_replication_group_seeds system variable. If the connection is refused, the joining member tries to connect to each of the other seed members in the list in order. If the joining member connects to a seed member but does not get added to the replication group as a result (for example, because the seed member does not have the joining member's address in its whitelist and closes the connection), the joining member continues to try the remaining seed members in the list in order.

A joining member must communicate with the seed member using the same protocol (IPv4 or IPv6) that the seed member advertises in the group_replication_group_seeds option. For the purpose of IP address whitelisting for Group Replication, the whitelist 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 whitelisted in addition to the joining member's 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 whitelisted address for the appropriate protocol, its connection attempt is refused. For more information, see Section 18.5.1, “IP Address Whitelisting”.

group_replication_gtid_assignment_block_size

The number of consecutive GTIDs that are reserved for each member. Each member consumes its blocks and reserves more when needed.

group_replication_ip_whitelist

Specifies which hosts are permitted to connect to the group. Note that the value you specify for this variable is not validated until a START GROUP_REPLICATION statement is issued and the Group Communication System (GCS) is available.

By default, this system variable is set to AUTOMATIC, which permits connections from private subnetworks active on the host. The group communication engine (XCom) automatically scans active interfaces on the host, and identifies those with addresses on private subnetworks. These addresses and the localhost IP address for IPv4 and (from MySQL 8.0.14) IPv6 are used to create the Group Replication whitelist. For a list of the ranges from which addresses are automatically whitelisted, see Section 18.5.1, “IP Address Whitelisting”.

The automatic whitelist of private addresses cannot be used for connections from servers outside the private network. For Group Replication connections between server instances that are on different machines, you must provide public IP addresses and specify these as an explicit whitelist. If you specify any entries for the whitelist, the private and localhost addresses are not added automatically, so if you use any of these, you must specify them explicitly.

As the value of the group_replication_ip_whitelist option, you can specify host names, simple IP addresses, or CIDR notation, in any combination. A comma must separate each entry. From MySQL 8.0.14, IPv6 addresses (or host names that resolve to them) can be used as well as IPv4 addresses. An example whitelist is as follows:

"192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24"

The address that you specify for each group member in group_replication_local_address must be whitelisted on the other servers in the replication group. If any of the seed members for the group are listed in the group_replication_group_seeds option with an IPv6 address when a joining member has an IPv4 group_replication_local_address, or the reverse, you must also set up and whitelist an alternative 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). For more information, see Section 18.5.1, “IP Address Whitelisting”.

It is possible to configure different whitelists on different group members according to your security requirements, for example, in order to keep different subnets separate. However, this can cause issues when a group is reconfigured. If you do not have a specific security requirement to do otherwise, use the same whitelist on all members of a group. For more details, see Section 18.5.1, “IP Address Whitelisting”.

For host names, name resolution takes place only when a connection request is made by another server. A host name that cannot be resolved is not considered for whitelist validation, and a warning message is written to the error log. Forward-confirmed reverse DNS (FCrDNS) verification is carried out for resolved host names.

group_replication_local_address

The network address which the member provides for connections from other members, specified as a host:port formatted string. This address must be reachable by all members of the group because it is used by the group communication engine (XCom, a Paxos variant) for TCP communication between remote XCom instances. Communication with the local instance is over an input channel using shared memory.

The address or host name that you specify in 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, and you can use the same host name or IP address for all members as long as the ports are all different. The recommended port for group_replication_local_address is 33061. Note that the value you specify for this variable is not validated until the START GROUP_REPLICATION statement is issued and the Group Communication System (GCS) is available.

The network address configured by 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. An IPv6 address must be specified in square brackets in order to distinguish the port number, for example:

group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

If a host name specified as the Group Replication local address for a server instance resolves to both an IPv4 and an IPv6 address, the IPv4 address is always used for Group Replication connections. For more information on Group Replication support for IPv6 networks and on replication groups with a mix of members using IPv4 and members using IPv6, see Section 18.4.5, “Support For IPv6 And For Mixed IPv6 And IPv4 Groups”.

For the purpose of IP address whitelisting for Group Replication, the address that you specify for each group member in group_replication_local_address must be added to the list for the group_replication_ip_whitelist option on the other servers in the replication group. If any of the seed members for the group are listed in the group_replication_group_seeds option with an IPv6 address when this member has an IPv4 group_replication_local_address, or the reverse, you must also set up and whitelist an alternative address for this member for the required protocol (or a host name that resolves to an address for that protocol). For more information, see Section 18.5.1, “IP Address Whitelisting”.

group_replication_member_weight

A percentage weight that can be assigned to members to influence the chance of the member being elected as primary in the event of failover, for example when the existing primary leaves a single-primary group. Assign numeric weights to members to ensure that specific members are elected, for example during scheduled maintenance of the primary or to ensure certain hardware is prioritized in the event of failover.

For a group with members configured as follows:

during election of a new primary the members above would be sorted as member-2, member-3, member-4, and member-1. This results in member-2 being chosen as the new primary in the event of failover. For more information, see Section 18.4.1.1, “Single-Primary Mode”.

group_replication_member_expel_timeout

The period of time in seconds that a Group Replication group member waits after creating a suspicion before expelling from the group the member suspected of having failed. The initial 5-second detection period before a suspicion is created does not count as part of this time. Changing the value of group_replication_member_expel_timeout on a group member takes effect immediately for existing as well as future suspicions on that group member. It is not mandatory for all members of a group to have the same setting, but it is recommended in order to avoid unexpected expulsions.

A group member is expelled when another member's suspicion of it (or its own suspicion of itself) times out. By default, group_replication_member_expel_timeout is set to 0, meaning that there is no waiting period and a suspected member is liable for expulsion immediately after the 5-second detection period ends. An additional short period of time might elapse before the expelling mechanism detects and implements the expulsion. If a group member is at an older MySQL Server version that does not support this setting, this is its behavior towards other members or itself.

To avoid unnecessary expulsions on slower networks, or in the case of expected transient network failures or machine slowdowns, you can specify a timeout value greater than zero, up to a maximum of 3600 seconds (1 hour). If a suspect member becomes active again before the suspicion times out, it rejoins the group, applies all the messages that were buffered by the remaining group members, and enters ONLINE state. Otherwise, it is liable for expulsion immediately after the suspicion times out.

The waiting period before expelling a member only applies to members that have previously been active in the group. Non-members that were never active in the group do not get this waiting period and are removed after the initial detection period because they took too long to join.

If any members in a group are currently under suspicion, the group membership cannot be reconfigured (by adding or removing members or electing a new leader). If group membership changes need to be implemented while one or more members are under suspicion, and you want the suspect members to remain in the group, take any actions required to make the members active again, if that is possible. If you cannot make the members active again and you want them to be expelled from the group, you can force the suspicions to time out immediately. Do this by changing the value of group_replication_member_expel_timeout on any active members to a value lower than the time that has already elapsed since the suspicions were created. The suspect members then become liable for expulsion immediately.

An expelled member is not allowed to rejoin the group normally. If the expelled member does reconnect to the group and so becomes aware that it was expelled, it follows the action specified by the system variable group_replication_exit_state_action. If this system variable is set to ABORT_SERVER, which is the default, the expelled member shuts itself down. If it is set to READ_ONLY, the expelled member remains online but switches itself to super read only mode.

group_replication_poll_spin_loops

The number of times the group communication thread waits for the communication engine mutex to be released before the thread waits for more incoming network messages.

group_replication_recovery_complete_at

Recovery policies when handling cached transactions after state transfer. This option specifies whether a member is marked online after it has received all transactions that it missed before it joined the group (TRANSACTIONS_CERTIFIED) or after it has received and applied them (TRANSACTIONS_APPLIED).

group_replication_recovery_get_public_key

Whether to request from the master the public key required for RSA key pair-based password exchange. This variable applies to slaves that authenticate with the caching_sha2_password authentication plugin. For that plugin, the master does not send the public key unless requested.

If group_replication_recovery_public_key_path is set to a valid public key file, it takes precedence over group_replication_recovery_get_public_key.

group_replication_recovery_public_key_path

The path name to a file containing a slave-side copy of the public key required by the master for RSA key pair-based password exchange. The file must be in PEM format. This variable applies to slaves that authenticate with the sha256_password or caching_sha2_password authentication plugin. (For sha256_password, setting group_replication_recovery_public_key_path applies only if MySQL was built using OpenSSL.)

If group_replication_recovery_public_key_path is set to a valid public key file, it takes precedence over group_replication_recovery_get_public_key.

group_replication_recovery_reconnect_interval

The sleep time, in seconds, between reconnection attempts when no donor was found in the group.

group_replication_recovery_retry_count

The number of times that the member that is joining tries to connect to the available donors before giving up.

group_replication_recovery_ssl_ca

The path to a file that contains a list of trusted SSL certificate authorities.

group_replication_recovery_ssl_capath

The path to a directory that contains trusted SSL certificate authority certificates.

group_replication_recovery_ssl_cert

The name of the SSL certificate file to use for establishing a secure connection.

group_replication_recovery_ssl_cipher

The list of permitted ciphers for SSL encryption.

group_replication_recovery_ssl_crl

The path to a directory that contains files containing certificate revocation lists.

group_replication_recovery_ssl_crlpath

The path to a directory that contains files containing certificate revocation lists.

group_replication_recovery_ssl_key

The name of the SSL key file to use for establishing a secure connection.

group_replication_recovery_ssl_verify_server_cert

Make the recovery process check the server's Common Name value in the donor sent certificate.

group_replication_recovery_use_ssl

Whether Group Replication recovery connection should use SSL or not.

group_replication_single_primary_mode

Instructs the group to automatically pick a single server to be the one that handles read/write workload. This server is the PRIMARY and all others are SECONDARIES.

group_replication_ssl_mode

Specifies the security state of the connection between Group Replication members.

group_replication_start_on_boot

Whether the server should start Group Replication or not during server start.

group_replication_transaction_size_limit

Configures the maximum transaction size in bytes which the group accepts. Transactions larger than this size are rolled back. Use this option to avoid large transactions causing the group to fail. A large transaction can cause problems for a group, either in terms of memory allocation or network bandwidth consumption, which may cause the failure detector to trigger because a given member is unreachable while it is busy processing the large transaction. When set to 0 there is no limit to the size of transactions the group accepts, and there may be the risk of large transactions causing the group to fail. Adjust the value of this variable depending on the size of workload you require from the group.

group_replication_unreachable_majority_timeout

Configures how long members that suffer a network partition and cannot connect to the majority wait before leaving the group. By default set to 0, which means that members that find themselves in a minority due to a network partition wait forever to connect the group. In a group of 5 servers (S1,S2,S3,S4,S5), if there is a disconnection between (S1,S2) and (S3,S4,S5) there is a network partition. The first group (S1,S2) is now in a minority because it cannot contact more than half of the group. While the majority group (S3,S4,S5) remains running, the minority group waits forever for a network reconnection. Any transactions processed by the minority group are blocked until Group Replication is stopped using STOP GROUP REPLICATION on the members of the minority.

If configured to a number of seconds, members wait for this amount of time after losing contact with the majority of members before leaving the group. All pending transactions processed by the minority are rolled back and the servers in the minority partition move to the ERROR state and set themselves to super_read_only=ON mode.