文中继上一节Mysql升阶之应用haproxy构建负载均衡群集
这儿贴出来上一节应用haproxy构建负载均衡群集的系统架构图：
负载均衡群集系统架构图
以前大家构建负载均衡的益处：
一个是提升载入特性
一个是当一台从连接点挂了，负载均衡连接点会将要求均值的导入到别的从连接点，提升易用性。
可是以前的事例仅有一台写网络服务器（主连接点），一台负载均衡连接点，假如主连接点挂了，那麼web应用就不可以开展写实际操作，假如负载均衡连接点挂了就没法获取数据。
为了更好地防止这个问题，就需要做一些冗余设计实际操作：
多设定一台主连接点的备份数据连接点，在我们载入的情况下只往主连接点载入，不往这一备份数据连接点载入，换句话说一切正常状况下，备份数据连接点全都无需干。仅有当服务器点挂了了以后，web应用才往这一备份数据连接点载入。而备份数据连接点自然也和全部从连接点是主从复制的关联。
备份数据连接点和主连接点是主主拷贝的关联，那样一方面平常备份数据连接点会和主连接点的增加数据库同步；另一方面在主连接点挂了的期内，备份数据连接点增加的数据信息也会载入到主连接点里边（在主连接点恢复过来后写进驻连接点）。
随后负载均衡连接点也一样是那样实际操作，多搭建一台负载均衡连接点，平常也是失灵，当原负载均衡连接点挂了的情况下，另一台负载均衡连接点便会起功效。
应用keepalived完成高可用性
基本原理和全过程:
连接点一切正常时的虚似IP偏向
连接点服务器宕机时的虚似IP偏向
在主连接点和主连接点的备份数据连接点（称为主连接点2）都安裝keepalived。并根据keepalived的环境变量特定同一个虚似IP,该虚似IP和两部主连接点的IP段要一致才行。
当两部主连接点都运行keepalived服务项目的情况下，keepalived会在这其中一台权重值高的连接点，即主连接点1（权重值能够在keepalived配备中特定）转化成这一虚似IP，另一个连接点不容易转化成这一虚似IP。
大家联接mysql服务项目的情况下，在业务流程层特定联接的host是这一虚似IP的IP，而不是两部主连接点的ip。
这时虚似IP是在主连接点1中转化成的，因此 web应用实际上联接的是主连接点1。
这时，主连接点1和主连接点2是有相互之间通讯的。当主连接点1由于常见故障（如关闭电源，卡死等缘故）造成主连接点1的keepalived服务项目断掉，主连接点2的keepalived接受不上主连接点1的keepalived的回应，那麼主连接点2的keepalived便会在主连接点2上转化成这一虚拟ip。这时web应用联接的便是主连接点2。
当主连接点1恢复正常，而且重新启动keepalived服务项目时，2个连接点的通讯修复，并且主连接点1权重值比主连接点2高，这时主连接点1会再次转化成该虚似IP，柱连接点2的虚似IP就消退。那麼等同于Web连接点又连回主连接点1。
2个主连接点最好是设定开机自启动keepalived，要不然主连接点所属服务器挂了以后再修复，可是忘掉重新启动keepalived，那麼虚拟ip就一直都在备份数据连接点那。
keepalived不仅只局限性在mysql的高可用性，其方面高些。
keepalived的安裝和使
# 免费下载，缓解压力，安裝keepalived
tar -xzf keepalived-2.0.19.tar.gz
cd keepalived-2.0.19
./configure # 假如出错,请安装gcc-c /openssl/openssl-devel这好多个依靠
make && make install这时 keepalive 的
环境变量在 /usr/local/etc/keepalived/keepalived.conf
指令文档在 /usr/local/sbin/keeplive
配备主要参数：
下边是非常简单的配备，也是创作者的配备：
global_defs {
router_id LVS_MASTER # 在每一个keepalived都是有一个router_id，能够随意起,但相接通的keepalived的router_id不可以一样。
}
vrrp_instance VI_1 { # 配备案例
state MASTER # 表明该keepalived的情况，有二种，MASTER和BACKUP。表明是主连接点還是备份数据连接点，可是并不是在这儿配备了MASTER便是主连接点。只是要根据priority配备，优先高的便是主连接点。并且主连接点的priority要比备份数据连接点的至少高50才行
interface eth0 #表明虚拟ip所关联的网口
virtual_router_id 51 # 虚似路由器连接点的id号，主连接点和备份数据连接点的虚似路由器id务必同样
priority 150 # 优先，优先高的是主连接点，主连接点平常处在运行状态，而备份数据连接点平常不干事儿，仅有当主连接点挂掉才代替服务器点工作中
advert_int 1 # 我们知道 主连接点和备份数据连接点的keepalived是相互之间通讯的。这儿是通讯的间隔时间，企业秒。该值越小，越耗费特性。
authentication { # 受权，有二种方法，默认设置应用PASS的方法
auth_type PASS # 受权方法
auth_pass 1111 # 登陆密码，连接的几台keepalived间的登陆密码要同样
}
virtual_ipaddress { # 要转化成的虚似IP地址，能够转化成好几个，能够随便特定，可是务必是和主连接点及其备份数据连接点同样的子网的ip才行
192.168.200.100/24 # 后边的/24表明子网掩码是255.255.255.0
}
}下面就可以运行了
keepalived -D -f /usr/local/etc/keepalived/keepalived.conf # -D后台程序
随后实行
ip add
能够见到eth0网口下有本机ip信息内容，也有虚拟ip的信息内容，就表明成功了：
inet 154.202.57.21/29 brd 154.202.57.225 scope global eth0
valid_lft forever preferred_lft forever
inet 154.202.57.100/24 scope global eth0
valid_lft forever preferred_lft forever
备份数据连接点也安裝keepalived，配备內容以下（和主连接点的基础一样）：
global_defs {
router_id LVS_BACKUP
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.16/24
}
}
发觉这儿并沒有虚拟ip的信息内容。它是对的，由于虚拟ip总是在一台连接点上出現，假如主连接点挂了了，那麼虚拟ip才会出現在备份数据连接点上。
这儿我设定了主连接点的priority比备份数据连接点的priority高50，因此 当主连接点重新启动keepalived服务项目的情况下，虚拟ip会再次绑返回主连接点上。
在业务流程层，大家就立即联接这一虚拟ip，而大家具体连的是这一虚拟ip所属的连接点上，当主连接点一切正常工作中时，虚拟ip在主连接点上，那麼大家具体连的便是主连接点；当主连接点挂了，虚拟ip便会出現备份数据连接点上，大家这时具体联接的就是这个备份数据连接点。
这时我们在本地连接一下这一虚似IP的mysql（主连接点和备份数据连接点要关闭防火墙，并且要受权mysql客户给本地ip才行）
连取得成功就表明就行了。
PS：假如连不上，可能是服务器防火墙没关；
也有很有可能就是你特定的虚似IP是一个真正IP，该真正IP已存有，是他人的网络服务器。
因此 你务必关联一个没人用的ip做为虚拟ip才行。
keepalived的电子邮件主要参数
如今，倘若服务器点挂了了，只剩余一台备份数据连接点了，那麼假如这一备份数据连接点也挂了了，那麼就载入不上数据信息了。这时大家就需要设定电子邮件警报，提醒开发人员只剩余一台连接点了。
电子邮件警报写在global_defs这一全局性配备中，以下：
global_defs{
noticatition_email{
wenzhangxiang@yeah.net # 揽收者
}
notification_email from 1640632344@qq.com # 寄件者
smtp_server localhost # 当地安裝smtp服务项目
smtp_connect_timeout 30 # 请求超时時间
}可是当地都还没安裝smtp服务项目，也要自身安裝smtp服务项目。
keepalived的负载均衡主要参数
keepalived不但能够配备高可用性群集，还能够配备负载均衡群集
实际上便是在keepalived中特定服务项目，这儿以特定mysql服务项目为例子。
假如仅仅构建高可用性，不应用keepalived负载均衡的配备也行，只必须上边的最基础的配备就可以。可是最基础的配备会有一个难题：
我们知道假如主连接点的keepalived服务项目挂了，那麼虚似IP就所意味着的的真正IP便会转到备份数据连接点。可是如果是mysql服务项目挂了可是keepalived服务项目沒有挂了，那麼keepalived就不容易将虚似IP转到备份数据连接点，而大家的目地便是要对mysql服务项目开展高可用性，这类状况下就沒有做到大家的目地，因此 還是要对keepalived的配备特定要关联的服务项目的。
virtual_server 虚似IP 3306 { # “虚似IP 服务器端口” 虚似IP是上边的virtual_ipaddress特定的IP，没有/24；服务器端口就是你想特定的服务项目的服务器端口，假如想对网址开展负载均衡，便是80或443端口
delay_loop 6 #每过6s查验一次中国联通性
lb_algo wrr # 负载均衡的优化算法，wrr/rr/wlc，rr是轮询
lb_kind DR # 负载均衡分享标准：DR/NAT/TUN，假如主连接点和备份数据连接点在同一网段下，用DR就可以
persistence_timeout 60 #对话维持時间
protocol TCP # 协议书
real_server 连接点的真正IP 3306 { # 该设备真正IP
weight 100 # 权重值
notify_down /data/sh/mysql.sh
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 3306
}
}
}这儿提一下notify_down /data/sh/mysql.sh 这一配备。
表明当该连接点的mysql服务项目挂了是，要实行/data/sh/mysql.sh这一shell脚本制作。而这一脚本制作要做的事儿便是将keepalived终止。缘故非常简单，mysql挂了可是keepalived不挂了，那麼主连接点会一直占领着虚似IP，为了更好地将虚似IP迁移到备份数据连接点，大家就需要将主连接点的keepalived杀掉，它是/data/sh/mysql.sh这一脚本制作要做的事儿，该脚本制作內容以下：
#!/bin/bash
pkill keepalive自然大家还能够写一个用以邮件发送的Python脚本制作或是PHP脚本制作，并在mysql.sh这一bash脚本制作中实行发送邮件的脚本制作。那样就可以在连接点挂了时通告管理人员妥善处理。
