数据库多主集群对应脑裂的解决方案

Galera Arbitrator

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.

Starting Galera Arbitrator

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

Starting Galera Arbitrator from the Shell

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.

Starting Galera Arbitrator as a Service

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 ARBITRATOR - 数据库多主集群对应脑裂的解决方案

 

GALERA ARBITRATOR

因为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 集群备份

STARTING GALERA ARBITRATOR

Galera Arbitrator在Galera集群中是一个单独的进程。这意味着，你需要独立启动它。这也意味着你不能通过数据库配置文件的方式来启动，比如不能通过my.cnf启动。

Galera Arbitrator在启动的时候，脚本会在无人使用的进程中执行sudo声明，有一个特定问题在Fedora和其他版本的Linux中，这默认用户没有操作sudo配置的权限。要修正这个问题需要编辑/etc/sudoers中的Defaults requiretty，把这个注释掉即可。这样就可以防止操作系统阻塞Galera Arbitrator。

Starting Galera Arbitrator from the Shell

当开始通过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 参数

Starting Galera Arbitrator as a Service

当开始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