今天我们就来搭建一个读写分离，负载均衡的MySQL集群。想了解高可用理论方面内容的童鞋可以阅读理论篇。

奥兹·杰克：MySQL高可用方案：理论篇​zhuanlan.zhihu.com

搭建的集群的基本架构如下：

假设该集群下各机器的IP地址如下：

Master： 192.168.1.1

route：192.168.1.2

slave1：192.168.1.3

slave2:192.168.1.4

首先，我们需要通过主从复制搭建起最基本的一主三从集群。

• 配置master

1. 先在主数据库中创建主从复制使用的用户repli

GRANT REPLICATION SLAVE ON *.* TO 'repli'@'%' IDENTIFIED BY 'password';

然后修改my.cnf文件，在[mysqld]下添加如下配置：

[mysqld]
server-id=1  # id必须唯一
log-bin=mysql-bin  # 二进制文件名
log-bin-index=master-bin.index   # 显示master状态
binlog-do-db=DATABASE_NAME  # 主从复制哪些数据库
sync_binlog=N   # 每执行N次写入后与硬盘同步一次

值得一提的是，sync_binlog参数用于控制数据库的binlog与磁盘同步，默认情况下，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。1是最安全的，但是也是最慢的。因此，可以视具体情况选择合适的sync_binlog值。

重启mysqld服务之后，通过SHOW MASTER STATUS；可以查看主服务器的master状态

其中File显示的是二进制日志的文件名称，假设此处File为‘mysql-bin.000001’，Position为654321

• 配置Slave

修改配置文件my.cnf，在[mysqld]下添加如下配置：

[mysqld]
server-id=2   # 此id一定要大于master的id，且id必须保持唯一
relay-log-index=slave-relay-bin.index  # 定义relay-log-index的文件名
relay-log=slave-relay-bin  # 定义relay-log的文件名（默认保存在数据目录下）

配置完毕后重启mysqld，进入mysql命令行开始登陆master：

change master to master_host='192.168.1.1',
master_port=3306,
master_user='repli',
master_password='password',
master_log_file='mysql-bin.000001',
master_log_pos=654321;

其中master_log_file='mysql-bin.000001' 填的是master中二进制文件的名称

master_log_pos=654321 填的是master中Position的值

然后执行start slave;开始主从复制

mysql> start slave;     # 开始主从复制

此时可以通过show slave status G;查看从机状态

为了使从服务器专注于读服务，可以在每台从服务器上都执行set global read_only=1;来禁止写入。

而负载均衡可以通过HAProxy实现，在route机上安装HAProxy。

- - - - - - - - - - - - - - - - - - - HAProxy安装过程省略线 - - - - - - - - - - - - - - - - - - - - -

安装成功后打开/etc/haproxy/haproxy.cfg进行配置

globaldaemon # 以守护进程的方式工作于后台，其等同于“-D”选项的功能nbproc 1log 127.0.0.1 local2  # 通过local2进行log记录pidfile /var/run/haproxy.pidmaxconn 5000  # 最大并发连接数,等同于命令行选项“-n”  default=4000defaultsmode tcp  # mode{tcp/http/health}: tcp在第四层, http在第七层.retries 3 # 3次连接失败就认为服务器不可用，通过check进行检查option redispatch  # serverId对应的服务器挂掉后,强制定向到其他健康的服务器option abortonclosemaxconn 4096timeout connect 5000mstimeout client 30000mstimeout server 30000mstimeout check 2000log global# 监控页面配置
listen admin_statsstats enablebind 0.0.0.0:8080  # 监听端口mode httpoption httplogmaxconn 5stats refresh 30s  # 30s刷新一次页面stats uri /MONITER # 虚拟路径stats hide-version  # 隐藏HAProxy的版本号stats realm Global statisticsstats auth root:abcd1234   # 登录账号：密码
# 配置完毕后可以通过 http://ip:8080/MONITER 同时输入账号密码来访问HAProxy的监控页面listen testbind 0.0.0.0:3306log 127.0.0.1 local0 debugbalance roundrobin  # 负载均衡算法option mysql-check user lb01mode tcpserver slave1 192.168.1.3:3306 server slave2 192.168.1.4:3306 # 如果还有更多从机，直接追加即可

