mysql fabric cluster_Mysql Fabric 完美高可用集群管理

大家都知道oracle最近出的fabric高可用群集管理，看似方便管理，但自身却是个单点，为追求完美，笔者花费两天时间试图去弥补它的缺陷！

事成之后，不敢私藏，愿与大家分享！

软件环境：

MySQL-client-5.6.19-1.el6.x86_64.rpm

MySQL-server-5.6.19-1.el6.x86_64.rpm

mysql-connector-python-2.0.1-1.el6.noarch.rpm

mysql-utilities-1.5.2-1.el6.noarch.rpm

最小配置五台设备：fabricA、fabricB、 fabricC、fabricD、 fabricE

fabricA、fabricB、

fabricC --

mysql业务库,默认配置为一主二备

fabricD、 fabricE

--FabricStorageDB(双主复制)/FabricManage/keepalived

IP对照表：

192.168.25.101 业务mysql

192.168.25.102 业务mysql

192.168.25.103 业务mysql

192.168.25.104 StorageDB/Fabric

192.168.25.105 StorageDB/Fabric

192.168.25.106 vip 通过 keepalived 实现它在 104、105

上故障转移

架构特点：

1)小规模业务可直接访问 vip Fabric接口，此服务为故障转移高可用；

2)随着业务量的增长，可以将 104，105配置为负载均衡池中，实现入口负载均衡；

3)可随时增加 fabric F G H ... 入口可扩展，支持大规模业务访问；

我的测试：

从104上访问104接口写入数据库

[root@fabricD ~]# python /opt/python_fabric_104.py

Transactions executed on the master

33cf483b-0be7-11e4-95cf-000c294de731:1-2,

65b813f0-0be7-11e4-95d1-000c298fb50b:1-416,

8c0743a4-0b38-11e4-915c-000c29f0e0b0:1-81

Had to synchronize (2,) transactions.

Retrieved (u'lei', u'quanying')

从104上访问105接口写入数据库

[root@fabricD ~]# python /opt/python_fabric_105.py

Transactions executed on the master

33cf483b-0be7-11e4-95cf-000c294de731:1-2,

65b813f0-0be7-11e4-95d1-000c298fb50b:1-420,

8c0743a4-0b38-11e4-915c-000c29f0e0b0:1-81

Had to synchronize (0,) transactions.

Retrieved (u'lei', u'quanying')

下面是从105分别使用两个接口地址访问数据库