基于CentOS7,MySQL5.7的 读写分离
一、读写分离
1.1 读写分离引入时机
大多数互联网业务中,往往读多写少,这时候数据库的读会首先成为数据库的瓶颈。如果我们已经优化了SQL,但是读依旧还是瓶颈时,这时就可以选择“读写分离”架构了。
读写分离首先需要将数据库分为主从库,一个主库用于写数据,多个从库完成读数据的操作,主从库之间通过主从复制机制进行数据的同步,如图所示。
在应用中可以在从库追加多个索引来优化查询,主库这些索引可以不加,用于提升写效率。
读写分离架构也能够消除读写锁冲突从而提升数据库的读写性能。使用读写分离架构需要注意:主从同步延迟和读写分配机制问题
1.2 主从同步延迟
使用读写分离架构时,数据库主从同步具有延迟性,数据一致性会有影响,对于一些实时性要求比较高的操作,可以采用以下解决方案。
- 写后立刻读
在写入数据库后,某个时间段内读操作就去主库,之后读操作访问从库。 - 二次查询
先去从库读取数据,找不到时就去主库进行数据读取。该操作容易将读压力返还给主库,为了避免恶意攻击,建议对数据库访问API操作进行封装,有利于安全和低耦合。 - 根据业务特殊处理
根据业务特点和重要程度进行调整,比如重要的,实时性要求高的业务数据读写可以放在主库。对于次要的业务,实时性要求不高可以进行读写分离,查询时去从库查询。
1.3 读写分离实现方案
读写路由分配机制是实现读写分离架构最关键的一个环节,就是控制何时去主库写,何时去从库读。目
前较为常见的实现方案分为以下两种:
- 基于编程和配置实现(应用端)
程序员在代码中封装数据库的操作,代码中可以根据操作类型进行路由分配,增删改时操作主库,查询时操作从库。这类方法也是目前生产环境下应用最广泛的。优点是实现简单,因为程序在代码中实现,不需要增加额外的硬件开支,缺点是需要开发人员来实现,运维人员无从下手,如果其中一个数据库宕机了,就需要修改配置重启项目。 - 基于服务器端代理实现(服务器端)
中间件代理一般介于应用服务器和数据库服务器之间,从图中可以看到,应用服务器并不直接进入到master数据库或者slave数据库,而是进入MySQL proxy代理服务器。代理服务器接收到应用服务器的请求后,先进行判断然后转发到后端master和slave数据库。
目前有很多性能不错的数据库中间件,常用的有MySQL Proxy、MyCat以及Shardingsphere等等。
- MySQL Proxy:是官方提供的MySQL中间件产品可以实现负载平衡、读写分离等。
- MyCat:MyCat是一款基于阿里开源产品Cobar而研发的,基于 Java 语言编写的开源数据库中间
件。 - ShardingSphere:ShardingSphere是一套开源的分布式数据库中间件解决方案,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(计划中)这3款相互独立的产品组成。已经在2020年4月16日从Apache孵化器毕业,成为Apache顶级项目。
- Atlas:Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个数据库中间件。
- Amoeba:变形虫,该开源框架于2008年开始发布一款 Amoeba for MySQL软件。
1.4 读写分离搭建,基于服务器端代理实现
1.4.1 安装代理机Proxy
代理服务器可以使用克隆的方式来实现,修改ip地址为:192.168.80.155
1.4.2 安装代理插件
上传插件:
mysql-proxy-0.8.5-linux-el6-x86-64bit.tar.gz
解压:
tar -zxvf mysql-proxy-0.8.5-linux-el6-x86-64bit.tar.gz(此工具内部使用了大量得lua脚本进行分发处理)
创建proxy配置文件,配置参数:vim /etc/mysql-proxy.cnf
user=root 当前代理节点账号
admin-username=root 主从mysql数据库账号和密码
admin-password=root
proxy-address=192.168.80.155:4040 当前代理节点运行的ip地址和端口(请求入口,后续进行分发)
设置主库:
proxy-backend-addresses=192.168.80.128:3306 可以指定多个,使用逗号隔开
设置从库:
proxy-read-only-backend-addresses=192.168.80.55:3306 可以指定多个
设置lua脚本进行管理:
proxy-lua-script=/softInstall/mysql/mysql-proxy-0.8.5-linux-el6-x86-64bit/share/doc/mysql-proxy/rw-splitting.lua
log-file=/var/log/mysql-proxy.log
log-level=debug
运行方式:
daemon=true
keepalive=true 遇到故障,自动重启
添加操作权限:
chmod 660 /etc/mysql-proxy.cnf
修改lua脚本:
设置触发代理的链接池数,vi rw-splitting.lua
后续所有数据库操作都将进入proxy代理,达到链接数,才进行相应读写分离配置。
1.4.3 启动mysql-proxy
执行命令:
./mysql-proxy --defaults-file=/etc/mysql-proxy.cnf
如果没有报错,则表示启动成功。(proxy的防火墙也需要进行关闭)
1.4.4 测试
使用可视化工具链接proxy:
通过proxy查询数据:
关闭从节点:
通过可视化工具访问proxy,执行数据插入操作:
在主节点查看数据:
查询到通过代理节点插入的新的数据,说明代理将写操作转发到了主节点进行操作
通过可视化工具访问proxy,查询数据:
查询不到刚刚通过代理插入的数据,而从节点关闭导致没有插入成功,说明查询操作是通过从节点进行处理的
二、双主模式
2.1 适用场景
很多企业刚开始都是使用MySQL主从模式,一主多从、读写分离等。但是单主如果发生单点故障,从库切换成主库还需要作改动。因此,如果是双主或者多主,就会增加MySQL入口,提升了主库的可用性。因此随着业务的发展,数据库架构可以由主从模式演变为双主模式。双主模式是指两台服务器互为主从,任何一台服务器数据变更,都会通过复制应用到另外一方的数据库中。
使用双主双写还是双主单写?
建议大家使用双主单写,因为双主双写存在以下问题:
- ID冲突
在A主库写入,当A数据未同步到B主库时,对B主库写入,如果采用自动递增容易发生ID主键的冲突。可以采用MySQL自身的自动增长步长来解决,例如A的主键为1,3,5,7…,B的主键为2,4,6,8… ,但是对数据库运维、扩展都不友好。 - 更新丢失
同一条记录在两个主库中进行更新,会发生前面覆盖后面的更新丢失。
高可用架构如下图所示,其中一个Master提供线上服务,另一个Master作为备胎供高可用切换,Master下游挂载Slave承担读请求。
随着业务发展,架构会从主从模式演变为双主模式,建议用双主单写,再引入高可用组件,例如:Keepalived和MMM等工具,实现主库故障自动切换。
2.2 双主模式搭建
暂时略,后续补充
2.3 MMM架构
MMM(Master-Master Replication Manager for MySQL)是一套用来管理和监控双主复制,支持双主故障切换 的第三方软件。MMM 使用Perl语言开发,虽然是双主架构,但是业务上同一时间只允许一个节点进行写入操作。下图是基于MMM实现的双主高可用架构。
-
MMM故障处理机制
MMM 包含writer和reader两类角色,分别对应写节点和读节点。 * 当 writer节点出现故障,程序会自动移除该节点上的VIP * 写操作切换到 Master2,并将Master2设置为writer * 将所有Slave节点会指向Master2
除了管理双主节点,MMM 也会管理 Slave 节点,在出现宕机、复制延迟或复制错误,MMM 会移除该节点的 VIP,直到节点恢复正常。
-
MMM监控机制
MMM 包含monitor和agent两类程序,功能如下: * monitor:监控集群内数据库的状态,在出现异常时发布切换命令,一般和数据库分开部署。 * agent:运行在每个 MySQL 服务器上的代理进程,monitor 命令的执行者,完成监控的探针工作和具体服务设置,例如设置 VIP(虚拟IP)、指向新同步节点。