乐趣区

关于分布式:冰河能不能讲讲如何实现MySQL数据存储的无限扩容

jiezi

写在后面

随着互联网的高速倒退，企业中积淀的数据也越来越多，这就对数据存储层的扩展性要求越来越高。当今互联网企业中，大部分企业应用的是 MySQL 来存储关系型数据。如何实现 MySQL 数据存储层的高度可扩展性成为了互联网企业必须要解决的问题。那么，如何实现真正意义上的 MySQL 有限扩容呢？明天，冰河就来以实战的角度为大家讲讲如何实现 MySQL 数据库的有限扩容。

文章已收录到：https://github.com/sunshinelyz/technology-binghe 和 https://gitee.com/binghe001/technology-binghe，小伙伴们别忘记给个小星星哦~~

概述

本文是在《海量数据架构下如何保障 Mycat 的高可用？》一文的根底上进一步扩大，从而实现数据存储层每一个环节的高可用，从而实现 MySQL 的有限扩容。

要解决的问题

在《海量数据架构下如何保障 Mycat 的高可用？》一文中，咱们的架构图如下：

由上图能够看出，HAProxy 存在单点隐患，一旦这个 HAProxy 服务宕机，那么整个服务架构将不可用。那么，如何解决 HAProxy 存在的单点隐患问题呢？这就是这篇博文要解决的问题。

软件版本

  • 操作系统：CentOS-6.8-x86_64
  • JDK 版本：jdk1.8
  • HAProxy 版本：haproxy-1.5.19.tar.gz
  • Mycat 版本：Mycat-server-1.6(自行下载源码编译)
  • keepalived 版本:keepalived-1.2.18.tar.gz
  • MySQL 版本：mysql-5.7.tar.gz

部署布局

高可用负载平衡集群部署架构

上图中简化了数据存储局部的架构细节。例如，其中对于架构中的每一个局部，咱们都能够独自进行扩大，独立成集群对外提供服务，而不会存在单点故障的问题。

图解阐明：

(1) HAProxy 实现了 Mycat 多节点的集群高可用和负载平衡，而 HAProxy 本身的高可用则能够通过 Keepalived 来实现。因而，HAProxy 主机上要同时装置 HAProxy 和 Keepalived，Keepalived 负责为该服务器抢占 vip（虚构 ip，图中的 192.168.209.130），抢占到 vip 后，对该主机的拜访能够通过原来的 ip（192.168.209.135）拜访，也能够间接通过 vip（192.168.209.130）拜访。

(2) Keepalived 抢占 vip 有优先级，在 keepalived.conf 配置中的 priority 属性决定。然而个别哪台主机上的 Keepalived 服务先启动就会抢占到 vip，即便是 slave，只有先启动也能抢到（要留神防止 Keepalived 的资源抢占问题）。

(3) HAProxy 负责将对 vip 的申请散发到 Mycat 集群节点上，起到负载平衡的作用。同时 HAProxy 也能检测到 Mycat 是否存活，HAProxy 只会将申请转发到存活的 Mycat 上。

(4) 如果 Keepalived+HAProxy 高可用集群中的一台服务器宕机，集群中另外一台服务器上的 Keepalived 会立即抢占 vip 并接管服务，此时抢占了 vip 的 HAProxy 节点能够持续提供服务。

(5) 如果一台 Mycat 服务器宕机，HAPorxy 转发申请时不会转发到宕机的 Mycat 上，所以 Mycat 仍然可用。

综上：Mycat 的高可用及负载平衡由 HAProxy 来实现，而 HAProxy 的高可用，由 Keepalived 来实现。

HAProxy 节点 2 的部署

HAProxy 主机 2（liuyazhuang136, 192.168.209.136）的装置部署请参考博文《海量数据架构下如何保障 Mycat 的高可用？》，留神配置文件的调整：多节点部署时 haproxy.cfg 配置文件中的 node、description 配置的值要做相应调整。

HAProxy 主机 2（liuyazhuang136, 192.168.209.136）上的 HAProxy 配置如下：

## global 配置中的参数为过程级别的参数，通常与其运行的操作系统无关

global

log 127.0.0.1 local0 info ## 定义全局的 syslog 服务器，最多能够定义 2 个

### local0 是日志设施，对应于 /etc/rsyslog.conf 中的配置，默认回收 info 的日志级别

#log 127.0.0.1 local1 info

chroot /usr/share/haproxy ## 批改 HAProxy 的工作目录至指定的目录并在放弃权限之前执行

### chroot() 操作，能够晋升 haproxy 的安全级别

