文章目录
官方文档
如果英文不好的话，可以参考 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
