Fragmentation of the cluster When a cluster is split into several individual groups due to network reasons (a group may be a single node or several interconnected nodes), the data is inconsistent and may result in brain fissures and inconsistent data. In this case, only one set of nodes can continue to serve, the state of this set of nodes is primary. When this happens, Galera cluster launches a special quorum algorithm to elect a component as the primary component. Cluster size determines the number of votes in the Quorum quorum (so it is better to avoid splitting the brain-this extends to other devices, such as switches, networks, data centers, at least 3), when a node no longer responds and is presumably no longer part of the cluster. Galera will start an arbitration election. You can use Evs.suspect_timeout to fine-tune this no response timeout, which is set to 5 seconds by default. When galera the election, most of the nodes that were originally connected to remain are the main ones, but the split nodes are still alive. When the division occurs, the weighted quorum is obtained as one of the main components, the other the weight of the node state becomes non-primary and attempts to connect to the master. Weighting requires "most" so two nodes cannot be clustered, and if one faliure the other will automatically become non-primary state
the condition of the brain fissureA cluster error causes the data nodes to be independent of each other in a case called a brain fissure. When a brain fissure occurs, data can be irreparably damaged, such as two data nodes independently updating the same row of data on the same table. Like other weight-based systems, when the quorum algorithm fails to elect the primary node, the Galera cluster also has a brain fissure. This can happen if the cluster cluster is only two nodes or if the main switch is broken without a backup switch. To minimize the risk of brain cracking in an even-numbered cluster environment, ensure that the cluster is separated according to the way it is guaranteed to produce the master, such as 4 node cluster-3 (Primary) + 1 (non-primary). The weight of the node can be adjusted in the run process set GLOBAL wsrep_provider_options= "Pc.weight=3"; Galera applies the new weight value by distributing the message carrying the weight, but does not notify the application of the change of the mechanism. But watch out! When the weight message is changed, the cluster splits, causing the whole cluster to become non-primary. In this case, you can only wait to re-merge or view that part as the latest data and then restart it as the first node.
Node1:pc.weight = 2node2:pc.weight = 1node3:pc.weight = 0
Three nodes configure the weights as above, and if you kill Node 2 and node 3 at the same time, node 1 becomes the master, but the kill node 1,,2 and 3 becomes non-primary
Galera Arbitrator
ArbitratorThe Galera arbitrator is a member of the cluster that participates in the voting but does not really participate in the duplication. Galera The arbitrator is established for the following two purposes: 1, even nodes, the arbitrator as a node to make the cluster an odd number, so as to avoid brain crack 2, it can request a continuous application state snapshot, can be used to make a backup although the arbitrator does not save data, it must be able to flow through all the replication stream, So putting the arbiter in a network environment with poor connections to other nodes can lead to poor performance across the cluster. The arbitrator is inverted and does not affect the operation of the cluster, can be hung at any time a new node up
Start Galera ArbitratorGalera Arbitrator is an independent process with cluster, called GARBD. This means that it must be started separately, and it also means that the arbiter cannot be configured through MY.CNF. How you configure the arbiter depends on how you start it. When the arbiter starts, the script executes the sudo statement in its process as a user nobody. However, in Fedora and some other versions of Linux, the default sudo configuration prevents the operation of a user's non-TTY connection. To avoid this, the defaults Requiretty line needs to be removed from the/etc/sudoers file. 1. Use Shell to start the arbiter with Shell to start the arbiter, there are two options to configure. The parameters can be set by the command line first
$ GARBD--group=example_cluster \ --address= "gcomm://192.168.1.1,192.168.1.2,192.168.1.3" \ --option= " socket.ssl_key=/etc/ssl/galera/server-key.pem;socket.ssl_cert=/etc/ssl/galera/server-cert.pem;socket.ssl_ca=/ Etc/ssl/galera/ca-cert.pem;socket.ssl_cipher=aes128-sha ""
If you use SSL, you need to set a password. You can set the options you want to use in the configuration file if you do not want to output these items every time you start the arbiter with the shell.
# arbtirator.configgroup = Example_clusteraddress = gcomm://192.168.1.1,192.168.1.2,192.168.1.3
Then use--cfg when starting the arbitrator
$ GARBD--cfg/path/to/arbitrator.config
--help parameter Get help
$ GARBD--HELPUSAGE:GARBD [options] [group address]
2. Start the arbiter as a service when you start the arbiter as a service, regardless of init or systemd, and the shell-initiated configuration file is different
# Copyright (C) 2013-2015 codership oy# This config file was to being sourced by GARBD service script.# A space-separated list of node addresses (address[:p ort]) in the cluster:galera_nodes= "192.168.1.1:4567 192.168.1.2:4567" # Galera cluster name, Should is the same as on the rest of the node. Galera_group= "Example_wsrep_cluster" # Optional Galera internal options string (e.g. SSL settings) # See/HTTP Galeracluster.com/documentation-webpages/galeraparameters.htmlgalera_options= "Socket.ssl_cert=/etc/galera/cert /cert.pem;socket.ssl_key=/$ "# Log file for GARBD. Optional, by default logs to sysloglog_file= "/var/log/garbd.log"
This configuration file should be placed in the system's service profile directory, common such as/etc under. You can then start the garb service. With init: # service garb start with Systemd, # Systemctl start garb in addition to the standard configuration, all parameters of the cluster cluster also apply to arbitrators, except those prefixed with REPL. When you start with the shell, you can use the--option parameter to set it.
Division and arbitration mechanism of Galera cluster cluster