• 配置段说明：

“global”配置中的参数为进程级别的参数，且通常与其运行的操作系统有关

“defaults”用于为所有其他配置段提供默认参数

“forntend”用于定义一系列监听的套接字，这些套接字可以接受客户端请求并与子建立连接

“backend” 用于定义一系列“后端”服务器，代理将会将对应客户端的请求转发至这些服务器

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

• 负载均衡算法：

“balance”用于定义负载均衡算法，可用于"defaults"、"listen"和"backend"中。用于在负载均衡场景中挑选一个server。

其支持的算法有：

roundrobin：基于权重进行轮询，在服务器的处理时间保持均匀分布时 ，这是最平衡、最公平的算法。此算法是动态的，这表示某权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多支持4128个连接。

static-rr：基于权重进行轮询，与roundrobin类似，但是为静态方法，在运行时调整期后端权重不会生效，不过，其在后端服务器连接数上没有限制。

leastconn：新的连接会被派发至具有最少连接数目的后端服务器，在有这较长会话的场景中推荐使用此算法，如LDAP、SQL等。其并不太适合用于较短会话的应用层协议，如HTTP，此算法是动态的，可以在运行时调整其权重。

source：将请求的源地址进行hash运算，并有后端的服务器的权重总数相处后派发至某匹配的服务器，这可以使得同一个客户端IP的请求始终被派发至某特定的服务器，不过，当服务器权重总数发生变化时，如某服务器宕机或者添加新服务器，许多的请求可能会被派发至与此前请求不同的服务器，常用于负载均衡无cooki功能的基于TCP的协议，默认为动态，不过可以使用hash-type修改此特性。

uri：对URI的左半部分（“问号”标记之前的部分）或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是派发至某匹配的服务器，除法服务器的权重总数发生了变化，此算法常用于代理缓存或反病毒代理以提高缓存的命中率，需要注意的是，此算法仅应用于HTTP后端服务器场景，其默认为静态算法，不过可以使用hash-type修改此特性。

url_param：通过为URL指定的参数在每个HTTP GET请求中将会被索引，日过找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相处后派发至某匹配的服务器，此算法可以通过追踪请求中的用户标识进而确保同一个用户的ID请求被发送同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮询算法对其想用请求进行调度，此算法默认为静态，不过可以使用hash-type修改此特性。

har（）:对于每个HTTP请求，通过指定的HTTP首部将会被检索，如果对于那个的首部没有出现或其没有有效值，则使用轮询算法对响应请求进行调度，其有一个可选项“use_domain_only”可以指定检索类似host类的首部时仅计算域名部分以降低hash算法的运算量，此算法默认为静态，不过可以使用hash-type修改此特性。

• 参数mode说明：

用于设定实例的运行模式或协议，当实现内容交换时，前段和后端必须工作与统一中模式（一般说来时tcp模式），否则将无法启动实例。

其一共支持tcp、http、health三种模式。

1. tcp: 实例运行于纯tcp模式，在客户端和服务器端之间将建立一个全双工的连接，且不会对7层报文做任何类型的检查，此为默认模式，通常用于SSL、SSH、SMTP等应用

2. http：实例运行于http模式，客户端请求在转发至后端服务器之前将被深度分析，所有不与RFC模式兼容的请求都会被拒绝

3. health：实例运行于health模式，其对入站请求仅响应“OK”信息并关闭连接，且不会记录任何日志信息 ，此模式将用于相应外部组件的监控状态检测请求；目前来讲，此模式已经废弃，因为tcp或http模式中的monitor关键字可完成此类功能

介绍完haproxy的基本配置以后，咱们回到部署的步骤中。

配置完毕后，直接service haproxy start启动haproxy服务即可。

此时查询haproxy状态就可以看得到：

HAProxy启动成功！现在整个集群中以它作为从机负载均衡的路由，读服务直接访问route，它会根据负载均衡算法将读请求分配给某个slave，从而实现负载均衡。