Percona Arbitrator的使用

1.前言        

前文中我们介绍了Percona XtraDB Cluster双节点的故障情况(http://blog.csdn.net/wjf870128/article/details/45199781)，由于脑裂的发生和quorum机制，通常单纯双节点的percona集群无法保证环境的可靠性。

因此引入了仲裁技术-->arbitrator来防止双节点的集群环境中由于通信故障而导致节点无法正常同步的情况发生。

上图摘自galera官网中对于arbitrator的定义，在这里arbitrator有两种功能：

1. 在多节点的集群当中担任类似与已添加节点的角色，防止节点间通信中断导致的闹裂发生
2. 可以用来请求一个完整的SST副本，用于备份使用。

当节点无法接受到其他节点的通信时，如果可以同arbitrator连接，就可以通过arbitrator来接受和发送同步数据，实现一致性。

注：虽然arbitrator不实际的应用接受的同步数据，但是由于arbitrator需要查看所有的同步活动，因此如果arbitrator所在的网络速度慢的话会导致整个集群性能下降。

2.安装步骤

1. Cluster环境：

       OS：Redhat 6.5

       Cluster：Percona-XtraDB-Cluster5.6.22-25

       主节点：

       hostname：mysql-pxc01

       ip addr：192.168.48.11

       备节点：

       hostname：mysql-pxc02

       ip addr：192.168.48.12

      参考前文http://blog.csdn.net/wjf870128/article/details/45176011搭建双节点的percona  xtradb cluster环境。

2.Arbitrator环境：

       OS：Redhat 6.5

       Software：Percona-XtraDB-Cluster-5.6.22-25.8-r978-el6-i386-bundle.tar

       ip addr：192.168.48.8

3.解压缩软件包

       tar -xf Percona-XtraDB-Cluster-5.6.22-25.8-r978-el6-i386-bundle.tar

4.安装依赖包nc

       yum install nc

5.安装Arbitrator包

       rpm -ivh Percona-XtraDB-Cluster-garbd-3-3.9-1.3494.rhel6.i686.rpm

3.调用Arbitrator使用

1.查看现有的双节点Percona XtraDB Cluster状态

主节点：

备节点：

可以看到双节点的cluster状态正常。

2.创建Arbitrator目录

# mkdir /arbitrator

3.创建Arbitrator配置文件

# touch /arbitrator/ab.cfg

4.配置Arbitrator配置文件

group = my_Redhat_cluster
address = "gcomm://192.168.48.11:4567,192.168.48.12:4567"

5.启动Arbitrator

# garbd -c /arbitrator/ab.cfg -l /arbitrator/ab.log &

</pre><p></p><p>6.查看Arbitrator日志如下</p><p></p><pre code_snippet_id="650707" snippet_file_name="blog_20150422_6_3498325" name="code" class="html">[root@mysql-repl01 arbitrator]# cat ab.log 
2015-04-22 21:49:37.274  INFO: CRC-32C: using "slicing-by-8" algorithm.
2015-04-22 21:49:37.275  INFO: Read config: 
        daemon:  0
        name:    garb
        address: gcomm://192.168.48.11:4567,192.168.48.12:4567
        group:   my_Redhat_cluster
        sst:     trivial
        donor:   
        options: gcs.fc_limit=9999999; gcs.fc_factor=1.0; gcs.fc_master_slave=yes
        cfg:     /arbitrator/ab.cfg
        log:     /arbitrator/ab.log

2015-04-22 21:49:37.278  INFO: protonet asio version 0
2015-04-22 21:49:37.279  INFO: Using CRC-32C for message checksums.
2015-04-22 21:49:37.279  INFO: backend: asio
2015-04-22 21:49:37.279  WARN: access file(./gvwstate.dat) failed(No such file or directory)
2015-04-22 21:49:37.279  INFO: restore pc from disk failed
2015-04-22 21:49:37.281  INFO: GMCast version 0
2015-04-22 21:49:37.282  INFO: (6a6899f9, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567
2015-04-22 21:49:37.282  INFO: (6a6899f9, 'tcp://0.0.0.0:4567') multicast: , ttl: 1
2015-04-22 21:49:37.283  INFO: EVS version 0
2015-04-22 21:49:37.284  INFO: gcomm: connecting to group 'my_Redhat_cluster', peer '192.168.48.11:4567,192.168.48.12:4567'
2015-04-22 21:49:37.300  INFO: (6a6899f9, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: 
2015-04-22 21:49:37.723  INFO: declaring 322cd734 at tcp://192.168.48.11:4567 stable
2015-04-22 21:49:37.724  INFO: declaring 7cf4fdc0 at tcp://192.168.48.12:4567 stable
2015-04-22 21:49:37.737  INFO: Node 322cd734 state prim
2015-04-22 21:49:37.741  INFO: view(view_id(PRIM,322cd734,3) memb {
        322cd734,0
        6a6899f9,0
        7cf4fdc0,0
} joined {
} left {
} partitioned {
})
2015-04-22 21:49:37.741  INFO: save pc into disk
2015-04-22 21:49:37.819  INFO: gcomm: connected
2015-04-22 21:49:37.819  INFO: Changing maximum packet size to 64500, resulting msg size: 32636
2015-04-22 21:49:37.820  INFO: Shifting CLOSED -> OPEN (TO: 0)
2015-04-22 21:49:37.820  INFO: Opened channel 'my_Redhat_cluster'
2015-04-22 21:49:37.820  INFO: New COMPONENT: primary = yes, bootstrap = no, my_idx = 1, memb_num = 3
2015-04-22 21:49:37.821  INFO: STATE EXCHANGE: Waiting for state UUID.
2015-04-22 21:49:37.856  INFO: STATE EXCHANGE: sent state msg: 403738d4-e82d-11e4-8fdd-e23f2cc4e259
2015-04-22 21:49:37.860  INFO: STATE EXCHANGE: got state msg: 403738d4-e82d-11e4-8fdd-e23f2cc4e259 from 0 (mysql-pxc01)
2015-04-22 21:49:37.860  INFO: STATE EXCHANGE: got state msg: 403738d4-e82d-11e4-8fdd-e23f2cc4e259 from 1 (garb)
2015-04-22 21:49:37.869  INFO: STATE EXCHANGE: got state msg: 403738d4-e82d-11e4-8fdd-e23f2cc4e259 from 2 (mysql-pxc02)
2015-04-22 21:49:37.869  INFO: Quorum results:
        version    = 3,
        component  = PRIMARY,
        conf_id    = 2,
        members    = 2/3 (joined/total),
        act_id     = 14292,
        last_appl. = -1,
        protocols  = 0/7/3 (gcs/repl/appl),
        group UUID = 79357561-c9f1-11e4-8f0b-9f74387f802d
2015-04-22 21:49:37.869  INFO: Flow-control interval: [9999999, 9999999]
2015-04-22 21:49:37.869  INFO: Shifting OPEN -> PRIMARY (TO: 14292)
2015-04-22 21:49:37.870  INFO: Sending state transfer request: 'trivial', size: 7
2015-04-22 21:49:37.874  INFO: Member 1.0 (garb) requested state transfer from '*any*'. Selected 0.0 (mysql-pxc01)(SYNCED) as donor.
2015-04-22 21:49:37.874  INFO: Shifting PRIMARY -> JOINER (TO: 14292)
2015-04-22 21:49:37.879  INFO: 1.0 (garb): State transfer from 0.0 (mysql-pxc01) complete.
2015-04-22 21:49:37.879  INFO: Shifting JOINER -> JOINED (TO: 14292)
2015-04-22 21:49:37.883  INFO: 0.0 (mysql-pxc01): State transfer to 1.0 (garb) complete.
2015-04-22 21:49:37.883  INFO: Member 1.0 (garb) synced with group.
2015-04-22 21:49:37.883  INFO: Shifting JOINED -> SYNCED (TO: 14292)
2015-04-22 21:49:37.889  INFO: Member 0.0 (mysql-pxc01) synced with group.
2015-04-22 21:49:40.800  INFO: (6a6899f9, 'tcp://0.0.0.0:4567') turning message relay requesting off

7.查看节点状态

主节点：

 备节点：

可以发现cluster成为3节点集群环境。

4.验证Abitrator

引用前文我们介绍的 http://blog.csdn.net/wjf870128/article/details/45199781 双节点percona cluster的失败情况来验证我们的arbitrator是否发生作用。

1.将我们的主备节点通信断开

[root@mysql-pxc01 ~]# iptables -A INPUT -d 192.168.48.12 -s 192.168.48.11 -j REJECT
[root@mysql-pxc01 ~]# iptables -A OUTPUT -d 192.168.48.12 -s 192.168.48.11 -j REJECT

2.查看主备节点状态

主节点：

日志：

备节点：

日志：

发现虽然日志中报通信错误，但是集群状态仍然正常。

3.我们再来插入数据看看是否同步

主节点：

备节点：

可以发现数据已经成功同步到备节点中！Arbitrator功能生效。