group haproxy ## 同 gid，不过这里为指定的用户组名

user haproxy ## 同 uid，但这里应用的为用户名

daemon ## 设置 haproxy 后盾守护过程模式运行

nbproc 1 ## 指定启动的 haproxy 过程个数，### 只能用于守护过程模式的 haproxy；默认为止启动 1 个过程，### 个别只在单过程仅能关上多数文件描述符的场中中才应用多过程模式

maxconn 4096 ## 设定每个 haproxy 过程所承受的最大并发连接数，### 其等同于命令行选项 "-n"，"ulimit-n" 主动计算的后果正式参照从参数设定的

# pidfile /var/run/haproxy.pid ## 过程文件（默认门路 /var/run/haproxy.pid）node liuyazhuang136 ## 定义以后节点的名称，用于 HA 场景中多 haproxy 过程共享同一个 IP 地址时

description liuyazhuang136 ## 以后实例的形容信息

## defaults：用于为所有其余配置段提供默认参数，这默认配置参数可由下一个 "defaults" 所从新设定

defaults

log global ## 继承 global 中 log 的定义

mode http ## mode: 所解决的模式 (tcp: 四层 , http: 七层 , health: 状态查看, 只会返回 OK)

### tcp: 实例运行于纯 tcp 模式，在客户端和服务器端之间将建设一个全双工的连贯，#### 且不会对 7 层报文做任何类型的查看，此为默认模式

### http: 实例运行于 http 模式，客户端申请在转发至后端服务器之前将被深度剖析，#### 所有不与 RFC 模式兼容的申请都会被回绝

### health：实例运行于 health 模式，其对入站申请仅响应“OK”信息并敞开连贯，#### 且不会记录任何日志信息，此模式将用于相应内部组件的监控状态检测申请

option httplog

retries 3

option redispatch ## serverId 对应的服务器挂掉后, 强制定向到其余衰弱的服务器

maxconn 2000 ## 前端的最大并发连接数（默认为 2000）### 其不能用于 backend 区段，对于大型站点来说，能够尽可能进步此值以便让 haproxy 治理连贯队列，### 从而防止无奈应答用户申请。当然，此最大值不能超过“global”段中的定义。### 此外，须要留心的是，haproxy 会为每个连贯维持两个缓冲，每个缓存的大小为 8KB，### 再加上其余的数据，每个连贯将大概占用 17KB 的 RAM 空间，这意味着通过适当优化后，### 有着 1GB 的可用 RAM 空间时将保护 40000-50000 并发连贯。### 如果指定了一个过大值，极其场景中，其最终所占据的空间可能会超过以后主机的可用内存，### 这可能会带来意想不到的后果，因而，将其设定一个可承受值放为理智相对，其默认为 2000

timeout connect 5000ms ## 连贯超时(默认是毫秒, 单位能够设置 us,ms,s,m,h,d)

timeout client 50000ms ## 客户端超时

timeout server 50000ms ## 服务器超时

## HAProxy 的状态信息统计页面

listen admin_stats

bind :48800 ## 绑定端口

stats uri /admin-status ## 统计页面

stats auth admin:admin ## 设置统计页面认证的用户和明码，如果要设置多个，另起一行写入即可

mode http

option httplog ## 启用日志记录 HTTP 申请

## listen: 用于定义通过关联“前端”和“后端”一个残缺的代理，通常只对 TCP 流量有用

listen mycat_servers

bind :3307 ## 绑定端口

mode tcp

option tcplog ## 记录 TCP 申请日志

option tcpka ## 是否容许向 server 和 client 发送 keepalive

option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www ## 后端服务状态检测

### 向后端服务器的 48700 端口（端口值在后端服务器上通过 xinetd 配置）发送 OPTIONS 申请

### (原理请参考 HTTP 协定)，HAProxy 会依据返回内容来判断后端服务是否可用.

### 2xx 和 3xx 的响应码示意衰弱状态，其余响应码或无响应示意服务器故障。balance roundrobin ## 定义负载平衡算法，可用于 "defaults"、"listen" 和 "backend" 中, 默认为轮询形式

server mycat_01 192.168.209.133:8066 check port 48700 inter 2000ms rise 2 fall 3 weight 10

server mycat_02 192.168.209.134:8066 check port 48700 inter 2000ms rise 2 fall 3 weight 10

## 格局：server <name> <address>[:[port]] [param*]

### serser 在后端申明一个 server，只能用于 listen 和 backend 区段。### <name> 为此服务器指定的外部名称，其将会呈现在日志及正告信息中

