Shulou(Shulou.com)06/01 Report--

"galera parameter resolution:"

1. Status parameters:

-- wsrep_last_committed:

Represents the latest transaction number of the current node, which is also the second half of the latest galera GTID. The first half is the value of the parameter wsrep_local_state_uuid, which is updated after each commit, DDL execution completion, or APPLY

-- wsrep_replicated:

Represents the number of transactions that the current node has replicated.

-- wsrep_replicated_bytes:

Corresponding to the parameter wsrep_replicated, the size of each transaction is different, which represents the sum of the total byte sizes (key and data) of the wsrep_replicated transactions that have been replicated

-- wsrep_repl_keys:

The total number of key corresponding to wsrep_replicated transactions that have been replicated by the current node. A transaction can contain multiple key

-- wsrep_repl_keys_bytes:

Corresponding to the parameter wsrep_repl_keys, the total size of all sent key represents the total byte size.

-- wsrep_repl_data_bytes:

Corresponding to the parameter wsrep_repl_keys_bytes and the relationship with the above parameters: wsrep_replicated_bytes=wsrep_repl_keys_bytes+wsrep_repl_data_bytes+wsrep_replicated*64

-- wsrep_received:

Corresponding to the parameter wsrep_replicated, indicates the number of transactions replicated from the write node that have been received by the current node, in units of transactions

-- wsrep_received_bytes:

Corresponding to the parameter wsrep_received, indicates the number of bytes of key and DATA contained in all received transactions

-- wsrep_local_commits:

Indicates the number of transactions submitted locally by the current node

-- wsrep_local_cert_failures

Indicates the number of local node authentication failures

-- wsrep_local_replays:

Indicates the number of local replay operations. The higher the value of this parameter, the higher the frequency of local errors.

-- wsrep_local_send_queue:

Indicates the number of transactions the current node is waiting for replication, that is, the length of the sending queue. If the parameter is larger, it indicates that there is a problem with local pressure or network performance, and can be used as a monitoring indicator.

-- wsrep_local_send_queue_max:

The maximum number of transactions waiting in the queue in the history of the current node

-- wsrep_local_send_queue_min:

The minimum number of transactions waiting for a column in the history of the current node, which is usually 0

-- wsrep_local_send_queue_avg:

The current node has waited for the average queue length since the last flush parameter. The higher the value, the greater the pressure, but the waiting of flow_control is not included in this parameter.

-- wsrep_local_recv_queue:

Indicates the number of transactions in the queue accepted by the current node from other nodes. This queue is related to flow control. If this value reaches the gcs.fc_ value, flow control will occur. This node will send flow control to the entire cluster. Be careful, the whole cluster will be blocked. When the value of wsrep_local_recv_queue is less than gcs.fc_limit*gcs.fc_factor, the flow control will be released.

-- wsrep_local_recv_queue_mas:

Represents the maximum number of transactions in the current node history receiving queue

-- wsrep_local_recv_queue_min:

Represents the minimum number of transactions in the current node history receiving queue

-- wsrep_local_recv_queue_avg:

Represents the average number of transactions in the current node history receiving queue. If the average value of one node is larger than the others, it can be considered that the hardware performance of this machine is not very good, or due to pressure.

-- wsrep_local_cached_downto:

Represents the minimum GTID value in the current node cache, which can determine whether other nodes in the cluster need to do IST or SST when starting.

-- wsrep_flow_control_paused_ns:

Represents the length of time, in nanoseconds, that the cluster is blocked due to flow control messages. This parameter cannot be reset through flush status. Its value is incremental and cumulative.

-- wsrep_flow_control_paused:

Indicates that the ratio of the newly generated FC pause time since the last flush status to the time between the start of the flush and the execution of the show status like "wsrep%" command can be understood as a pause time. The closer this value is to 0, the more normal the system is. If it is about 1, it means that the current system is basically unable to replicate.

-- wsrep_flow_control_sent:

When the length of a node's replication task queue exceeds fc_limit, the node will send FC messages to the entire cluster. This parameter indicates the number of times the current node sends FC messages to the entire cluster. The higher the value, the slower the node does. If this value increases abruptly, there may be a problem with this node, or the load on this node increases, causing the apply write set to slow down.

-- wsrep_flow_control_recv:

Represents the number of times the current node received a FC message. When this parameter suddenly increases, you need to see which node has a sudden increase in the sentencing value, then this node may have a performance problem.

-- wsrep_cert_deps_distance:

Represents the sum of the difference between the GTID2 of a transaction and the GTID1 of the transaction on which it depends, and the ratio of the total number of transactions (n_certified) validated during this period.

