生猛干货

带你搞定MySQL实战，轻松对应海量业务处理及高并发需求，从容应对大场面试

官方文档

https://dev.mysql.com/doc/

如果英文不好的话，可以参考 searchdoc 翻译的中文版本

http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html

主从复制配置的目的之一----读写分离

我们进行主从复制配置的一个主要目的就是 分担 主库的 读压力，将读的请求都转移到 从节点上。

为什么要进行读写分离

那么为什么要进行读写分离呢？ 我们知道基本上80%的操作都是读请求 ------> 写操作的压力是无法分担的，而且只能在主节点上操作。 而读操作呢 就可以在主节点上 也可以在从节点上，所以为了减少主节点的DB压力，将读请求转移到一个或者多个从节点上。

读写分离的实现方式

基本上有两种方式

• 大部分都用过，配置动态数据源 。 程序直连DB，性能损耗较少 ，方便维护。要说缺点的话无非就是要开发 。 比较简单，我们这里不讨论该方案。
• 依靠中间件

程序开发

aop 动态数据源，这里不探讨这个方案，实现起来也比较简单。

中间件maxScale 实现读写分离

主流的两个 ： mysql-proxy （未正式发布，性能和稳定性有点问题，不建议） 和 maxScale .

maxScale 是 MariaDB（MySQL的分支版本） 提供的中间件。

maxScale 不仅能提供读写分离，而且能实现读请求的负载均衡 。

使用中间件实现读写分离的优缺点

优点：

• 由中间件根据查询语法分析，自动完成读写分离。 但存过这种，识别不出来，会在主节点执行
• 对应用透明，无需修改程序

缺点：

• 大并发高负载的情况下，由于增加了中间层，对查询有损耗。 （QPS 50%-70%的降低）
• 对于延迟敏感的业务无法自主在主库执行

读写分离： 要解决的是如何在复制集群的不同角色上，去执行不同的SQL

读的负载均衡： 要解决的是具有相同角色的数据库，如何共同分担相同的负载。

如何实现读的负载均衡 ： 软件 ：LVS 、 Haproxy、MaxScale 等 ， 硬件： F5 等

MaxScale

最终的架构

我们先看下我们再次将要完成的方案的架构

MySQL ---- > MaxScale -----> MHA集群

MaxScale Core介绍

• Authentication 认证插件 ： 缓存用户信息
• Protocal协议插件
• Router 路由插件 （readconnroute 负责多台服务器负载均衡 、readwritesplit 负责读写分离） – 比较重要
• Monitor 监控插件
• Filter & Logging 日志和过滤插件

安装部署

请移步 https://pan.baidu.com/s/1SVnUHzqr-KyyYRl5fRbkqg

搞定MySQL