### <address> 此服务器的 IPv4 地址，也反对应用可解析的主机名，但要在启动时须要解析主机名至响应的 IPV4 地址

### [:[port]]指定将客户端连贯申请发往此服务器时的指标端口，此为可选项

### [param*]为此 server 设定的一系列参数，均为可选项，参数比拟多，上面仅阐明几个罕用的参数：#### weight: 权重，默认为 1，最大值为 256，0 示意不参加负载平衡

#### backup: 设定为备用服务器，仅在负载平衡场景中的其余 server 均不能够启用此 server

#### check: 启动对此 server 执行监控状态查看，其能够借助于额定的其余参数实现更精密的设定

#### inter: 设定监控状态查看的工夫距离，单位为毫秒，默认为 2000，##### 也能够应用 fastinter 和 downinter 来依据服务器端专题优化此事件提早

#### rise: 设置 server 从离线状态转换至失常状态须要查看的次数（不设置的状况下，默认值为 2）#### fall: 设置 server 从失常状态转换至离线状态须要查看的次数（不设置的状况下，默认值为 3）#### cookie: 为指定 server 设定 cookie 值，此处指定的值将会在申请入站时被查看，##### 第一次为此值筛选的 server 将会被后续的申请所选中，其目标在于实现长久连贯的性能

#### maxconn: 指定此服务器承受的最大并发连接数，如果发往此服务器的连贯数目高于此处指定的值，##### 其将被搁置于申请队列，以期待其余连贯被开释

HAProxy 节点 1 的状态信息页：http://192.168.209.135:48800/admin-status

HAProxy 节点 2 的状态信息页：http://192.168.209.136:48800/admin-status

Keepalived 介绍

官网：http://www.keepalived.org/

Keepalived 是一种高性能的服务器高可用或热备解决方案，Keepalived 能够用来避免服务器单点故障的产生，通过配合 Haproxy 能够实现 web 前端服务的高可用。Keepalived 以 VRRP 协定为实现根底，用 VRRP 协定来实现高可用性 (HA)。VRRP(Virtual Router Redundancy Protocol) 协定是用于实现路由器冗余的协定，VRRP 协定将两台或多台路由器设施虚构成一个设施，对外提供虚构路由器 IP(一个或多个)，而在路由器组外部，如果理论领有这个对外 IP 的路由器如果工作失常的话就是 MASTER，或者是通过算法选举产生。MASTER 实现针对虚构路由器 IP 的各种网络性能，如 ARP 申请，ICMP，以及数据的转发等；其余设施不领有该虚构 IP，状态是 BACKUP，除了接管 MASTER 的 VRRP 状态通告信息外，不执行对外的网络性能。当主机生效时，BACKUP 将接管原先 MASTER 的网络性能。VRRP 协定应用多播数据来传输 VRRP 数据，VRRP 数据应用非凡的虚构源 MAC 地址发送数据而不是本身网卡的 MAC 地址，VRRP 运行时只有 MASTER 路由器定时发送 VRRP 通告信息，示意 MASTER 工作失常以及虚构路由器 IP(组)，BACKUP 只接管 VRRP 数据，不发送数据，如果肯定工夫内没有接管到 MASTER 的通告信息，各 BACKUP 将宣告本人成为 MASTER，发送通告信息，从新进行 MASTER 选举状态。

Keepalived 的装置

留神：须要在 192.168.209.135、192.168.209.136 两台服务器上安装 Keepalived。

Keepalived（http://www.keepalived.org/download.html）

上传或下载 keepalived

上传或下载 keepalived（keepalived-1.2.18.tar.gz）到 /usr/local/src 目录

解压装置

装置 keepalived 须要用到 openssl

# yum install gcc gcc-c++ openssl openssl-devel
# cd /usr/local/src
# tar -zxvf keepalived-1.2.18.tar.gz
# cd keepalived-1.2.18
# ./configure --prefix=/usr/local/keepalived
# make && make install

将 keepalived 装置成 Linux 零碎服务

因为没有应用 keepalived 的默认门路装置（默认是 /usr/local）, 装置实现之后，须要做一些工作
复制默认配置文件到默认门路

# mkdir /etc/keepalived
# cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/

复制 keepalived 服务脚本到默认的地址

# cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
# cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
# ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/
# ln -s /usr/local/keepalived/sbin/keepalived /sbin/

设置 keepalived 服务开机启动

# chkconfig keepalived on

批改 Keepalived 配置文件

(1) MASTER 节点配置文件（192.168.209.135）

