社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
It’s recommended when deploying a Galera Cluster that you use a minimum of three instances: Three nodes, three datacenters and so on.
If the cost of adding resources (e.g., a third datacenter) is too much, you can use Galera Arbitrator. Galera Arbitrator is a member of a cluster that participates in voting, but not in the actual replication.
Warning
While Galera Arbitrator does not participate in replication, it does receive the same data as all other nodes. You must secure its network connection.
Galera Arbitrator serves two purposes: When you have an even number of nodes, it functions as an odd node, to avoid split-brain situations. It can also request a consistent application state snapshot, which is useful in making backups.
Galera Arbitrator
If one datacenter fails or loses its WAN connection, the node that sees the arbitrator—and by extension sees clients—continues operation.
Note
Even though Galera Arbitrator doesn’t store data, it must see all replication traffic. Placing Galera Arbitrator in a location with poor network connectivity to the rest of the cluster may lead to poor cluster performance.
In the event that Galera Arbitrator fails, it won’t affect cluster operation. You can attach a new instance to the cluster at any time and there can be several instances running in the cluster.
For more information on using Galera Arbitrator for making backups, see Backing Up Cluster Data.
Galera Arbitrator is a separate daemon from Galera Cluster, called garbd
. This means that you must start it separately from the cluster. It also means that you cannot configure Galera Arbitrator through the my.cnf
configuration file.
How you configure Galera Arbitrator depends on how you start it. That is to say, whether it runs from the shell or as a service. These two methods are described in the next two sections.
Note
When Galera Arbitrator starts, the script executes a sudo
statement as the user nobody
during its process. There is a particular issue in Fedora and some other distributions of Linux, in which the default sudo
configuration will block users that operate without tty
access. To correct this, edit with a text editor the /etc/sudoers
file and comment out this line:
Defaults requiretty
This will prevent the operating system from blocking Galera Arbitrator.
When starting Galera Arbitrator from the shell, you have two options as to how you may configure it. You can set the parameters through the command line arguments, as in the example here:
$ 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-SHA256""
If you use SSL, it’s necessary to specify the cipher. Otherwise, after initializing the ssl context an error will occur with a message saying, “Terminate called after throwing an instance of ‘gu::NotSet’”.
If you don’t want to enter the options every time you start Galera Arbitrator from the shell, you can set the options in the arbtirator.config
configuration file:
# arbtirator.config group = example_cluster address = gcomm://192.168.1.1,192.168.1.2,192.168.1.3
Then, to enable those options when you start Galera Arbitrator, use the --cfg
option like so:
$ garbd --cfg /path/to/arbitrator.config
For more information on the options available to Galera Arbitrator through the shell, run garbd
with the --help
argument.
$ garbd --help Usage: garbd [options] [group address] Configuration: -d [ --daemon ] Become daemon -n [ --name ] arg Node name -a [ --address ] arg Group address -g [ --group ] arg Group name --sst arg SST request string --donor arg SST donor name -o [ --options ] arg GCS/GCOMM option list -l [ --log ] arg Log file -c [ --cfg ] arg Configuration file Other options: -v [ --version ] Print version -h [ --help ] Show help message
In addition to the standard configuration, any parameter available to Galera Cluster also works with Galera Arbitrator, except for those prefixed by repl
. When you start it from the shell, you can set those using the --option
argument.
For more information on the options available to Galera Arbitrator, see Galera Parameters.
When starting Galera Aribtrator as a service, whether using init
or systemd
, you would use a different format for the configuration file than you would use when starting it from the shell. Below is an example of the configuration file:
# Copyright (C) 2013-2015 Codership Oy # This config file is to be sourced by garbd service script. # A space-separated list of node addresses (address[:port]) in the cluster: GALERA_NODES="192.168.1.1:4567 192.168.1.2:4567" # Galera cluster name, should be the same as on the rest of the node. GALERA_GROUP="example_wsrep_cluster" # Optional Galera internal options string (e.g. SSL settings) # see https://galeracluster.com/documentation-webpages/galeraparameters.html GALERA_OPTIONS="socket.ssl_cert=/etc/galera/cert/cert.pem;socket.ssl_key=/$" # Log file for garbd. Optional, by default logs to syslog LOG_FILE="/var/log/garbd.log"
In order for Galera Arbitrator to use the configuration file, you must place it in a file directory where your system looks for service configuration files. There is no standard location for this directory; it varies from distribution to distribution, though it usually in /etc
and at least one sub-directory down. Some common locations include:
/etc/defaults/
/etc/init.d/
/etc/systemd/
/etc/sysconfig/
Check the documentation for the operating system distribution your server uses to determine where to place service configuration files.
Once you have the service configuration file in the right location, you can start the garb
service. For systems that use init
, run the following command:
# service garb start
For systems that run systemd
, use instead this command:
# systemctl start garb
This starts Galera Arbitrator as a service. It uses the parameters set in the configuration file.
In addition to the standard configuration, any parameter available to Galera Cluster also works with Galera Arbitrator, excepting those prefixed by repl
. When you start it as a service, you can set those using the GALERA_OPTIONS
parameter.
For more information on the options available to Galera Arbitrator, see Galera Parameters.
因为Galera
集群需要至少3个节点组成集群,才不会发生脑裂状况。
Galera
集群部署推荐的是至少三个实例或三个节点或三个数据中心等等。
如果添加一个节点会成本太高,比如添加多一台数据库服务器,那你可以选择使用Galera Arbitrator
。Galera Arbitrator
就是集群中的一份子,可以参与投票,但不参与实际的复制。
注意:虽然
Galera Arbitrator
不参与复制,但它和其他节点一样也会接受数据。你必须确保他的网络连接。
Galera Arbitrator
有两个用途:
当集群为偶数节点时,它的加入以避免脑裂的发生。
同时它能够用于备份,例如快照功能。
如果一个数据中心失败或者是断开连接,并且它与Galera Arbitrator
是接连的话,那Galera Arbitrator
就会作为中间件的扩展。例如node1
与node2
是断开连接的,此时若node1
与Galera Arbitrator
、node2
与Galera Arbitrator
连接的话,那Galera Arbitrator
作为中间件将会为node1
与node2
连接通信。
尽管
Galera Arbitrator
不存储数据,但它必须可以看到所有的流量的传输复制。如果Galera Arbitrator
放在一个网络环境较差的地方,那它连接到集群的时候,可能会导致集群执行或性能下降。
如果Galera Arbitrator
失败的话,它不会影响集群的正常操作。你可以将一个新的实例加入到集群中,可以有多个实例运行在集群中。
有关
Galera Arbitrator
备份的设置,可参考Galera 集群备份
Galera Arbitrator
在Galera
集群中是一个单独的进程。这意味着,你需要独立启动它。这也意味着你不能通过数据库配置文件的方式来启动,比如不能通过my.cnf
启动。
Galera Arbitrator
在启动的时候,脚本会在无人使用的进程中执行sudo
声明,有一个特定问题在Fedora和其他版本的Linux中,这默认用户没有操作sudo
配置的权限。要修正这个问题需要编辑/etc/sudoers
中的Defaults requiretty
,把这个注释掉即可。这样就可以防止操作系统阻塞Galera Arbitrator
。
当开始通过shell
命令执行Galera Arbitrator
的时候,首先你需要通过命令行参数配置。例如:
$ 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""
如果你使用SSL
的方式,则你需要输入密码。否则会有terminate called after throwing an instance of ‘gu::NotSet’
的SSL
提示。
如果你不想每次通过shell
方式启动Galera Arbitrator
,那你可以自定义配置文件中执行。
例如配置文件如下:
# arbtirator.config
group = example_cluster
address = gcomm://192.168.1.1,192.168.1.2,192.168.1.3
当你开始启动Galera Arbitrator
,使用--cfg
选项。
例如:
$ garbd --cfg /path/to/arbitrator.config
更多的参数,可用过--help来查看帮助。
$ garbd --help
Usage: garbd [options] [group address]
Configuration:
-d [ --daemon ] Become daemon
-n [ --name ] arg Node name
-a [ --address ] arg Group address
-g [ --group ] arg Group name
--sst arg SST request string
--donor arg SST donor name
-o [ --options ] arg GCS/GCOMM option list
-l [ --log ] arg Log file
-c [ --cfg ] arg Configuration file
Other options:
-v [ --version ] Print version
-h [ --help ] Show help message
除了标准的配置,Galera
集群中任何配置,都可用于Galera Arbitrator
,除了那些repl
前缀的命令。
当你从shell
启动的话,你可以使用 --option
来设置参数。
更多
Galera Arbitrator
参数可参考Galera 参数
当开始Galera Arbitrator
服务时,无论你使用init
或者systemd
,通过shell
命令,指定不同的配置文件,来启动不用的服务,以实现灵活启动。
# Copyright (C) 2013-2015 Codership Oy
# This config file is to be sourced by garbd service script.
# A space-separated list of node addresses (address[:port]) in the cluster:
GALERA_NODES="192.168.1.1:4567 192.168.1.2:4567"
# Galera cluster name, should be 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.html
GALERA_OPTIONS="socket.ssl_cert=/etc/galera/cert/cert.pem;socket.ssl_key=/$"
# Log file for garbd. Optional, by default logs to syslog
LOG_FILE="/var/log/garbd.log"
为了让Galera Arbitrator
使用配置文件启动,需要你把他放到系统配置文件中,因操作系统发行版而异,而放到不同的地方,通常是放在/etc
下。
通常位置:
/etc/defaults/
/etc/init.d/
/etc/systemd/
/etc/sysconfig/
检查你的发行版的来确定配置文件放在哪里。
一旦你把配置文件放到对的地方,你可以用garb
命令来启动服务。
# service garb start
或者
# systemctl start garb
之后它会执行配置文件里面设置的参数来运行对集群的监听。
---------------
出处:https://galeracluster.com/library/documentation/arbitrator.html
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!