說MGR - MGR重點參數說明

transaction_write_set_extraction=XXHASH64

Defines the algorithm used to generate a hash identifying the writes associated with a transaction. If you are using Group Replication, the hash value is used for distributed conflict detection and handling. On 64-bit systems running Group Replication, we recommend setting this to XXHASH64 in order to avoid unnecessary hash collisions which result in certification failures and the roll back of user transactions.

binlog_transaction_dependency_tracking=WRITESET

The source of dependency information that the master uses to determine which transactions can be executed in parallel by the slave's multithreaded applier.?

loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

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.

loose-group_replication_local_address= "10.0.2.5/6/7:33081"

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 for Group Replication (XCom, a Paxos variant) for TCP communication between remote XCom instances. Other Group Replication members contact this member through this host:port for all internal group communication. 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.?

loose-group_replication_group_seeds= "10.0.2.5:33081,10.0.2.6:33081,10.0.2.7:33081"

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 the seed member's network addresses specified as a comma separated list, such as host1:port1,host2:port2. 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 host names, issuing START GROUP_REPLICATION fails.

loose-group_replication_start_on_boot=OFF

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

loose-group_replication_bootstrap_group=OFF

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.

loose-group_replication_single_primary_mode=ON

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. This system variable is a group-wide configuration setting. It must have the same value on all group members, cannot be changed while Group Replication is running, and requires a full reboot of the group (a bootstrap by a server with group_replication_bootstrap_group=ON) in order for the value change to take effect.

loose-group_replication_enforce_update_everywhere_checks=OFF

Enable or disable strict consistency checks for multi-primary update everywhere. The default is that checks are disabled. In single-primary mode, this option must be disabled on all group members. In multi-primary mode, this option should be enabled. This system variable is a group-wide configuration setting. It must have the same value on all group members, cannot be changed while Group Replication is running, and requires a full reboot of the group (a bootstrap by a server with group_replication_bootstrap_group=ON) in order for the value change to take effect.

loose-group_replication_member_weight=50

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.

loose-group_replication_recovery_retry_count=10

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

loose-group_replication_recovery_reconnect_interval=60

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

loose-group_replication_flow_control_mode=DISABLED

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

loose-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.

loose-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.

loose-group_replication_unreachable_majority_timeout=10

Configures how long members that suffer a network partition and cannot connect to the majority wait before leaving 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 for the specified time 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. Note that group_replication_unreachable_majority_timeout has no effect if it is set on the servers in the minority group after the loss of majority has been detected.

By default, this system variable is set to 0, which means that members that find themselves in a minority due to a network partition wait forever to leave the group. 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. When the specified time elapses, all pending transactions processed by the minority are rolled back, and the servers in the minority partition move to the ERROR state. These servers then follow the action specified by the system variable group_replication_exit_state_action, which can be to set themselves to super read only mode or shut down MySQL.

loose-group_replication_exit_state_action=READ_ONLY

Configures how Group Replication behaves when a server instance leaves the group unintentionally, for example after encountering an applier error, or in the case of a loss of majority, or when another member of the group expels it due to a suspicion timing out. The timeout period for a member to leave the group in the case of a loss of majority is set by the group_replication_unreachable_majority_timeout system variable. Note that an expelled group member does not know that it was expelled until it reconnects to the group, so the specified action is only taken if the member manages to reconnect, or if the member raises a suspicion on itself and expels itself.

When group_replication_exit_state_action is set to ABORT_SERVER, if the member exits the group unintentionally, the instance shuts down MySQL.

When group_replication_exit_state_action is set to READ_ONLY, if the member exits the group unintentionally, the instance switches MySQL to super read only mode (by setting the system variable super_read_only to ON).

loose-group_replication_compression_threshold=1000000

The value in bytes above which (LZ4) compression is enforced. When set to zero, deactivates compression. The value of group_replication_compression_threshold should be the same on all group members.

loose-group_replication_transaction_size_limit=134217728

Configures the maximum transaction size in bytes which the replication group accepts. Transactions larger than this size are rolled back by the receiving member and are not broadcast to the group. Large transactions can cause problems for a replication group in terms of memory allocation, which can cause the system to slow down, or in terms of network bandwidth consumption, which can cause a member to be suspected of having failed because it is busy processing the large transaction.