! Configuration File for keepalived
global_defs {
## keepalived 自带的邮件揭示须要开启 sendmail 服务。倡议用独立的监控或第三方 SMTP
    router_id liuyazhuang135 ## 标识本节点的字条串，通常为 hostname
}
## keepalived 会定时执行脚本并对脚本执行的后果进行剖析，动静调整 vrrp_instance 的优先级。## 如果脚本执行后果为 0，并且 weight 配置的值大于 0，则优先级相应的减少。## 如果脚本执行后果非 0，并且 weight 配置的值小于 0，则优先级相应的缩小。## 其余状况，维持本来配置的优先级，即配置文件中 priority 对应的值。vrrp_script chk_haproxy {
    script "/etc/keepalived/haproxy_check.sh" ## 检测 haproxy 状态的脚本门路
    interval 2 ## 检测时间距离
    weight 2 ## 如果条件成立，权重 +2
}
## 定义虚构路由，VI_1 为虚构路由的标示符，本人定义名称
vrrp_instance VI_1 {
    state BACKUP ## 默认主设施（priority 值大的）和备用设施（priority 值小的）都设置为 BACKUP，## 由 priority 来管制同时启动状况下的默认主备，否则先启动的为主设施
    interface eth3 ## 绑定虚构 IP 的网络接口，与本机 IP 地址所在的网络接口雷同，我的是 eth3
    virtual_router_id 35 ## 虚构路由的 ID 号，两个节点设置必须一样，可选 IP 最初一段应用,
    ## 雷同的 VRID 为一个组，他将决定多播的 MAC 地址
    priority 120 ## 节点优先级，值范畴 0-254，MASTER 要比 BACKUP 高
    nopreempt ## 主设施（priority 值大的）配置肯定要加上 nopreempt，否则非抢占也不起作用
    advert_int 1 ## 组播信息发送距离，两个节点设置必须一样，默认 1s
    ## 设置验证信息，两个节点必须统一
    authentication {
        auth_type PASS
        auth_pass 1111 ## 实在生产，按需要对应该过去
    }
    ## 将 track_script 块退出 instance 配置块
    track_script {chk_haproxy ## 查看 HAProxy 服务是否存活}
    ## 虚构 IP 池, 两个节点设置必须一样
    virtual_ipaddress {192.168.209.130 ## 虚构 ip，能够定义多个，每行一个}
}

(2)BACKUP 节点配置文件（192.168.209.136）

! Configuration File for keepalived
global_defs {router_id liuyazhuang136}
vrrp_script chk_haproxy {
    script "/etc/keepalived/haproxy_check.sh"
    interval 2
    weight 2
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth3
    virtual_router_id 35
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    track_script {chk_haproxy}
    virtual_ipaddress {192.168.209.130}
}

特地留神：如果非抢占模式不失效，在 Keepalived 的故障节点复原后会再次导抢占 vip，从而因 vip 切换而闪断带来的危险（视频讲解）。按以上配置，配置了 Keepalived 非抢占模式，配置及留神点如下：
(1) 主设施、从设施中的 state 都设置为 BACKUP
(2) 主设施、从设施中都不要配置 mcast_src_ip（本机 IP 地址）
(3) 默认主设施（priority 值大的 Keepalived 节点）配置肯定要加上 nopreempt，否则非抢占不起作用
(4) 防火墙配置容许组播（主、备两台设施上都须要配置，keepalived 应用 224.0.0.18 作为 Master 和 Backup 健康检查的通信 IP）

# iptables -I INPUT -i eth3 -d 224.0.0.0/8 -p vrrp -j ACCEPT
# iptables -I OUTPUT -o eth3 -d 224.0.0.0/8 -p vrrp -j ACCEPT（eth3 为主机的网卡设施名称，生产环境服务器能够用独立网卡来解决组播和心跳检测等）# service iptables save
重启防火墙：# service iptables restart

编写 Haproxy 状态检测脚本

咱们编写的脚本为 /etc/keepalived/haproxy_check.sh (已在 keepalived.conf 中配置)
脚本要求：如果 haproxy 进行运行，尝试启动，如果无奈启动则杀死本机的 keepalived 过程，keepalied 将虚构 ip 绑定到 BACKUP 机器上。

内容如下：

# mkdir -p /usr/local/keepalived/log
# vi /etc/keepalived/haproxy_check.sh

haproxy_check.sh 脚本内容如下：

#!/bin/bash
START_HAPROXY="/etc/rc.d/init.d/haproxy start"
STOP_HAPROXY="/etc/rc.d/init.d/haproxy stop"
LOG_FILE="/usr/local/keepalived/log/haproxy-check.log"
HAPS=`ps -C haproxy --no-header |wc -l`
date "+%Y-%m-%d %H:%M:%S" >> $LOG_FILE
echo "check haproxy status" >> $LOG_FILE
if [$HAPS -eq 0];then
echo $START_HAPROXY >> $LOG_FILE
$START_HAPROXY >> $LOG_FILE 2>&1
sleep 3
if [`ps -C haproxy --no-header |wc -l` -eq 0];then
echo "start haproxy failed, killall keepalived" >> $LOG_FILE
killall keepalived
fi
fi

保留后，给脚本赋执行权限：

# chmod +x /etc/keepalived/haproxy_check.sh

启动 Keepalived

# service keepalived start
Starting keepalived: [OK]

Keepalived 服务治理命令：

进行：service keepalived stop
启动：service keepalived start
重启：service keepalived restart
查看状态：service keepalived status

高可用测试

（1）敞开 192.168.209.135 中的 Haproxy，Keepalived 会将它重新启动

# service haproxy stop

（2）敞开 192.168.209.135 中的 Keepalived，VIP（192.168.209.130）会被 192.168.209.136 抢占

# service keepalived stop

由上图可知：Keepalived 进行后，192.168.209.135 节点的网络接口中的 VIP（192.168.209.130）将隐没

此时，由上图可知：在 192.168.209.136 节点的网络接口中会呈现 VIP（192.168.209.130）。

查看此时 VIP 对应的 MAC，Windows 下应用 CMD 命令查看：

阐明此时 VIP 曾经漂移到物理主机 192.168.209.136 上了

再通过 VIP(192.168.209.130) 来拜访 Haproxy 集群，拜访到的也是 192.168.209.136

（3）重新启动 192.168.209.135 中的 Keepalived

重新启动 192.168.209.135 中的 Keepalived，vip（192.168.209.130）保留在 192.168.209.136 主机上，不会呈现 135 启动抢占 vip 的状况。

# service keepalived start

（4）模仿抢占了 vip 的节点（192.168.209.136）中的 HAProxy 故障或启动失败

形式：把 192 节点中的 haproxy.cfg 文件重命名为 haproxy.cfg_bak，并把 haproxy 服务进行 kill 掉，此时 keepalived 会尝试去启动 haproxy，会因为找不到配置文件而启动失败，此时就会进行 haproxy_check.sh 脚本中的 killall keepalived 命令，完结 keepalived 进行。随后就是 192.168.209.135 节点从新抢占 vip

阐明此时 VIP 曾经漂移到物理主机 192.168.209.135 上了

再通过 VIP(192.168.209.130) 来拜访 Haproxy 集群，拜访到的也是 192.168.209.135

验证数据库拜访

通过 vip 拜访数据库、验证 vip 切换后的数据库拜访

（1）命令行拜访数据库

（2）Navicat 拜访数据库

至此，Mycat 高可用负载平衡集群的实现（HAProxy + Keepalived + Mycat）搭建结束

大家能够到链接 http://download.csdn.net/detail/l1028386804/9915621 下载搭建 Mycat 高可用负载平衡集群的实现（HAProxy + Keepalived + Mycat）应用的 Keepalived

其余举荐文章

  • 《海量数据架构下如何保障 Mycat 的高可用？》
  • 《冰河，能讲讲 Mycat 如何实现 MySQL 的读写拆散吗？》
  • 《MySQL 如何实现万亿级数据存储？》
  • 《Mycat 外围开发者带你轻松把握 Mycat 路由转发！！》
  • 《Mycat 外围开发者带你看尽 Mycat 三大外围配置文件！！》
  • 《作为 Mycat 外围开发者，怎能不来一波 Mycat 系列文章？》

重磅福利

微信搜一搜【冰河技术】微信公众号，关注这个有深度的程序员，每天浏览超硬核技术干货，公众号内回复【PDF】有我筹备的一线大厂面试材料和我原创的超硬核 PDF 技术文档，以及我为大家精心筹备的多套简历模板（不断更新中），心愿大家都能找到心仪的工作，学习是一条时而郁郁寡欢，时而开怀大笑的路，加油。如果你通过致力胜利进入到了心仪的公司，肯定不要懈怠放松，职场成长和新技术学习一样，逆水行舟。如果有幸咱们江湖再见！

另外，我开源的各个 PDF，后续我都会继续更新和保护，感激大家长期以来对冰河的反对！！

退出移动版