-- wsrep_commit_oooe:

The value of this parameter is always 0. If other values appear, please see the official website.

-- wsrep_commit_oool:

The value of this parameter is always 0. If other values appear, please see the official website.

-- wsrep_commit_window:

This parameter is still related to the above parameter. Oooe; is checked every time it is committed. If this value is higher, the order of the real commit process is more disorderly, and the writing transaction pressure is not balanced. If it is closer to 1, it means that the write is more orderly and the transaction is relatively uniform.

-- wsrep_apply_oooe:

This parameter is the same as the above oooe. If this value is very close to 0, then the execution of the system is basically serial.

-- wsrep_apply_oool:

Corresponding to the parameter wsrep_apply_oooe, the object of this parameter means that the higher the value, the more disorder occurs during parallel execution; if the value is smaller, it is basically executed sequentially.

-- wsrep_apply_window:

This parameter value corresponds to the above. The higher this value, the greater the GTID difference between parallel apply transactions, and the more frequent the activity of this node.

-- wsrep_local_state:

Indicates the status of the current node. (there are 4 values: 1: request to join the cluster, which is generally not visible at a high speed; 2: data synchronization; 3: the current node has joined the cluster; 4: the current node is exactly the same as the entire cluster)

-- wsrep_local_state_comment:

This parameter corresponds to the four state values of the above parameter one by one, and is a description of the node value above.

-- wsrep_cert_index_size:

Indicates the total number of key in the authentication queue of the current node

-- wsrep_causal_reads:

Represents the number of waits to handle this write set, but this parameter is no longer used

-- wsrep_cert_interval:

Represents the sum of the difference between the GTID values of all transactions and the GTID values of the most recently committed transactions that they can see, and the ratio of the total number of transactions that have been validated during this period

-- wsrep_evs_repl_latency:

Indicates the replication delay of GCOMM during message delivery (in seconds). Sampling time is controlled by parameter evs.stats_report_period. Default is PT1M.

-- wsrep_incoming_addresses:

Indicates the information of all nodes that have joined or are in the process of joining the cluster. The format is: IP: Port, IP: Port, which can be used for monitoring.

-- wsrep_cluster_size:

Indicates the number of nodes in the current cluster, corresponding to the parameter wsrep_incoming_addresses, and can also be used as a monitoring item. Generally, the monitoring condition must be greater than or equal to 3. If it is 3, the problem of brain fissure will occur.

-- wsrep_local_bf_aborts:

Indicates the number of transactions in which the local transaction was actively cancelled due to the transaction conflict while the current node was running. If this value is large, it means that there are many write conflicts in the cluster, and you may need to adjust the way of writing, such as switching write nodes, etc.

-- wsrep_local_index:

Represents the number of the current node in the cluster. In a cluster, each node has a unique number, counting from 0

-- wsrep_ready:

A very important monitoring item, you can know whether the status of the current node can be comforted. Normally, it is ON. If it becomes OFF, there may be a brain fissure, or the network between other nodes may not be connected, or the galera cluster may not start normally. You can generally restore it with the command set global wsrep_provider_options='pc.bootstrap=yes', but after executing this command, you need to observe the state of the entire cluster, otherwise it may cause the node to logically break out of the cluster. The function of this command is to change the current node to primary. If it is executed, it means that you are sure to use this node to provide services.

2. Variable parameters:

-- wsrep_provider_options:

-cert.log_conflicts:

In galera, every transaction committed will be verified to see if there is a dependency and insist on whether there is a conflict, etc. If a conflict is found, this parameter controls whether to record the conflict, so that the cause can be found through the log or used to do some other work, and the log will be recorded in the error_log file.

-gcache.dir:

The directory used to specify the GCache file, which works only if the gcache.name parameter specifies a relative path, but if the gcache.name specifies an absolute path, this parameter is ignored. If this parameter is not specified, it will be set to the value of the parameter base_dir

-gcache.name:

Used to specify the name of the GCache file, which can also be accompanied by a path, including absolute and relative paths

-gcache.mem_size: not recommended! It has been officially abandoned.

-gcache.page_size:

This parameter indicates the size of the newly created physical file. If one is still not enough, the new physical file of the same size will continue to be created. When GCache is purge, the GCache of the physical file will be cleared, and if there is no valid write set content in the file, the file will be deleted. So as long as the physical file appears, it means that GCache is not enough.

-gcache.size: not recommended! It has been officially abandoned.

-gcs.fc_limit:

This parameter controls the size of the accepted queue and triggers the FC.

-gcs.fc_factor:

This parameter indicates how big the receiving queue is, and the FC will be released. This parameter is a ratio, and the result of gcs.fc_limit X gcs.gc_factor is the length of the receive queue when the FC is released. If it is less than this length, FC releases

-gcs.fc_master_slave:

This parameter is related to the above two parameters. If set to yes, it means that the current cluster is used in master-slave mode, that is, single-point write mode, and other nodes are slave nodes; if set to no, it means that multi-point write mode is used, and the value of gcs.fc_limit that takes effect will change.

-gcs.sync_donor:

This parameter controls whether donor sends flow control messages during state transfer. If this parameter is set to no, no flow control is generated, so it is a non-blocking state transfer.

-gmcast.listen_addr:

This value is used to sense the join operation of other nodes, and the newly joined node will send a message to this address after selecting donor, which can establish a connection.

-gmcast.segment:

The setting of this value is used to determine which node has priority when selecting donor. The range is 0-255. the higher the value, the higher the priority. It is generally set to 0, that is, donor is automatically selected.

-ist.recv_addr:

This address is used to set the receive address of joiner when doing IST. By default, it is set to the address specified by wsrep_node_address, and the port is a separate receive port in the format of IP:PORT.

-repl.commit_order:

This parameter controls the behavior of galera concurrency control for commit operations. To make the binlog generated by all nodes exactly the same, it is recommended that this value be set to 3

-repl.max_ws_size:

This parameter is used to control the replication size of the write set, in bytes

-pc.bootstrap:

This parameter can be used to change a node whose current node state is unserviceable (non-primary components) into a node in primary components state. Generally speaking, the command of this parameter is set to: set global wsrep_provider_options='pc.bootstrap=yes';, is used to quickly deal with failures and restore online services.

-- wsrep_start_position:

This parameter is a new parameter in the PXC version of mysqld, which is used to specify the latest GTID value of the current node when the node starts, or to specify where the current node starts to increment data points from the cluster.

-- wsrep_slave_threads:

This parameter is used to set the number of threads used for parallel replication when performing apply from a node in a galera cluster cluster.

-wsrep_retry_autocommit:

This parameter is used to control the transaction execution behavior. If verification fails, each node should fail verification, then each node will fail. In the case of verification failure, the slave node can directly ignore the write set. The primary node is controlled by the parameter wsrep_retry_autocommit. If it is not 0, the current transaction (in the case of autocommit) will be executed again, re-executed from beginning to end, and then sent again, verified, etc.

-- wsrep_recover:

This parameter is used to find the latest GTID value of a node (in the shutdown state). It only needs to go to a fixed location of the ibddata of innodb, find the GTID value, and then enter it into the log file, so that you can know the latest location and the difference with the cluster.

-- wsrep_on:

This parameter is used to control whether writes from the current node want to be copied to other nodes. By default, in order to ensure the consistency of the cluster, writes from one node are copied to other nodes.

-- wsrep_max_ws_size:

This parameter is used to control the size of galera cluster write transactions on a node. Here, it refers to the total number of byte of keys and DATA, which is a security parameter.

-- wsrep_max_ws_rows:

This parameter is used to control the number of rows affected by galera cluster writing transactions at a node. If this value is exceeded, an exception is thrown directly, which is a security parameter

-- wsrep_desync:

Set this parameter to on on the node with replication delay, so that the node will become an asynchronous replication mode, where the master database can always write and the slave node can apply all the time. If the length of the queue for accepting tasks has exceeded the fc.slave value, the slave node will not send flow control. Be careful, the writes of the whole cluster are safe and sound, but it is just possible that the slave node's data is not up to date. There is a delay for a period of time, if you can have a few songs, there is nothing wrong with maintaining such a state for a long time. If the delay problem is gone, there will be no more task accumulation. It can be said that the parameter value is set to OFF, and the whole cluster is consistent again, and it becomes a real galera cluster.

-- wsrep_cluster_address:

The format of this parameter is similar: gcomm://192.168.1.1:3306192.168.1.2:3306. When starting, each node will find other nodes in the cluster by setting this parameter. The specified nodes can be started or not, and galera will automatically select and join them. It is recommended to ensure that the value of this parameter is consistent with the actual nodes in the cluster when changing the cluster, so as to avoid unnecessary trouble when changing in the future.

-- wsrep_OSU_method:

This parameter is used to control the execution behavior of DDL; by default, its value is TOI, which means that the whole process is strongly ordered during execution, and when the modified table is used, it will be killed. This is the default and the easiest method, and this method is also recommended.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.